set_input_delay constraints direction

[EBoln]

Good day!
Tell me, in which direction should the delays be considered relative to the clock front?

create_clock -name {llc} -period 75MHz { llc }

set_input_delay -clock [get_clocks {llc}]             -max  4.10 [get_ports {rx_data[*]}]
set_input_delay -clock [get_clocks {llc}]             -min  0.15 [get_ports {rx_data[*]}]
set_input_delay -clock [get_clocks {llc}] -clock_fall -max  3.34 [get_ports {rx_data[*]}] -add_delay
set_input_delay -clock [get_clocks {llc}] -clock_fall -min -0.89 [get_ports {rx_data[*]}] -add_delay

Or

create_clock -name {llc} -period 75MHz { llc }

set_input_delay -clock [get_clocks {llc}]             -max -4.10 [get_ports {rx_data[*]}]
set_input_delay -clock [get_clocks {llc}]             -min -0.15 [get_ports {rx_data[*]}]
set_input_delay -clock [get_clocks {llc}] -clock_fall -max -3.34 [get_ports {rx_data[*]}] -add_delay
set_input_delay -clock [get_clocks {llc}] -clock_fall -min  0.89 [get_ports {rx_data[*]}] -add_delay

Or

create_clock -name {llc} -period 75MHz { llc }

set_input_delay -clock [get_clocks {llc}]             -max  4.10 [get_ports {rx_data[*]}]
set_input_delay -clock [get_clocks {llc}]             -min -0.15 [get_ports {rx_data[*]}]
set_input_delay -clock [get_clocks {llc}] -clock_fall -max  3.34 [get_ports {rx_data[*]}] -add_delay
set_input_delay -clock [get_clocks {llc}] -clock_fall -min  0.89 [get_ports {rx_data[*]}] -add_delay

and so on

Thanks

[sstrell]

What kind of interface is this?  I'm guessing DDR.  Center-aligned or edge-aligned clock?  Same edge or opposite edge data transfer?  And what are the numbers in your waveform supposed to represent?  Exact timing or an example from an external device or something?

[EBoln]

Yes, edge-aligned DDR, dual edge data transfer. Data from DS

-0.15 Positive clock edge to end of valid data
 4.1    Positive clock edge to start of valid data
 0.89  Negative clock edge to end of valid data
 3.34  Negative clock edge to start of valid data

Converting to waveform from top message

[sstrell]

That helps a bit.  First of all, with the clock arriving edge-aligned, you need an internal 90 degree phase shift to center-align the incoming clock with the data, usually performed with a PLL.  If you already have that in your design, add derive_pll_clocks to your .sdc to create the generated clock constraint needed.

From there, I think the correct formulas to use would be (for edge-aligned DDR):

(setup latch - setup launch) - Tsu = 0 - Tsu

Th - (hold launch - hold latch) = Th - (clock period/2) 

So the values for -max would be -4.1 and -3.34 and for -min would be (0.15 - (13.33ns/2)) and (0.89 - (13.33ns/2)), so -6.515 and -5.775.  I think I got the math right.  It's all negative, so it looks weird, but it's because of the edge alignment and the fact that there's the internal phase shift to then center align the clock with the data.

You'll also need a number of false path timing exceptions to prevent incorrect analysis.  Assuming same edge transfer, they would look like this (you need to specify your virtual clock as well):

set_false_path -setup -rise_from [get_clocks vir_clk_in] -fall_to [get_clocks llc]

set_false_path -setup -fall_from [get_clocks vir_clk_in] -rise_to [get_clocks llc]

set_false_path -hold  -rise_from [get_clocks vir_clk_in] -rise_to [get_clocks llc]

set_false_path -hold  -fall_from [get_clocks vir_clk_in] -fall_to [get_clocks llc]

[EBoln]

Thank you very much for your reply!
There is one subtlety - I have no pll left and cannot move it 90 degrees. Calculations are good, but for me the main problem is in understanding which way to count: for max to the left of the edge and for min also to the left? or how?

[sstrell]

You need some method for shifting the clock if the clock is arriving at the device edge aligned.  Otherwise, you will not be able to meet timing.

-max is for constraining setup.  -min is for constraining hold.  So -max/-min are for the rising edge and -max/-min combined with -clock_fall are for the falling clock edge.  The negative numbers I gave you are what should be used.

[EBoln]

this is all clear, but in which direction relative to the edge is the countdown

[EBoln]

sorry not edge-aligned, but center-aligned

[sstrell]

So...are you now saying the clock is center-aligned with the data?

[EBoln]

Yes, I was wrong, I'm sorry. Clock is center-aligned with the data. why pll is needed, can't the fitter delay the data lines to align with the clock? at first glance, it is enough to delay by 2.5ns, so that center-aligned

[sstrell]

If it's center-aligned, you don't need a PLL for a phase shift, though sometimes one is still inserted to add minor phase adjustments to improve slack.  But you do need to add a phase shift to your create_clock command:

create_clock -name llc  -period 13.33 -waveform { 3.33 9.99 } [get_ports llc]

The numbers are all different for center-aligned as well:

(period/4) - Tsu

Th - (period/4)

[SyafieqS]

Hi Evgeniy,

Any updates?

[EBoln]

Sorry for the long absence. In general, my main question was in what direction is the positive timing relative to the front?

Taking the initial timing diagram as an example, how do you define it correctly?