Forum Discussion
How to constrain a source-synchronous FPGA input?
- 4 years ago
The timing requirements can be met using PHY Lite. Unfortunately, the PHY Lite documentation is atrocious. This led to a protracted nightmare of failed Intel "support" here and then here.
Eventually, my company was somehow able to contact an engineer at Intel, who solved the problem immediately.
In summary:
- The refclk and strb pins (two FPGA pins) must both be driven by the same external clock.
- There is a bug in all versions of Quartus up to and including 21.4, which prevents the IO delay chains from being configured correctly. Therefore, the design will typically fail timing, even if everything has been configured correctly. As a workaround (until the bug is fixed in Quartus 22.1), the IO delay chains can be configured manually (see details below).
Here is the content of the (excellent) E-mail:
Quartus should automatically change the IO delay chain settings such that each IO is optimized for both setup and hold however there appears to be a problem with the automatic delay chain calculation algorithm in 21.3 which is why you are seeing lots of hold violations while your setup looks good. I have checked in 21.4 and can confirm that the same issue exists in that version too. I can however confirm that this issue has been resolved in the latest internal release of 22.1 which is due for release very soon. As a temporary solution (prior to the release of 22.1) you can manually set the IO delay chain values using the assignment below. set_instance_assignment -name IO_12_LANE_INPUT_DATA_DELAY_CHAIN 60 -to InData You can apply this to all InData pins (as in the assignment above) however to get the optimum solution you will need to apply different values on a per-pin basis which is also supported. I am looking at what specific settings are required to close timing and will update you in due course. You can see the delay chain values used in the "Delay Chain Summary" section of the Route Stage report. I tested the assignment above in 21.3 and the interface closed timing. With regard to the refclk versus the strobe, ideally these should both originate from the same clock source such that they are PPM aligned. This will prevent the internal FIFO within the PHYLITE IP from overflowing/underflowing. The simplest solution is to connect the same clock on your board to both the strobe and refclk pins of the device.
We applied these changes in our project and it met timing. Correct behavior has been confirmed in simulation.
When you say that it failed timing catastrophically, what exactly is failing? Can you show waveforms and numbers from the timing analyzer?
Your constraints look good. Does the -waveform with the Tcl variables in quotes work correctly? Normally those would be [] around the actual values.
@sstrell Thank you for your reply.
Both setup and hold timing fail on the first flip-flop. Here is the setup timing analysis:
And here is the hold timing analysis:
As you can see in the Waveform panes, the -waveform SDC command is being picked up correctly (and there are no warnings about this). In the Intel examples that I used as a reference, they use curly braces to form a string literal {1.23 4.56}. I just used double quotes so I could evaluate variables "$var1 $var2" without having to delimit the $ with a \.