Cyclone 10 GX DDR interface timing / constraint issue

[designEngineer]

I am trying to meet timing on a source synchronous edge aligned DDR interface with a Cyclone 10 GX. The interface fails timing but I think the setup relationship from the DDIO output to the first regular register may be wrong in the timing analyzer (using a half clock cycle when it has a full clock cycle).

Quick description of the interface (also see attached diagram interface_diagram.jpg):

-------------------------------------------------------------------------------------

- 8 bit wide LVDS data input "DI"

- LVDS clock input DCLK running at 338 MHz

- data changes on both rising and falling edge of the clock (DDR)

- data is edge aligned to the clock input

- there are 3 more data inputs (DID, DQ and DQD which are not drawn in the diagram, they all use the same clocking and are just a replica of DI)

The input clock goes to a PLL which is outputting a clock with the same frequency (338 MHz) and no phase shift, this PLL output clock is then used to drive the DDIO instantiation as well as the first register after the DDIO.

I am wondering if my input constraints / exceptions are wrong. I came up with them based on the AN433 and they are as follows:

Constraints:

------------

derive_pll_clocks -create_base_clocks

derive_clock_uncertainty

create_clock -name dclk_ext_virt -period 2.958

# from AN433 Example 41 and 43

set_input_delay -max .05 -clock [get_clocks dclk_ext_virt] [get_ports {DI[*] DID[*] DQ[*] DQD[*]}]

set_input_delay -max .05 -clock [get_clocks dclk_ext_virt] -clock_fall [get_ports {DI[*] DID[*] DQ[*] DQD[*]}] -add_delay

set_input_delay -min .05 -clock [get_clocks dclk_ext_virt] [get_ports {DI[*] DID[*] DQ[*] DQD[*]}] -add_delay

set_input_delay -min .05 -clock [get_clocks dclk_ext_virt] -clock_fall [get_ports {DI[*] DID[*] DQ[*] DQD[*]}] -add_delay

# from AN433 Example 50

set_multicycle_path -setup -end -rise_from [get_clocks dclk_ext_virt] -rise_to [get_clocks i_adc|i_adc_pll_c10|iopll_0|outclk338] 0

set_multicycle_path -setup -end -fall_from [get_clocks dclk_ext_virt] -fall_to [get_clocks i_adc|i_adc_pll_c10|iopll_0|outclk338] 0

# from AN433 Example 51

set_false_path -setup -fall_from [get_clocks dclk_ext_virt] -rise_to [get_clocks i_adc|i_adc_pll_c10|iopll_0|outclk338]

set_false_path -setup -rise_from [get_clocks dclk_ext_virt] -fall_to [get_clocks i_adc|i_adc_pll_c10|iopll_0|outclk338]

set_false_path -hold -rise_from [get_clocks dclk_ext_virt] -rise_to [get_clocks i_adc|i_adc_pll_c10|iopll_0|outclk338]

set_false_path -hold -fall_from [get_clocks dclk_ext_virt] -fall_to [get_clocks i_adc|i_adc_pll_c10|iopll_0|outclk338]

------------

Timing is failing from the input pin to the DDIO registers as well as from the DDIO registers to the first regular register after the DDIO. Attached is the timing report reporting setup timing to the PLL output clock for the slow corner (timing_report.txt).

One thing I don't understand in particular is why the timing analyzer is showing that it is using the clock inverted for the analysis. It uses the inverted virtual clock as the latch clock for "i_adc|i_adc_channel_top|i_ddio_c10_dqd|gpio_0|core|i_loop[x].altera_gpio_bit_i|input_path.in_path_fr.buffer_data_in_fr_ddio~ddio_in_fr__nff" and then the inverted PLL output clock as the launch clock from there to the first regular register. But the only thing that should be using the inverted clock is the DDIO register that registers data for the falling edge which should then be registered again with the rising edge of the regular clock so that both the low and the high DDIO outputs change on the rising edge of the regular PLL output clock. Meaning if "i_adc|i_adc_channel_top|i_ddio_c10_dqd|gpio_0|core|i_loop[x].altera_gpio_bit_i|input_path.in_path_fr.buffer_data_in_fr_ddio~ddio_in_fr__nff" is the falling edge register of the DDIO then from there the data should go through another register inside the DDIO (using the rising edge of the non inverted clock) before being registered by "i_adc|i_adc_channel_top|di_h_d[x]" or "i_adc|i_adc_channel_top|di_l_d[x]" but both of those show the inverted clock as the launch clock.

I am running Quartus 19.2 Pro for this project. The interesting thing is that I have that same interface with the same constraints on a Cyclone 5 (using Quartus Lite 18.0) and even though the interface is also failing timing, the setup relationship shows a full clock cycle instead of a half clock cycle from the DDIO output to the first regular register input as I would expect.

Any pointers on how to get this to meet timing and understand what is going on including just fixing my constraints if they are wrong are greatly appreciated!

[sstrell]

For a DDR input, you don't use the multicycle of 0. That's only for edge-aligned DDR output.

The online training explains this much better than the app note:

https://www.intel.com/content/www/us/en/programmable/support/training/course/oddr1000.html

#iwork4intel

[Kenny_Tan]

Hi,

For DDIO running more than 200Mhz, you will have to use phylite instead.

Thanks,

[designEngineer]

@KTan9: I looked at the phylite IP but am not sure how this would be implemented. I have an ADC interface that provides a 338 clock and four 8-bit wide data inputs that are running at DDR. The phylite IP seems to require a clock input (used as the PLL ref_clk) that is synchronous to the strobe_in input at half the frequency of the interface clock. Would my data inputs DI, DID, and DQ, DQD map to the io_data_in ports and my 338 clock map to the io_strobe_in port? If so where am I supposed to get the ref_clk from that is supposed to be synchronous to strobe_in but half the frequency? Any pointers to what I am missing or not understanding are greatly appreciated!

@sstrell: I have watched the online training and have changed the following things:

• changed PLL mode from LVDS to source synchronous
• added a 90 degree phase shift of the 338 PLL output (in order to align the clock at the center of where the incoming data changes)
• removed the set_multicycle_path constraints

With those changes I am getting timing violations that are worse than before (see updated timing report attached). Also the setup relationship from the DDIO output to the first regular capture register is still showing as half a clock cycle but shouldn't it be a full clock cycle?

I am not sure at this point on how to proceed, is the phylite the right path or can I get the interface timing to pass with the DDIO implementation?

Thank you for your help!

[Kenny_Tan]

You can refer to https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/ug/ug_altera_phylite.pdf page 10 for each of the clock definition.

I would advise you to download the design example

https://www.intel.com/content/www/us/en/programmable/documentation/kly1430805439505.html

On how they make the connection

[Kenny_Tan]

As mention, you will not be able to close timing with 338 MHz on the DDIO.

[Kenny_Tan]

any further question?

[designEngineer]

I am still wondering where the half clock speed, synchronous clock for the interface is supposed to be coming from. I looked at the design and I understand generally how this is supposed to be hooked up but it requires that half speed clock that I don't know where to take from.

Again my interface has DDR data lines and a clock. The phylite calls the clock a strobe and then wants a clock that is synchronous to the strobe and half speed. But the ADC that I am interfacing with doesn't have that. Can it be generated by a PLL or something like that?

Thanks!

[Kenny_Tan]

Hi, Lets setup a meeting discussion to see your requirement. Can you provide the info below?

1) name:

2) email address:

3) company:

[Kenny_Tan]

Also,

4) Country:

[Kenny_Tan]

any update?

[designEngineer]

Can I email that info somewhere instead of posting it to the forum?

Thanks!

[Kenny_Tan]

Sure, you can check your email inbox

[Kenny_Tan]

Have you check your email box?

[designEngineer]

@KennyT_Intel​ 

I have replied to your email trail since I have some follow up questions but have not heard back. Are you still supporting this issue and if so did you receive my follow up questions?

Thanks!

[Kenny_Tan]

Yes, I am still supporting this. I will get back to you by today.