I have a source-synchronous input to my FPGA (an Intel Cyclone 10 GX 10CX085), coming from an external chip whose datasheet gives the following information:

  • fmax = 300 MHz (single data rate)
  • tsetup = 0.4 ns
  • thold = 0.5 ns

Using an oscilloscope, I can see the data is "center-aligned" (such that the data values are stable near the rising edge of the clock).

I have stripped my whole design down to two flip-flops and I still struggle to meet timing, even if I heavily relax the timing constraints. The whole Quartus project can be downloaded from here.


By closely following Intel's free training course, I understand that for best timing performance I should instantiate a PLL (specifically, an IOPLL configured in "source synchronous" mode) and my timing constraints should be defined like this:

# Define input clock parameters
set period 3.333
set tsu 0.4
set th 0.5

# Define input delays
set half_period [expr $period/2]
set in_max_dly [expr $half_period - $tsu]
set in_min_dly [expr $th - $half_period]

# Create virtual launch clock
create_clock -name virtual_clock -period $period

# Create physical base clock (phase shifted by 180 degrees) on FPGA pin
create_clock -name Clk -period $period -waveform "$half_period $period" [get_ports Clk]

# Create generated clocks on the PLL outputs

# Set input delay constraints
set_input_delay -clock [get_clocks virtual_clock] -max $in_max_dly [get_ports InData*]
set_input_delay -clock [get_clocks virtual_clock] -min $in_min_dly [get_ports InData*]

This failed timing catastrophically, so I tried relaxing to a 10 MHz clock with an extremely generous thold = 25 ns:

# Define input clock parameters
set period 100
set tsu 0.4
set th 25

This also failed timing. However, if I manually adjust the phase of the PLL (to basically anything sufficiently larger than zero) then timing is of course met comfortably at 10 MHz:

enter image description here

This leaves me very confused about the following:

  • Are my requirements (300 MHz, 0.5 ns, 0.4 ns) feasible with this device?
    • If so, then how? (Timing contraints, PLL configuration, etc).
    • If not, then what performance is possible? (I can't see this information anywhere in the FPGA documentation).

Many thanks in advance for any help!

  • \$\begingroup\$ You don't have to give setup time in the expression for in_max_dly because it is a known quantity at capturing flop and is hence already incorporated by STA tool in the destination path. \$\endgroup\$
    – Mitu Raj
    Commented Dec 27, 2021 at 14:21
  • \$\begingroup\$ Is your timing analysis failing for hold analysis? \$\endgroup\$
    – Mitu Raj
    Commented Dec 27, 2021 at 14:22
  • 1
    \$\begingroup\$ A critical point is whether the FF is in the IOB (nice and fast) or in the FPGA fabric (unknown and probably long routing delay). You want it in the IOB for good I/O timings. (then you may need a second FF in the fabric to absorb the routing delay). I'm not current with Altera (cough Intel) FPGAs so can't make any tools suggestions. \$\endgroup\$
    – user16324
    Commented Dec 27, 2021 at 17:58
  • 1
    \$\begingroup\$ @MituRaj The terminology is commonly abused. Please refer to "Setup and Hold Method" on page 46 of AN433 or Section 3.12 of OCSS1000. \$\endgroup\$
    – Harry
    Commented Dec 27, 2021 at 18:07
  • 1
    \$\begingroup\$ @user_1818839 When I look in the "Resource Property Viewer" for the flip-flop, I can see it is implemented inside DDIOINCELL_X38_Y14_N35. As far as I understand, this is the dedicated IO register needed for good timing performance (by GPIO standards). I also tried explicitly setting FAST_INPUT_REGISTER on the data pins in the .qsf file and it gave the same result. \$\endgroup\$
    – Harry
    Commented Dec 27, 2021 at 18:23

1 Answer 1


Your exact timing requirements from the source seems a bit unclear?

tsetup = 0.4 ns. thold = 0.5 ns.

If you by these numbers really mean to say that the input signal is valid only during a 0.9ns window around the edge of the clock, then there is no way you can do this on an FPGA using just the phase shift of an IOPLL. You need a valid window of several nanoseconds for that to work. Hard to say what the exact limit is. It is essentially the sum of the IO and routing delay uncertainty, and PLL delay uncertainty

You need dedicated hardware to make it work with a valid window of only 0.9ns, and you are in luck: The Cyclone 10 has such hardware capability. It is called "phylite" and is used for high speed source synchronous interfaces such as DDR3.

Look it up in the cyclone 10 datasheets. It should do the job.

EDIT: Thanks - I have looked it up and, after a protracted battle with atrocious documentation and toolchain bugs, the details of a working PHY Lite solution can be found here:


  • 1
    \$\begingroup\$ Thank you. My interpretation of the datasheet is the same as yours (0.9 ns stable time). And after many hours of reading datasheets, I came the the same conclusion as you: PHYLite would be the solution. In my case, this means a PCB redesign because PHYLite requires signals to be routed to a "DQS group" (specific FPGA pins). The PHYLite documentation is very poor, so it basically says it can be used for this purpose, but not how. I will have some time to look into this while the hardware is redesigned. \$\endgroup\$
    – Harry
    Commented Jan 9, 2022 at 10:34
  • \$\begingroup\$ Note that the clock must be connected to a very specific pin for each DQS group. Probably 99% of the time phylite is used only for the provided DDR3 IP core, so I can well imagine that the documentation for custom uses might be somewhat lacking. \$\endgroup\$ Commented Jan 9, 2022 at 15:50
  • \$\begingroup\$ Thinking about it.... A SERDES IO might also be another option for you. But that depends a lot on what protocol you are implementing. \$\endgroup\$ Commented Jan 9, 2022 at 15:54
  • \$\begingroup\$ Also, when you are making the PCB. Be careful to match the length of the data and clock traces to within a millimeter or so. And make sure you route them on the same layer of the PCB. Otherwise your 0.9ns window will shrink even more. Look up DDR3 PCB design guidelines if you have never designed a board like this before. \$\endgroup\$ Commented Jan 9, 2022 at 18:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.