cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Advisor
Advisor
8,273 Views
Registered: ‎10-10-2014

board trace delay in source synchronous interfaces if clock and data traces have the same length

Jump to solution

to ease explanation of my question, consider a source synchronous output as an example. It's applicable to source synchronous inputs as well.

 

I'm wondering if the board trace delays matter in case the traces for data and forwarded clock are equal in length ...

 

If we take the language template for 'rising edge source synchronous outputs' xdc constraint below as an example.

 

I can see that trce_dly_max is used for the setup delay (set_output_delay -max), and trc_dely_min for the hold delay (set_output_delay -min). 

 

But how can (physically, under the same PVT conditions) the forwarded clock travel slower than the data, in case all traces are routed equal in length?

 

Or are these trce_dly_max / min used to compensate for any 'difference in lenght' between the length of the forwarded clock trace and data traces?

 

#  Rising Edge Source Synchronous Outputs 
#
#  Source synchronous output interfaces can be constrained either by the max data skew
#  relative to the generated clock or by the destination device setup/hold requirements.
#
#  Setup/Hold Case:
#  Setup and hold requirements for the destination device and board trace delays are known.
#  
# forwarded         ____                      ___________________ 
# clock                 |____________________|                   |____________ 
#                                            |
#                                     tsu    |    thd
#                                <---------->|<--------->
#                                ____________|___________
# data @ destination    XXXXXXXXX________________________XXXXX
#
# Example of creating generated clock at clock output port
# create_generated_clock -name <gen_clock_name> -multiply_by 1 -source [get_pins <source_pin>] [get_ports <output_clock_port>]
# gen_clock_name is the name of forwarded clock here. It should be used below for defining "fwclk".	

set fwclk        <clock-name>;     # forwarded clock name (generated using create_generated_clock at output clock port)        
set tsu          0.000;            # destination device setup time requirement
set thd          0.000;            # destination device hold time requirement
set trce_dly_max 0.000;            # maximum board trace delay
set trce_dly_min 0.000;            # minimum board trace delay
set output_ports <output_ports>;   # list of output ports

# Output Delay Constraints
set_output_delay -clock $fwclk -max [expr $trce_dly_max + $tsu] [get_ports $output_ports];
set_output_delay -clock $fwclk -min [expr $trce_dly_min - $thd] [get_ports $output_ports];

# Report Timing Template
# report_timing -to [get_ports $output_ports] -max_paths 20 -nworst 1 -delay_type min_max -name src_sync_pos_out -file src_sync_pos_out.txt;
		
        
        

 

 

** kudo if the answer was helpful. Accept as solution if your question is answered **
0 Kudos
1 Solution

Accepted Solutions
Highlighted
Xilinx Employee
Xilinx Employee
14,999 Views
Registered: ‎05-07-2015

Re: board trace delay in source synchronous interfaces if clock and data traces have the same length

Jump to solution

HI @ronnywebers
-----------------

let's asume because of this trace differnce the clock can arrive :

* max 0.2ns later than the data at the destination chip ( i.e data_trcedelay_min - clock_trcedelay_max= - 0.2ns)

* min 0.1ns later than the data at the destination chip (i.e data_trcedelay_max - clock_trcedelay_min = - 0.1 ns)

Destination chip : Tsu = 2.000 ns , Thd = 0.500ns
-----------------
So obviously, when if there is no pcb tracedelay for data and fw_clk (or they have exactly eqaul trace delays), the constraints will be as follows

set_output_delay -clock $fwclk -max 2.00 [get_ports $output_ports];
set_output_delay -clock $fwclk -min -0.50 [get_ports $output_ports];


Now, because of non equal trace delays for data  and fw_clk paths, If the fw_clk arrives 0.2ns/0.1ns (max/min) later than data at the destination chip,  
It  makes it easier to meet the setup requirement on destination device and similarly  makes it harder to meet hold requirement on the destination device. hence our output delay constraints should reflect the same,
Therefore, replace 
trce_dly_max with "data_trcedelay_max - clock_trcedelay_min" = - 0.1 ns
trce_dly_min with  "data_trcedelay_min - clock_trcedelay_max" = - 0.2 ns
The modfied constraints will look like,

set_output_delay -clock $fwclk -max [expr -0.10 + 2.00] [get_ports $output_ports];
set_output_delay -clock $fwclk -min [expr -0.20 -0.50] [get_ports $output_ports];


Another Approach:
Actually you can save all the trouble of  calculating the trce_delay difference between data and clock paths by simply using data trace delays only for the "trce_dly_min" and "trce_dly_max" values in the set_output_delay constraints
And use "set_clock_latency" to separately mention clock trace delays.
set_clock_latency  -max $clk_trcedly_max [get_clocks $fw_clk]

set_clock_latency  -min $clk_trcedly_min [get_clocks $fw_clk]

Also, refer this forum post by Avrum to gain more insight into how to generate a fowarded clock through ODDR and write create_generate clock constraint for the same in a source synchronous interface.

Thanks
Bharath
--------------------------------------------------​--------------------------------------------
Please mark the Answer as "Accept as solution" if information provided addresses your query/concern.
Give Kudos to a post which you think is helpful.
--------------------------------------------------​-------------------------------------------

View solution in original post

3 Replies
Highlighted
Xilinx Employee
Xilinx Employee
8,255 Views
Registered: ‎05-07-2015

Re: board trace delay in source synchronous interfaces if clock and data traces have the same length

Jump to solution

HI @ronnywebers

 

You are correct. Ideally it is the skew between the clock and data paths  that has to be captured in the trce_dly_max/min  values.
Skew between clock and data can be due to difference in length/width of clock and data traces on the pcb.

Thanks
Bharath
--------------------------------------------------​--------------------------------------------
Please mark the Answer as "Accept as solution" if information provided addresses your query/concern.
Give Kudos to a post which you think is helpful.
--------------------------------------------------​-------------------------------------------
Highlighted
Advisor
Advisor
8,248 Views
Registered: ‎10-10-2014

Re: board trace delay in source synchronous interfaces if clock and data traces have the same length

Jump to solution

thanks @nagabhar for the clear explanation. 

 

to make sure I understand the meaning of constraint and template completely : asume the clock trace is a bit longer/slower  than the data traces, so the clock 'lags behind' on the data lines.

 

let's asume because of this trace differnce the clock can arrive :

* max 0.2ns later than the data at the destination chip

* min 0.1ns later than the data at the destination chip

 

let's also asume the destination chip has a setup requirement of 2.0ns, and a hold requirement of 0.5ns

tsu = 2.000

thd = 0.500ns

 

refering back to the template,I had my doubts if 

 

trce_dly_max is equal to +0.2ns or -0.2ns ?

trce_dly_min is equal to +0.1ns or -0,2ns ?

 

 

I thinks the values should be positive, I try to reason like this :

 

a) for the setup (set_output_delay -max) :

the clock arrives 'at maximum' 0.2ns 'later' at the destination chip, because of the extra trace delay on the clock line, so the 'setup' requirement for the data at the destination chip is a bit more relaxed -> trce_dly_max would be +0.2ns, as if the trace delay gives some extra setup margin of 0.2ns

 

b) for the hold (set_output_delay -min) :

the clock arrives 'at minimum' 0.1ns later at the destination chip, so the 'hold' time is also 'relaxed' a bit, so instead of 0.5ns, thanks to the extra delay on the clock, the required hold time is reduced to 0.4ns. It needs to be 'negative' (-0.4) becase the 'direction' of hold time is in the opposite way (still strange to me to :-)

 

I'm actually wondering how to read the constraint in plain english :-)

 

so if I'm correct, the template filled in with these values would become :

 

set fwclk        clk_10MHz;        # forwarded clock name (generated using create_generated_clock at output clock port)        
set tsu          2.000;            # destination device setup time requirement
set thd          0.500;            # destination device hold time requirement
set trce_dly_max 0.200;            # maximum board trace delay
set trce_dly_min 0.100;            # minimum board trace delay
set output_ports DOUT[*];   	   # list of output ports

# Output Delay Constraints
set_output_delay -clock $fwclk -max [expr $trce_dly_max + $tsu] [get_ports $output_ports];
set_output_delay -clock $fwclk -min [expr $trce_dly_min - $thd] [get_ports $output_ports];

# so replaced by the defintions this would mean :
set_output_delay -clock clk_10MHz -max [0.200 + 2.000] [get_ports DOUT[*]];
set_output_delay -clock clk_10MHz -min [0.100 - 0.500] [get_ports $output_ports];

# or :
set_output_delay -clock clk_10MHz -max  2.200 [get_ports DOUT[*]];
set_output_delay -clock clk_10MHz -min -0.400 [get_ports DOUT[*]];	

 

** kudo if the answer was helpful. Accept as solution if your question is answered **
0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
15,000 Views
Registered: ‎05-07-2015

Re: board trace delay in source synchronous interfaces if clock and data traces have the same length

Jump to solution

HI @ronnywebers
-----------------

let's asume because of this trace differnce the clock can arrive :

* max 0.2ns later than the data at the destination chip ( i.e data_trcedelay_min - clock_trcedelay_max= - 0.2ns)

* min 0.1ns later than the data at the destination chip (i.e data_trcedelay_max - clock_trcedelay_min = - 0.1 ns)

Destination chip : Tsu = 2.000 ns , Thd = 0.500ns
-----------------
So obviously, when if there is no pcb tracedelay for data and fw_clk (or they have exactly eqaul trace delays), the constraints will be as follows

set_output_delay -clock $fwclk -max 2.00 [get_ports $output_ports];
set_output_delay -clock $fwclk -min -0.50 [get_ports $output_ports];


Now, because of non equal trace delays for data  and fw_clk paths, If the fw_clk arrives 0.2ns/0.1ns (max/min) later than data at the destination chip,  
It  makes it easier to meet the setup requirement on destination device and similarly  makes it harder to meet hold requirement on the destination device. hence our output delay constraints should reflect the same,
Therefore, replace 
trce_dly_max with "data_trcedelay_max - clock_trcedelay_min" = - 0.1 ns
trce_dly_min with  "data_trcedelay_min - clock_trcedelay_max" = - 0.2 ns
The modfied constraints will look like,

set_output_delay -clock $fwclk -max [expr -0.10 + 2.00] [get_ports $output_ports];
set_output_delay -clock $fwclk -min [expr -0.20 -0.50] [get_ports $output_ports];


Another Approach:
Actually you can save all the trouble of  calculating the trce_delay difference between data and clock paths by simply using data trace delays only for the "trce_dly_min" and "trce_dly_max" values in the set_output_delay constraints
And use "set_clock_latency" to separately mention clock trace delays.
set_clock_latency  -max $clk_trcedly_max [get_clocks $fw_clk]

set_clock_latency  -min $clk_trcedly_min [get_clocks $fw_clk]

Also, refer this forum post by Avrum to gain more insight into how to generate a fowarded clock through ODDR and write create_generate clock constraint for the same in a source synchronous interface.

Thanks
Bharath
--------------------------------------------------​--------------------------------------------
Please mark the Answer as "Accept as solution" if information provided addresses your query/concern.
Give Kudos to a post which you think is helpful.
--------------------------------------------------​-------------------------------------------

View solution in original post