<whitequark>
i like how each RE project uses a pun as a name
<ZirconiumX>
Also useful for avoiding any copyright claims
ondrej3 has quit [Quit: Leaving]
<ZirconiumX>
I can't think of a neat way of doing bitstream -> LUT conversion, so 64 if statements it is
<whitequark>
you could use a lookup table
<whitequark>
although i personally used um, give me a secon
<ZirconiumX>
I'd need quite a few of them for each individual byte
<whitequark>
byte?
<ZirconiumX>
Pass bytes in, or together the resulting LUT
Asu has joined ##openfpga
Asu` has quit [Ping timeout: 268 seconds]
vonnieda has joined ##openfpga
vonnieda has quit [Read error: Connection reset by peer]
vonnieda_ has joined ##openfpga
pie__ has joined ##openfpga
pie_ has quit [Remote host closed the connection]
pie__ has quit [Remote host closed the connection]
pie__ has joined ##openfpga
pie__ has quit [Remote host closed the connection]
genii has quit [Remote host closed the connection]
pie__ has joined ##openfpga
pie__ has quit [Remote host closed the connection]
pie_ has joined ##openfpga
mumptai has joined ##openfpga
ym has joined ##openfpga
dh73 has joined ##openfpga
<azonenberg>
ZirconiumX: just index into a truth table
<azonenberg>
for a lut4: wire[15:0] lut = $VALUE; wire[3:0] a = {a3, a2, a1, a0}; assign out = lut[a];
<azonenberg>
or what are you trying to do
<ZirconiumX>
azonenberg: I'm writing a LUT scrambler/descrambler for a Cyclone V bitstream
<ZirconiumX>
No Verilog here
<ZirconiumX>
Given an input LUT, lay out the bits of the LUT how the bitstream expects them
<ZirconiumX>
And conversely, given a bitstream, retrieve the bits of the LUT
<whitequark>
azonenberg: that's actually an incorrect way to implement a LUT in Verilog
<azonenberg>
whitequark: oh?
<whitequark>
for two unrelated reasons even
* whitequark
should write "The Verilog Haters' Handbook"
<azonenberg>
i'm assuming a behavioral sim model without reprogramming
<whitequark>
yes.
<whitequark>
incorrect.
<azonenberg>
how?
<whitequark>
1) it doesn't do correct x-propagation (i.e. a symmetric LUT driven by an x input should not result in x output)
<azonenberg>
... x's
<whitequark>
2) it doesn't introduce delta cycles and so simulators will glitch at the very start of simulation
<whitequark>
this was actually how behavioral LUT models were written in Yosys
<whitequark>
and it does break in real world in very confusing ways
<azonenberg>
I would probably also add assertions to verify that there are no X's
<whitequark>
then you can never disconnect an input to this LUT
<azonenberg>
You never should
<azonenberg>
tie off if not used
<ZirconiumX>
At least Verilog only has 4 logic levels, not 9 ^^;
<whitequark>
well, arguably x-propagation is a feature of behavioral Verilog, not a bug
<whitequark>
but yes, I guess asserting that the inputs aren't x also works
<whitequark>
still two bugs :)
<azonenberg>
My rule is that if your FPGA design ever has an X, there is a bug in either the simulation or your rtl, if not both
<azonenberg>
in ASIC having no reset is OK for datapath elements that dont need it
<azonenberg>
but in FPGA everything should always be well defined
<tnt>
azonenberg: Heh .. bram content can be x, srl content can be x, ...
<tnt>
I want my simulator to properly show me thos 'x' are stopped where I designed them to be stopped.
<whitequark>
azonenberg: that's the philosophy on which migen is designed
<azonenberg>
bram content can only get X if you violate timing iirc
<whitequark>
no, uninitialized bram
<azonenberg>
i dont think that is possible on xilinx
<whitequark>
sometimes you physically cannot fit initialization data into the bitstream
<tnt>
and there is more than xilinx :p
<whitequark>
for FPGAs with onboard flash
<azonenberg>
there is always an init value, if not specified it defaults to zero
<whitequark>
MachXO2 for example
<azonenberg>
i dont think xilinx has an option to omit it
<whitequark>
not necessarily
<azonenberg>
that was why they had the bitstream compression option
<azonenberg>
because otherwise an empty fpga has a huge bitstream from all the bram init
<whitequark>
for example, on ice40, the WARMBOOT primitive allows retaining BRAM contents
<whitequark>
so that would also be x
<whitequark>
logically
<tnt>
spram can't even _be_ initialized.
<whitequark>
also that
<whitequark>
the other use of X is essentially the same as undefined behavior in C/C++
<whitequark>
if an input to logic is provably X, synthesizer can pick it to be anything that's smaller because you are declaring that it doesn't matter which it is
<azonenberg>
pretty sure on xilinx lutram initializes to a known value, default zero, too
<azonenberg>
it just uses the truth table bits in the bitstream
<whitequark>
Xilinx is not the only or the best FPGA vendor
<whitequark>
and we were talking about ice40 single port ram
<azonenberg>
ah ok
<whitequark>
which is just a SRAM macro
<whitequark>
on ECP5 you can definitely omit BRAM init commands
<azonenberg>
interesting
<whitequark>
and interestingly, you can initialize several BRAMs with one data block
<azonenberg>
i like the xilinx philosophy re that, undefined behavior is a bug so kill it
<whitequark>
so no matter how many zeroed BRAMs you have, the size is almost the same
<tnt>
azonenberg: but there are also resets without reboot of the whole fpga in which case bram/dist ram content is ... whatever is left from the previous run. And I'd rather my simulation shows me that as 'x' to make sure it doesn't break my logic.
<azonenberg>
xilinx has that if you enable compression
<whitequark>
ah
<azonenberg>
its basically frame based lempel-ziv
<whitequark>
I'm not sure if that's actually xilinx philosophy
<whitequark>
oh!
<azonenberg>
rather than having content you have a header that says "go back and load frame X from before"
<whitequark>
they have X on bram output with some combination of BRAM port modes
<azonenberg>
i think thats only if you have a read-write collision under certain conditions on the same address
<whitequark>
yes
<azonenberg>
Which IMO should be a fatal timing error
<whitequark>
no
<azonenberg>
and abort sim
<whitequark>
it's perfectly well defined on every other FPGA
<azonenberg>
I like -Werror :p
<whitequark>
(usually, old data is read)
<whitequark>
I like BRAMs that behave sensibly
<azonenberg>
xilinx has several different modes
<azonenberg>
you can read the old data or the new data
<azonenberg>
there's optional forwarding
<azonenberg>
the issue is if you have a dual port ram and you have both ports write the same address
<azonenberg>
Or if you read the same on one port and write on the other port, but with offset clocks
<azonenberg>
this isnt a xilinx issue, asic srams have the same problem
<whitequark>
the latter is a timing error, definitely
<azonenberg>
its an inherent issue with 8t sram
<whitequark>
the former is not
<whitequark>
hm
<azonenberg>
when you activate both sets of row drivers
<azonenberg>
basically you have an internal bus fight
<whitequark>
so you could add a comparator that inhibits one of them
<azonenberg>
That is something you'd do in your design
<whitequark>
but xilinx has forwarding in silicon
<azonenberg>
Yeah
<whitequark>
why not add the comparator in silicon too?
<whitequark>
it's cheaper there, too
<azonenberg>
You'd also have to add a config bit saying which one to inhibit
<azonenberg>
to keep the ram symmetric
<whitequark>
sure
<azonenberg>
but yeah i would support such a design
<whitequark>
ah, another issue with xilinx is that they don't actually respect the behavioral memory models
<whitequark>
the same behavioral model can get synthesized as BRAM and DRAM and you end with different semantics
<whitequark>
their "solution" is to copy their macro exactly, which directly contradicts 1364.1-2002
<daveshah>
Xilinx Ultrascale+ URAM (288kbit blocks) is uninitializable and I think starts up undefined
<daveshah>
It's a single clock RAM, and has sensible collision behaviour iirc
gsi__ is now known as gsi_
<azonenberg>
ultraram is double pumped
<azonenberg>
So it has well defined collision semantics becuase there isnt a bus fight
solo1 has quit [Quit: WeeChat 2.4]
<azonenberg>
i.e. port X happens then port Y
<azonenberg>
i forget the ordering
<azonenberg>
internally it's 6T cells
<azonenberg>
But this is very different from 8T SRAM which allows true dual clock operation but also can have collisions
<whitequark>
yes but it's still uninitializable and undefined at start
rohitksingh has joined ##openfpga
<azonenberg>
ok fair enough
flea86 has quit [Quit: Goodbye and thanks for all the dirty sand ;-)]
<ZirconiumX>
The thing I hate most about IE{EE,TF} standards is that they're just numbered and you're expected to recognise them, but somebody could be like "This is a direct contradiction of IEEE 1584" and I'll just smile and nod.
<whitequark>
I have a huge stash of standards and desktop search so it's not such a huge issue...
<emeb>
instant citation - just don't try to peer beneath the surface.
<whitequark>
also nobody in the world will recognize IETF RFCs
<whitequark>
TCP alone is defined by like fifteen RFCs, none of which make any sense in isolation, and none of which are of much use if you're building a real-world high-performance stack
<whitequark>
grumble grumble
<gruetzkopf>
this directly contradicts IEEE 1284, IEEE 1394 and IEEE 1588
<whitequark>
1284 is parallel port, 1394 is firewire, and 1588 is ... ptp?
<gruetzkopf>
yes
<whitequark>
what about IEEE 69 and IEEE 420
<gruetzkopf>
(at least it's not IEEE 802.5)
<gruetzkopf>
oh IEEE 420-2013 is a fun one
<gruetzkopf>
IEEE 420-2013 - IEEE Standard for the Design and Qualification of Class 1E Control Boards, Panels, and Racks Used in Nuclear Power Generating Stations
* gruetzkopf
applies shibboleth to IEEE website
<whitequark>
I cant seem to find IEEE 69
<gruetzkopf>
power distribution stuff
<emeb>
the nice thing about standards is that there are so many to choose from
<gruetzkopf>
okay, i got 420-2013
forrestv has quit [Ping timeout: 252 seconds]
rohitksingh has quit [Ping timeout: 268 seconds]
forrestv has joined ##openfpga
ZipCPU|Laptop has joined ##openfpga
ZipCPU|lapt0p has joined ##openfpga
ZipCPU|lapt0p has quit [Remote host closed the connection]
mossmann has quit [Ping timeout: 245 seconds]
yhetti has quit [Ping timeout: 244 seconds]
Richard_Simmons has joined ##openfpga
Bob_Dole has quit [Ping timeout: 250 seconds]
<_whitenotifier-3>
[whitequark/Boneless-CPU] whitequark pushed 2 commits to master [+0/-0/±7] https://git.io/fjXfz
<_whitenotifier-3>
[whitequark/Boneless-CPU] whitequark 649e050 - gateware.core_fsm: fix legacy implementation to run on new nMigen.
<kc8apf>
ZirconiumX: feel free to ping me about bitstream <-> RTL conversions. I wrote a fair amount of the low-level parsing for prjxray. Coming up with a decent abstraction for that stuff is challenging
<ZirconiumX>
kc8apf: come join us in #prjmistral; the more the merrier
<kc8apf>
*sigh* another channel to monitor
<ZirconiumX>
You don't have to monitor it
<ZirconiumX>
But "kc8apf" is perhaps not the most memorable of names
<kc8apf>
it is globally unique though
ZipCPU|Laptop has quit [Ping timeout: 245 seconds]