<Hoernchen_>
please document that somewhere so someone can take a look at it
<Hoernchen_>
but tbh.. the ddr pins should be fine up to ~400Mhz or something like that, so well above 125mhz rgmii
<Hoernchen_>
well below the 1.25gsps xilinx claims for all of their ios, but still..
jk- has quit [Remote host closed the connection]
Hammdist has joined #litex
ElfenKaiser has quit [Quit: Konversation terminated!]
<Hammdist>
I thought of doing one last experiment on the versa board. I put a copy of the expected rx packet in a BRAM. now when I send packets it counts the number of errors in each of the 8 GMII bit positions. this produces basically a fingerprint of io cell performance that should not vary if I recompile my design (which would normally produce slight
<Hammdist>
variations in P&R). indeed it did not vary. switching to the other port produced a different fingerprint that again didn't vary when I recompiled the design. so barring some terrible misunderstanding of how RGMII is supposed to be hooked up to the FPGA, and assuming the delay values are OK (which I've checked several times now), I think it must be
<Hammdist>
a flaw in the io cell design, however improbable that may seem a priori
<Hoernchen_>
uh
<Hoernchen_>
the actual test is to use diamond to synthesize the design with proper constraints and/or io buffers
<Hammdist>
well I suppose it's possible that there's a bug in nextpnr that causes it not to configure DDR correctly, or cause arbitrary other problems. I don't have diamond installed though and I don't have experience using it. basically I need/want to use an open source toolchain so it's not practically helpful to me if it works in diamond
<Hoernchen_>
without diamond your io timing is basically guessing and hoping that it just works..
<Hammdist>
what do you mean by I/O timing, exactly? I expect nextpnr measures the delay from where logic outputs to where the ODDR is, doesn't it?
<Hammdist>
is there additional travel from ODDR to pin that isn't accounted for, or what?
<Hammdist>
I don't know what to make of this info. on the one hand this seems to a huge blind spot and that if I can learn about these I/O issues I can potentially improve my design. on the other hand there seems to be only a very small trickle of information on this topic
<Hammdist>
is there a chance that blindly applying -iopad would just automatically fix things?
<Hoernchen_>
well you could give it a try..
<Hoernchen_>
but, again, without running diamond at least once you're pretty much guessing
<Hammdist>
well -iopad did ... nothing
<Hammdist>
anyways none of this is litex-specific. I will ask more about I/O constraints in the ##fpga channel tomorrow
<Hammdist>
maybe I will put together a super-minimal tx-only mac that repeatedly broadcasts a fixed ethernet packet as a case study to see if the tx errors can be fixed with OFS1P3DX
<ysionneau>
hmm I'm trying to build a LiteX SoC with some Module I am writing, and abc9 dies saying something about a combinatorial loop : ERROR: Assert `no_loops' failed in passes/techmap/abc9_ops.cc:795.
<ysionneau>
by running the yosys cmd in debug I think I've understood that the issue might come from a FSM
<ysionneau>
the FSM seems to be translated in verilog as always @(*) and maybe the state <= next_state causes a loop
<ysionneau>
but I'm not sure...
<ysionneau>
has anyone ever got this issue?
<zyp>
yes, I had the same issue the other day, code that built fine with an older yosys refused to build after yosys switched to abc9 by default
<zyp>
in my case it was some logic in a FSM that caused a loop with some stream flow control signals
<ysionneau>
same here, I am using streams
<ysionneau>
(and a pretty recent yosys)
<ysionneau>
I'll try with -noabc9
<zyp>
yeah, -noabc9 worked for me, but it's better to fix the problem :)
<ysionneau>
which signal was giving you a comb loop ?
<zyp>
probably ready feeding into last
<Hammdist>
the two pieces of code seem to have different behavior though if I understand correctly. in the first, the else block is executed whenever we don't go to output state, but it is not the same in the second
<zyp>
no, the stream signals are moot unless the stream is valid & ready
<Hammdist>
cool, that's all right then
<ysionneau>
ah now it's nextpnr who is complaining about a comb loop
<ysionneau>
but this time I get a nice error message saying explicitely which signal is the problem
<ysionneau>
nice
<ysionneau>
ah, found my issue ... I was doing s.eq(s+1) in a fsm.act() instead of NextValue(s, s+1)