zng has quit [Quit: ZNC 1.8.x-nightly-20181129-f3eca21b - https://znc.in]
zng has joined #m-labs
<attie>
whitequark: memory inferrence is really messy, but the way migen describes it is calqued on how xilinx wants you to do it. The tools strongly encourage you to use NO_CHANGE preferentially, to the point of printing a message every time you use something else.
<attie>
but they also straight-up assume that you will never have an address collision between different ports
<attie>
despite the verilog that they are inferred from having very clear behavior for that case, the synthesizer will happily ignore it and implement something that does the complete opposite.
<attie>
there are still unresolved SyncFIFO bugs in the code from this.
<attie>
I spent about a month last year looking into this, but I couldn't find a portable solution.
<attie>
I guess the only way around that bug would be something like Memory() being specialized by platform to instantiate the BRAM with the right settings, with the inferrable verilog as a fallback.
<whitequark>
attie: WTF
<whitequark>
well the Xilinx synthesizer is a piece of shit then.
<whitequark>
but thanks for mentioning.
<whitequark>
one more item in the list titled "however immature open-source FPGA tools are, the vendor tools manage to outmatch them each time"...
<attie>
there's still an old PR hanging around with a partial fix that can't be applied cause it breaks for non-xilinx
<attie>
PR #105
<whitequark>
that is horrifying. but at least in nmigen you could use attr translation to do this.
<attie>
I can sort of understand why they do it that way, once they designed their BRAM the way they did
<attie>
it's either that or never infer BRAM at all
<whitequark>
how did they do it?
<whitequark>
I don't remember their design offhand
<attie>
if the write port is in read-first mode the collision is ok
<attie>
otherwise the read port has undefined behavior
<whitequark>
hrm
<whitequark>
attie: wait.
<whitequark>
this doesn't seem right.
<whitequark>
the default mode is WRITE_FIRST, and nothing in misoc or artiq ever switches it to NO_CHANGE.
<whitequark>
how come artiq works at all?
<attie>
write first and no change have the same behavior mostly?
<attie>
it's only different for r/w on the *same* port iirc
<whitequark>
yeah, NO_CHANGE only considers the same port
<whitequark>
that's my whole problem with it
<whitequark>
it does this weird thing where each write port is paired with a read port whether you want it or not
<attie>
that's how xilinx BRAM is
<whitequark>
yeah, but migen is not called xigen
<attie>
it's... extremely inspired by the Xilinx user guide chapter III, HDL coding styles
<whitequark>
well that's depressing
<whitequark>
i *guess* i'll have to delete enough anime to make space for vivado again.
<attie>
which is frankly how you have to write verilog if you want anything approaching sensible output from the xilinx tools.
<whitequark>
ah no, i have the piece of shit installed here already.
<whitequark>
what frontend does xilinx use anyway?
<attie>
they don't really accept verilog input. they accept a sequence of macros.
<attie>
no idea, their own proprietary mess i assume?
<whitequark>
right, this doesn't sound like synopsys
<attie>
I wonder if you could go from rtlil directly to edif netlist.
<whitequark>
write_edif ?
<attie>
avoid the whole "going through a language that was never made to describe the thing we want to do" rigamarole
<whitequark>
but that won't work because nmigen generates yosys coarse grained cells
<whitequark>
not xilinx
<attie>
well, I guess you'd need write_xilinx_edif then...
<attie>
(I have no idea what goes into that. I briefly flirted with the idea about...6 years ago?)
<whitequark>
I *think* I could coerce Yosys into generating the sort of HDL Xilinx tools will recognize
<whitequark>
(there is a very good russian expression for this kind of thing that is unfortunately too obscene to actually mention)
<attie>
right, this is a Very Professional channel
<whitequark>
attie: any idea if Xilinx will at least accept memory init in form of an initial block and not $readmemh?
<attie>
no idea
<attie>
user guide says yes
<attie>
integer i; initial for (i=0; i<DEPTH; i=i+1) ram[i] = 0; end
<whitequark>
ok cool, so the yosys generated verilog stands a chance of being acceptable as is
<whitequark>
attie: ugh, xilinx block rams are corrupted if you asynchronously reset the FFs driving them
<whitequark>
of course, this is exactly what you want to do to reset an AsyncFIFO
<whitequark>
(reliably, that is)
<attie>
asynchronously to which clock, the one driving the port in question?
<whitequark>
yeah
<whitequark>
I mean it doesn't matter for resetting AsyncFIFO.
<whitequark>
(because if you reset it you don't care what happens to the data)
<attie>
right
<attie>
I gave up and made my design non-resettable at some point because of block ram
<attie>
slowly inching my way back these days to a point where I might not have to reprogram the FPGA every time
<whitequark>
hmm I'm really unhappy with this AsyncFIFO behavior because it screws Glasgow over
<whitequark>
so I fixed it properly in nmigen, nmigen has async reset now
<attie>
is glasgow based on a xilinx fpga?
<whitequark>
thankfully it is not
<whitequark>
and will never be
<whitequark>
the current revision is based on Lattice iCE40, which is a small but very nicely designed deivce
<whitequark>
the next on Lattice ECP5
<whitequark>
which is also refreshingly simple architecture wise
<whitequark>
like you can actually just take the transceiver primitive and get it to work. i had to reverse-engineer it a little bit, but the whole thing took me less than 24 hours from never using a transceiver to getting 8b10b data via PCIe
<whitequark>
reverse-engineer here meaning "look up what port and parameter names their cell uses", mostly
<whitequark>
the main problem with Lattice is that they have several departments capable of producing nice silicon, nice docs and reasonably nice tools, but they do not talk to each other
<attie>
*gasp* an fpga without overengineered bloated hardblocks stuffed with bugs because "never mind we can fix it in post"?
<whitequark>
yes. that's ECP5.
<whitequark>
actually i've yet to stumble on a bug in ECP5 or iCE40
<whitequark>
the worst problem I've had with ECP5 was that the bit names in docs, ip generator, register map, and primitive basically never match each other
<attie>
heh. every employee has their own private naming scheme?
<whitequark>
more like every department?
<whitequark>
they're not like super different. it's that, e.g. the one that was doing the fabric added ff_ (for "fabric feed") to every signal name so the cell has those.
<whitequark>
but the one that was doing SERDES IP and documenting it has only learned about that late in the cycle so it's mentioned once in a footnote
<whitequark>
really, i wish all of my FPGA problems were that bad.
<attie>
yeah, that sounds benign
<attie>
you can probably Ctrl-F that footnote looking for "ff_"
<whitequark>
it's mostly that there is no complete description of the SERDES primitive
<whitequark>
so I had to guess that, and also infer from one of the names that it has an undocumented power down pin, etc
<whitequark>
not *really* an issue
<cr1901_modern>
>xilinx block rams are corrupted if you asynchronously reset the FFs driving them
<cr1901_modern>
This seems... bad if e.g. you're executing a program from block RAM and you use async reset to, say, reset the PC.
<whitequark>
well yes
<whitequark>
their workaround is to "not do that"
<cr1901_modern>
"Doctor, it hurts when I asynchronously reset the BRAM"
<cr1901_modern>
Someone (I'll do it if I ever get my hands on one) should test an Altera part too in case there are fun surprises.
<cr1901_modern>
whitequark: What are you unhappy with when you say _this_ AsyncFIFO behavior (1:14:36 AM)? The existence of NO_CHANGE? The fact that async reset corrupts your data? Or both?
<whitequark>
right now if you reset the read or write asyncfifo domain
<whitequark>
you start reading stale data.
<cr1901_modern>
right now as in old migen/sync reset?
<whitequark>
well, asyncfifo doesn't exactly get reset
<whitequark>
yu can reset one half of an asyncfifo
<whitequark>
which never does what you want
<whitequark>
really, it should be either reset completely or reset_less
<cr1901_modern>
I'll have to take a look when I wake up; you explained that you're using async reset b/c "no guarantee the consumer clock will be present". But without that restriction, why can't you in principle make the produce/consume reset signals both reset synchronously using a pulse stretcher?
<whitequark>
you can
m4ssi has joined #m-labs
uberardy has quit [Quit: uberardy]
cr1901_modern has quit [Read error: Connection reset by peer]
hartytp has joined #m-labs
<hartytp>
sb0: I'm starting to think about plans for Sayma v2.0
<hartytp>
my initial thought is this
<hartytp>
I won't do any work on it until you get RTM DRTIO up and running
<hartytp>
at that point you can work on fixing any bugs and generally getting support for unsynchronised SAWG rock solid
<hartytp>
in parallel to that, I was thinking of moving the DAC control to a kernel
<hartytp>
then implement the sync in much the same way as Urukul
<hartytp>
it feels like it will be much easier to develop and debug the code from kernels
<hartytp>
I'd move all DAC SPI to kernels and expose a few functions to control the JESD core
<hartytp>
what do you think?
hartytp has quit [Ping timeout: 256 seconds]
rohitksingh_work has quit [Read error: Connection reset by peer]
ElementW has quit [Quit: -]
rohitksingh_work has joined #m-labs
rohitksingh_work has quit [Read error: Connection reset by peer]
dlrobertson has quit [Quit: WeeChat 2.3]
sb0_ has joined #m-labs
<sb0_>
why does it need rtm drtio?
<sb0_>
not enough pins to drive the FF from AMC?
<sb0_>
we can probably move to kernels, the reason it's done in rust was the potential dependency of drtio on the clock tree. and since the hmc7043 is tightly interfaced with the DAC, it made sense to control the DAC from the runtime as well
sb0_ has quit [Quit: Leaving]
cr1901_modern has joined #m-labs
awygle_ has quit [Quit: No Ping reply in 180 seconds.]
awygle has joined #m-labs
<sb0>
whitequark: can those transceivers be easily operated in fixed-latency mode?
<sb0>
i.e. align the clock divider to the comma, not keep whatever divided clock is there and barrel-shift data to align the comma
<sb0>
this is very annoying to do with xilinx
rohitksingh has joined #m-labs
rohitksingh has quit [Remote host closed the connection]
<cr1901_modern>
>not keep whatever divided clock is there and barrel-shift data to align the comma
<cr1901_modern>
Is this what Xilinx IP does?
<whitequark>
sb0: hmm, good question
<whitequark>
sb0: I can't seem to find many details in the UG, but there is a control register that has two mode
<whitequark>
"bitslip word alignment mode" and "barrel shift word alignment mode"
<whitequark>
would the former be what you want?
<whitequark>
it says in re: en_bitslip signal elsewhere:
<whitequark>
SerDes Word Alignment to shift byte clock by 1 UI
<whitequark>
1 = Slip Rx byte clock by 1 UI for Word Alignment