Forum Discussion

hcom's avatar
hcom
Icon for Occasional Contributor rankOccasional Contributor
4 years ago
Solved

How to constrain a source-synchronous FPGA input?

I have a source-synchronous input to my Cyclone 10 GX (10CX085) FPGA, coming from an external chip whose datasheet gives the following information: f max = 300 MHz (single data rate) t setup = ...
  • hcom's avatar
    3 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:

    1. The refclk and strb pins (two FPGA pins) must both be driven by the same external clock.
    2. 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.