Lattice ICE5LP4K Propagation Delay

[Evan.Cornell]

I've got a design using ICE5LP4K-SG48ITR. One part of the design is clocking out data from upper bit of a shift register on the falling edge of input clock. What I see on ModelSim simulation looks beautiful and ideal, but what I see on the scope is that the data output pin doesn't change value until about 12ns after falling edge of input clock.

This delay is causing a problem on the receiving IC, since that 12ns delay causes the setup time to be too short for data to be read on the next rising edge of the clock. I effectively am receiving in all this data shifted by 1 bit.

Looking at the Typical Building Block Function Performance section in the iCE40 Ultra Family Data Sheet, I'm seeing values like this:

Pin-to-Pin Performance (LVCMOS25)
16-bit decoder - 16.5ns
4:1 MUX - 18.0ns
16:1 MUX - 19.5ns

This datasheet data makes me think the ~12ns delay from falling input clock edge to data output change is reasonable and inherent to the propagation delays within the FPGA itself.

Questions:
1. Am I correct in thinking that the 12ns delay is just inherent to iCE40 FPGA propagation delays?
2. Is there anything I can do to reduce the delay with the existing FPGA?

[SiliconWizard]

I suppose you are feeding the clock directly to an external chip from which you read?

[Evan.Cornell]

I suppose you are feeding the clock directly to an external chip from which you read?

External IC generating clock feeding to FPGA.
FPGA generating data line feeding back to external IC.

[SiliconWizard]

So the FPGA acting as a SPI slave.

[Evan.Cornell]

So the FPGA acting as a SPI slave.

Not SPI, I2S rather, but the same idea.

[SiliconWizard]

So the FPGA acting as a SPI slave.

Not SPI, I2S rather, but the same idea.

Yes same thing. What's the serial clock frequency?

[Evan.Cornell]

Yes same thing. What's the serial clock frequency?

24.576 MHz (~40ns total period)

[SiliconWizard]

As you figured, 12ns of total propagation time doesn't look unreasonable for this type of FPGA.

My thought here is that you may not be changing data on the proper edge of the clock.

[Evan.Cornell]

As you figured, 12ns of total propagation time doesn't look unreasonable for this type of FPGA.

My thought here is that you may not be changing data on the proper edge of the clock.

Indeed. Well, if propagation time was ideal as in simulation, then I'm already doing everything properly.

My plan to fix was to change data on rising clock edge, which is, in fact, what edge the external IC is latching data in (I2S data format, not MSB/LSB), but due to propagation delay of FPGA, ought to result in proper data.

[SiliconWizard]

Yes, with I2S, data changes on falling edges and typically sampled on rising edges.
A half period is about 20ns, data would still be 8ns early. Are you sure that's not enough for your I2S device?

Now, apologies if you know I2S very well and the following all sounds obvious to you, and you are sure this is not the culprit:
The WS (word select) line changes states on the LSB of the previous word rather than on the MSB of the current word, which is something many people not used to I2S often fail to handle properly when hand-coding a I2S interface. This would of course result in a shift of one bit.
https://upload.wikimedia.org/wikipedia/commons/thumb/a/a7/I2S_Timing.svg/500px-I2S_Timing.svg.png

[Evan.Cornell]

The external IC requires 12ns early time, unfortunately. And yes, understand well the 1-bit early, that is definitely already accounted for. My scope's logic analyzer protocol decoder already decodes the data properly, just not the external IC. Appreciate the input!

[SiliconWizard]

OK then, that's unfortunate. What's the chip you're using?

You can try optimizing the logic path to reduce the propagation delay, although I suppose you have already done what you could for this part. If unsure, you can check the number of logic levels and try shortening the path.

If that's not possible, then yeah, changing the data on the preceding rising edge should work, but in this case, it will explicitely rely on the longish delay - the same code on a faster FPGA could fail.
So, if you do this, it would be a good idea to comment it in your code.

[dmendesf]

Can't a clock to output constraint solve this?
https://www.latticesemi.com/~/media/LatticeSemi/Documents/UserManuals/RZ/Timing_Closure_Document.pdf

[asmi]

Have you tried the classic solution to this problem - forwarded clock? Bring a clock out on one of FPGA pins and connect it to your I2S slave device instead of external clock, and set up output constraints which relate to that forwarded clock.
Another pretty common solution is to use PLL to adjust the phase of the clock which clocks output flip-flops (or all design altogether if there are no specific requirements for clock). I don't know if PLL inside that FPGA can do that, but if it can, that can also be an option.
Finally the most "hacky" solution is to run output FFs at multiple of clock frequency, and use those intervals as poor man's output delay blocks. For example, if you run your output FFs at 4x frequency, and add an extra 1,2 or 3 periods of fast clock worth of delay. You can measure delay required and experiment with those delays to see which one works best.
Option 1 is the best of those, but other two allow to somewhat resolve the problem without changes to the PCB.

[Evan.Cornell]

So I believe I've gotten something work-able.

• Shift data out on clock rising edge
• Offset data by an extra bit to get the word to line up properly
• add falling edge clock to output data line constraint

These changes seem to have resulting in something reasonable.