<whitequark>
tnt: more observations. if i make the arbiter FSM go in circles between SETUP-IN and XFER-IN (i.e. replace all ways it can go to NEXT with SETUP-IN) then it is still broken
<whitequark>
this excludes FIFOADR and SLOE/FDOE signals
<whitequark>
and reduces our set of possible signals that cause the issue to FLAGC, SLWR, and FD
<whitequark>
i think the timings are wrong with one of these
<gruetzkopf>
i have my scope and glasgow handy if i need to look at any of these (and they're accessible)
<whitequark>
gruetzkopf: they're not super accessible
<whitequark>
worse yet it's a marginal event
<whitequark>
one in several hundred i think
<tnt>
whitequark: are you later tests done on the up5k or the hx8k ?
<gruetzkopf>
i mean i can tack on some awg30 magnet wire, that's not too bad
<tnt>
what's IF_CLK frequency btw ? 30M ?
<whitequark>
tnt: up5k and 30m still
<whitequark>
interestingly hx8k still has very similar issues apparently
<tnt>
Mmm, SLRD has a much longer setup time requirement than I originally noted in my analysis.
<whitequark>
ah
<whitequark>
interesting
<whitequark>
what about SLWR?
<tnt>
No, SLWR is what I looked at previously. 10.4 ns setup time. (and I rounded to 11 ns in the diagram).
<tnt>
But SLRD is 18.7 ns.
<tnt>
But still ... that leaves a 3.6 ns margin @ 30 MHz between worst case clock-to out of ice to worst case setup of FX2
<whitequark>
hm
<tnt>
I'll re check the ICE clock to out and setup/hold numbers in icecube.
<whitequark>
tnt: btw, have you seen the commit that *does* work?
<whitequark>
it doesn't use SB_GB_IO *or* registered SB_IO for the bus
<whitequark>
that's clearly wrong in general, because it results in unpredictable timings
<whitequark>
but in this specific case it seems to give better results
<tnt>
yeah, the problem is I can't run that commit through icecube and expects the same result :p and I can't run a placed/routed design through icecube timing analyzer either.
<whitequark>
ahhh
<whitequark>
i can test an icecube bitstream
<tnt>
also, without the SB_GB_IO it also wasn't working on my glasgow at all so ... very much specific to your setup :p
<whitequark>
right
<whitequark>
unsurprising
<tnt>
whitequark: it's the video-rgb-input you use for testing ?
<tnt>
ah yeah, indeed that works with all the args.
<tnt>
Mmm, ... synthesis has been running for the past 6 minutes ...
halkyardo has joined #glasgow
<tnt>
Ok, so icecube really doesn't like the ram description generate my migen.
<whitequark>
huh
<tnt>
among other things it really wants the size of the ram to be a power of 2 apparently.
<tnt>
Also apparently PIN_TYPE(6'd52) != PIN_TYPE(6'b110100) for icecube :/
<whitequark>
ugh, yeah
<tnt>
Mmm ... rising and falling edge setup/hold time requirements are different.
halkyardo has quit [Ping timeout: 245 seconds]
<tnt>
Doesn't really change the result though. Data capture window starts at the edge rather than 1.3ns after it but still ... plenty of margin.
halkyardo has joined #glasgow
<whitequark>
hm, strange
<tnt>
Mmm ... I'm actually wondering if that's something than nextpnr takes into account. Because in that internal re-register the path actually needs to be 1.3 ns faster than you'd expect from just halfing the period.
<tnt>
Wait ... is the IFCLK 50/50 ?
<whitequark>
it should be, yes
<whitequark>
lemme poke it with a scope
halkyardo has quit [Ping timeout: 255 seconds]
halkyardo has joined #glasgow
<tnt>
Mmm, yeah, I had some trouble finding it, but it does say 49-51% duty cycle and 300 ps jitter.
<tnt>
So "synchronous fifo write" is what's failing right ?
halkyardo has quit [Ping timeout: 255 seconds]
<whitequark>
tnt: yes, it's 50±1% as measured by my scope
<whitequark>
and yes
<whitequark>
that's what's failing
<whitequark>
tnt: iirc when i was debugging this "visual snow" many months ago, i found that the last byte in the transmission was the one that was bad
<whitequark>
i can re-verify this, although that will take work
<tnt>
I rechecked and I can't see any setup/hold time violation the way data are output / captured now.
<tnt>
So either I'm misunderstanding something somewhere, or there is a logic error somewhere :/
<tnt>
Oh wait ..
<tnt>
FIFOADR needs to pretty much be valid 1 cycle before the first write anything and 1 cycle after the last write.
<tnt>
I missed that spec because it's not at the same place as the others ...
halkyardo has joined #glasgow
<whitequark>
tnt: that should be handled fine though...
<whitequark>
I've tried adding wait states before and after changing FIFOADR, no effect
halkyardo has quit [Ping timeout: 246 seconds]
halkyardo has joined #glasgow
halkyardo has quit [Ping timeout: 246 seconds]
halkyardo has joined #glasgow
halkyardo has quit [Quit: WeeChat 2.4]
<whitequark>
tnt: think you could take a look at my FSM as well?