Lattice ICE5LP4K Propagation Delay - Page 1
Forum section: electronics / general

author: Evan.Cornell
author_rank: Regular Contributor
timestamp: July 15, 2023, 08:51:29 pm
content: 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.5ns4:1 MUX - 18.0ns16:1 MUX - 19.5nsThis 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?

author: SiliconWizard
author_rank: Super Contributor
timestamp: July 15, 2023, 08:57:48 pm
content: I suppose you are feeding the clock directly to an external chip from which you read?

author: Evan.Cornell
author_rank: Regular Contributor
timestamp: July 15, 2023, 08:59:02 pm
content: Quote from: SiliconWizard on July 15, 2023, 08:57:48 pmExternal IC generating clock feeding to FPGA.FPGA generating data line feeding back to external IC.

author: SiliconWizard
author_rank: Super Contributor
timestamp: July 15, 2023, 09:06:59 pm
content: So the FPGA acting as a SPI slave.

author: Evan.Cornell
author_rank: Regular Contributor
timestamp: July 15, 2023, 09:07:47 pm
content: Quote from: SiliconWizard on July 15, 2023, 09:06:59 pmNot SPI, I2S rather, but the same idea.

author: SiliconWizard
author_rank: Super Contributor
timestamp: July 15, 2023, 09:10:12 pm
content: Quote from: Evan.Cornell on July 15, 2023, 09:07:47 pmYes same thing. What's the serial clock frequency?

author: Evan.Cornell
author_rank: Regular Contributor
timestamp: July 15, 2023, 09:11:34 pm
content: Quote from: SiliconWizard on July 15, 2023, 09:10:12 pm24.576 MHz (~40ns total period)

author: SiliconWizard
author_rank: Super Contributor
timestamp: July 15, 2023, 09:14:10 pm
content: 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.

author: Evan.Cornell
author_rank: Regular Contributor
timestamp: July 15, 2023, 09:17:47 pm
content: Quote from: SiliconWizard on July 15, 2023, 09:14:10 pmIndeed. 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.

author: SiliconWizard
author_rank: Super Contributor
timestamp: July 16, 2023, 04:51:29 am
content: 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

author: Evan.Cornell
author_rank: Regular Contributor
timestamp: July 16, 2023, 03:31:54 pm
content: 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!

author: SiliconWizard
author_rank: Super Contributor
timestamp: July 16, 2023, 08:43:47 pm
content: 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.

author: dmendesf
author_rank: Frequent Contributor
timestamp: July 16, 2023, 11:45:38 pm
content: Can't a clock to output constraint solve this?https://www.latticesemi.com/~/media/LatticeSemi/Documents/UserManuals/RZ/Timing_Closure_Document.pdf

author: asmi
author_rank: Super Contributor
timestamp: July 17, 2023, 12:49:43 am
content: 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.

author: Evan.Cornell
author_rank: Regular Contributor
timestamp: July 17, 2023, 04:44:29 pm
content: So I believe I've gotten something work-able.Shift data out on clock rising edgeOffset data by an extra bit to get the word to line up properlyadd falling edge clock to output data line constraintThese changes seem to have resulting in something reasonable.