<Guest30>
Hi everyone! Not sure if this is the right place for such questions, but anyway. I'm trying to figure out whether iCE40 is the right FPGA for my hobby project that involves ADC with 70-80 MHz serial bus, so obviously I need to do some nanosecond timing math... Does yosys/nextpnr-ice40 have some timing info for IO buffers? So far I only see that
<Guest30>
nextpnr reports e.g. output pin critical path latencies between e.g. "posedge clk" and "...$sb_io.D_OUT_0 / D_OUT_1". Is there any (approximate) info on the delay between D_OUT_x and the actual hardware pin? Also would be curious to know the same for input side of things (delay, or ideally setup/hold requirements for a pin that registers input with
<Guest30>
a DFF and puts it onto D_IN_x). Wasn't able to find this info in the datasheet. Most probably iCEcube2 could've helped there, but a.t.m I have neither the tool nor the license for it..
ec has quit [Ping timeout: 276 seconds]
<tnt>
There is no IO timing info in the open toolchain at all.
<tnt>
Which iCE40 device are you considering ?
<Guest30>
HX4K in TQFP144 package
<tnt>
HX will have 2.6~2.8 ns clock to out (from the internal clock edge to the moment it hits the externa IO).
<tnt>
It has 1.0~1.4 ns setup time on IOFF input (relative to the internal clock edge)
<Guest30>
Hm.. Thanks for the numbers :-) Where did you get that data, iCEcube2?
<tnt>
And ~ -500 ns hold time (negative hold time) again, against the internal clock edge.
<tnt>
yes, from icecube 2, made some test veriog, wrote down the numbers.
<mwk>
umm... units?
<tnt>
oh sorry, -0.5 ns ...
<tnt>
(I wrote it down in ps ...)
<mwk>
yeah, microsecond-order IO timings would be obviously wrong
<mwk>
~unless you're dealing with insane FPGA such as UltraScale~
<tnt>
you can probably skip the first 30 min or so.
<Guest30>
tnt ok, thanks, will check
<Guest30>
BTW, I could've searched first through the git before asking... there seems to be a timing DB in icestorm: https://github.com/YosysHQ/icestorm/blob/master/icefuzz/timings_hx8k.txt . Next to it is timings.py script which can convert it to HTML format. And it lists e.g. IO, PRE_IO cells with PACKAGEPIN wires, so I guess I can look into there if I
<Guest30>
need more info :-)
<Guest30>
But I guess nextpnr just does not use / show all the data from it.
ec has joined #yosys
nelgau_ has joined #yosys
ec has quit [Ping timeout: 276 seconds]
<Guest30>
Wow. The difference between registered and unregistered output latency is impressive. Registered output will have 309ps for glbclk->OUTCLK + 140ps for OUTCLK->PADOUT (output ff) + 2353ps for PADOUT->PACKAGEPIN (output buffer), 2802ps in total from clk to pin (matches quite well with 2.6~2.8ns number above, I took worst-case numbers from the
<Guest30>
timings). OTOH, unregistered output will have 2237ps for DOUT0->PADOUT + 2353ps for PADOUT->PACKAGEPIN, 4590 ps in total, and this not including all the routing needed to get the signal on DOUT0.
<Guest30>
This confirms my occasional thought that if you want to output internal FPGA _clock_ onto the pin, and you want minimal skew, it's better use registered DDR output instead of casually routing clock through the fabric to DOUT0/1 and then running it straight to the pin without FFs.
<mwk>
that's pretty much the standard procedure for doing this
<mwk>
for source-synchronous applications
<Guest30>
ok, didn't know that :-) (I'm just beginning with FPGAs)
vidbina has joined #yosys
<tnt>
yeah, it's not even a choice unless you work at trivially slow speeds.
nelgau_ has quit [Remote host closed the connection]