Intel® Quartus® Prime Software
Intel® Quartus® Prime Design Software, Design Entry, Synthesis, Simulation, Verification, Timing Analysis, System Design (Platform Designer, formerly Qsys)
17039 Discussions

Source Synchronous Centre Aligned DDR timing constraints don't work

RoryH
Beginner
1,057 Views

Hello,

 

I am attempting to constrain an SLVS Source Synchronous Centre Aligned DDR Rx interface for a Cyclone V SX series device, using Quartus 18.1.  

 

Aside from some aspects of the set_input_delay constraints that's been confusing me, I've been having various issues with getting the basic constraints to work.

 

When I run a setup report, I am getting a failing path between the virtual (launch) clock and clock output from my PLL (in source synchronous mode).

 

Part of the reason for this failure is because the tool seems to think that the virtual (launch) clock should only be launching on the rising edge, even if the particular path latches on the falling edge.

 

I have attempted to use "set_false_path" .sdc commands to tell it that data launched on the rising edge shouldn't be latched on the falling edge, however, all this does is set this to a false path; the tool still doesn't know that the launch clock can launch on either edge.  I am able to verify this using the clock transfers report.

 

The other avenue I tried was to create 2 virtual clocks; one that launched on the rising edge and another that also launched on its rising edge, but that is 180 degrees out of phase.

 

This did not solve the issue however.

 

I am not sure what I am doing wrong; this aspect is not mentioned in any of the apps notes (e.g. AN433) or other Intel documents on this topic of constraining DDR source synchronous interfaces.

For reference, my constraints are as follows:

create_clock -name CLK_FPGA -period 50Mhz [get_ports {CLK_FPGA}]
derive_pll_clocks -use_net_name

create_clock -name CLK_SENSOR -period 3.367 -waveform {0.84175 2.52525} [get_ports {CLK_SENSOR}]
derive_pll_clocks -use_net_name

create_clock -name CLK_SENSOR_EXT -period 3.367

set_input_delay -clock { CLK_SENSOR_EXT } -max 0.336 [get_ports {SERIAL_DATA[3]}]
set_input_delay -clock { CLK_SENSOR_EXT } -min -0.336 [get_ports {SERIAL_DATA[3]}]
set_input_delay -clock { CLK_SENSOR_EXT } -fall -max -add_delay 0.336 [get_ports {SERIAL_DATA[3]}]
set_input_delay -clock { CLK_SENSOR_EXT } -fall -min -add_delay -0.336 [get_ports {SERIAL_DATA[3]}]

 

 

#if setting false paths:

set_false_path -setup -rise_from [get_clocks {CLK_SENSOR_EXT}] -fall_to [get_clocks {SS_PLL:Source_Synchronous_PLL|SS_PLL_0002:ss_pll_inst|altera_pll:altera_pll_i|outclk_wire[0]}]
set_false_path -setup -fall_from [get_clocks {CLK_SENSOR_EXT}] -rise_to [get_clocks {SS_PLL:Source_Synchronous_PLL|SS_PLL_0002:ss_pll_inst|altera_pll:altera_pll_i|outclk_wire[0]}]

set_false_path -hold -rise_from [get_clocks {CLK_SENSOR_EXT}] -rise_to [get_clocks {SS_PLL:Source_Synchronous_PLL|SS_PLL_0002:ss_pll_inst|altera_pll:altera_pll_i|outclk_wire[0]}]
set_false_path -hold -fall_from [get_clocks {CLK_SENSOR_EXT}] -fall_to [get_clocks {SS_PLL:Source_Synchronous_PLL|SS_PLL_0002:ss_pll_inst|altera_pll:altera_pll_i|outclk_wire[0]}]

0 Kudos
2 Replies
sstrell
Honored Contributor III
1,016 Views

First of all, you only need to use derive_pll_clocks once.  Put it in the file after all your clock constraints.  And don't use -use_net_name.  You don't need it.

Next, for the PLL, I'm presuming you have it in source synchronous mode and the phase shift is set to 0 since you said you are doing center-aligned data.

For your 3rd and 4th set_input_delay constraints, those should be -clock_fall, not -fall.  There's no option called -fall for clocks.  That may be your main issue.

For your calculated input delay max and min, I am presuming you are using the skew method since you have positive and negative values for -max and -min, respectively.  Verify that those values are correct.

Everything else looks ok.

RoryH
Beginner
970 Views

Hi sstrell,

 

thanks for your reply.  Your fix for the input delay constraints was spot on; I didn't realise I should have that clock_fall parameter.  I think I got confused and thought that "clock_fall" was related to an older .sdc format (I'd seen it in documents such as AN433 which I believe are a bit older).  Now I've changed it, and along with the set_false_path commands I can see the reports showing data being launched and latched on Rising to rising edges, and on falling to falling edges to the 2 correct input DDR registers as expected.

 

As for the input delay max and min values, yes I believe I am using the skew method.  My main resource for this was from an appnote by TI on interfacing a particular ADC (over LVDS) with an FPGA.  Totally not the device I am interfacing but it was helpful.   (You can find this here: Interfacing Altera FPGAs to ADS4249 and DAC3482 (TIDA-00069 Reference Guide)).  I have now gone over my values these with a colleague wrt the datasheet and he seemed to think the values I'd calculated made sense.

 

I am still getting some timing issues, but this is seems to be due to programmable delays on the data being introduced by the fitter wrt the clock, and also some clock uncertainty.  However, this is something I am trying to fix in chip planner and is unrelated to my original issues.  Thank  you very much for your help; it is much appreciated.

 

Rory

0 Kudos
Reply