cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Contributor
Contributor
20,095 Views
Registered: ‎10-17-2014

Input Delay Timing Constraints Doubts

Jump to solution

Hi All,

 

 I have a question regarding the constraint "Input Delay". The tool version of i am using is Vivado, 2014.4. 

Figure below shows the snapshot from the constraints wizard. In the red circle, the rise max of rising edge is calculated from the dv_bfe(Data Valid Before Falling Edge). I cant virtualize the logic of this calculation. From my understanding, rise max w.r.t rising edge should be maximun delay for the rise data. Could somebody calify on this?

 

And, the clock and data relative phase at the interface of the FPGA will be -> The clock edges(rising/falling) will be at the centre of the data valid window with dv_bre/dv_are/dv_bfe/dv_afe all equals to 1.2ns. 

 

The final constraints are as below:

set_input_delay -clock [get_clocks tri_mode_ethernet_mac_0_rgmii_rx_clk] -max 2.8 [get_ports {rgmii_rxd[*] rgmii_rx_ctl}]
set_input_delay -clock [get_clocks tri_mode_ethernet_mac_0_rgmii_rx_clk] -min 1.2 [get_ports {rgmii_rxd[*] rgmii_rx_ctl}]
set_input_delay -clock [get_clocks tri_mode_ethernet_mac_0_rgmii_rx_clk] -clock_fall -max 2.8 -add_delay [get_ports {rgmii_rxd[*] rgmii_rx_ctl}]
set_input_delay -clock [get_clocks tri_mode_ethernet_mac_0_rgmii_rx_clk] -clock_fall -min 1.2-add_delay [get_ports {rgmii_rxd[*] rgmii_rx_ctl}]

 

The subsequent Figure show the timing report of the interface. Here, as can bee seen in the red circle, the delay is added to data from the Launh edge clock. This delay does not look correct to me w.r.t my interface specification(data and clock relative phase), the data path should be minus 1.2ns to reflect the situation at the FPGA interface.  Am i missing sometings? 

 

Could someone please kindly clarify. 

 

Many Thanks.

Aaron

 

1.PNG2.PNG

 

 

 

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Guide
Guide
35,073 Views
Registered: ‎01-23-2009

Re: Input Delay Timing Constraints Doubts

Jump to solution

i changed the contraints of the input clock, rgmii_rxc, from just a simple period defination to:

 

While this may get you closer to getting timing to pass, there is nothing in the RGMII interface timing definition that makes this a valid change to perform. The timing of the RGMII is defined by what the external device is giving you (which, in turn, is defined by the RGMII specification). Remember, the whole point of input constraints is to describe the timing of the inputs to Vivado.

 

These input timings need to be relative to the FPGA's clock. In the case of the "correct way" timing (again, refer to my referenced post) we need a virtual clock because it will be used for the set_false_path relationships. But, the virtual clock and the real clock are defined with the same timing - since all clocks in Vivado are related by default it doesn't matter that there are two clocks involved, as long as they have the same timing characteristics - rise at 0, fall at 4.

 

By putting an edge specification (in reality a 90 degree phase shift of the clock) in the definition of the virtual clock, you are basically pushing your data windows forward by 1/4 of a clock phase. This isn't correct - the windows will be where RGMII says they will be (which is what your original constraints define) - not 2ns delayed from that.

 

So while you might get your static timing analysis to pass, they are passing based on an incorrect set of constraints. When you put this on the board where the timing will be the correct RGMII timing, the interface will fail.

 

Avrum

View solution in original post

0 Kudos
6 Replies
Highlighted
Voyager
Voyager
20,063 Views
Registered: ‎04-21-2014

Re: Input Delay Timing Constraints Doubts

Jump to solution

Have you looked at the langauge templates, which might give you a different way of looking at it:

 

# DDR System Synchronous Inputs
#
# A Double Data Rate (DDR) System Synchronous interface is
# an interface where the external device and the FPGA use
# the same clock, and a new data is captured half a clock
# cycle after being launched
#
# input      _______________________________                                  ________
# clock    _|                               |________________________________|    
#           |                               |
#           |-> (trco_min+trce_dly_min)     |-> (tfco_min+trce_dly_min)
#           |-----> (trco_max+trce_dly_max) |-----> (tfco_max+trce_dly_max)
#          ____    ____________________________    ____________________________    ___
# data     ____XXXX__________Rise_Data_________XXXX__________Fall_Data_________XXXX___
#

set input_clock     <clock_name>;   # Name of input clock
set trco_max        0.000;          # Maximum clock to output delay from rising edge (external device)
set trco_min        0.000;          # Minimum clock to output delay from rising edge (external device)
set tfco_max        0.000;          # Maximum clock to output delay from falling edge (external device)
set tfco_min        0.000;          # Minimum clock to output delay from falling edge (external device)
set trce_dly_max    0.000;          # Maximum board trace delay
set trce_dly_min    0.000;          # Minimum board trace delay
set input_ports     <input_ports>;  # List of input ports

# Input Delay Constraint
set_input_delay -clock $input_clock -max [expr $trco_max + $trce_dly_max] [get_ports $input_ports];
set_input_delay -clock $input_clock -min [expr $trco_min + $trce_dly_min] [get_ports $input_ports];
set_input_delay -clock $input_clock -max [expr $tfco_max + $trce_dly_max] [get_ports $input_ports] -clock_fall -add_delay;
set_input_delay -clock $input_clock -min [expr $tfco_min + $trce_dly_min] [get_ports $input_ports] -clock_fall -add_delay;

***Many of us who help you are just FPGA enthusiasts, and not Xilinx employees. If you receive help, and give kudos (star), you're likely to continue receiving help in the future. If you get a solution, please mark it as a solution.***
syssyncddr.GIF
0 Kudos
Highlighted
Guide
Guide
20,058 Views
Registered: ‎01-23-2009

Re: Input Delay Timing Constraints Doubts

Jump to solution

The constraints look correct. You are telling the tool that the data becomes valid 1.2ns before each edge and stays valid until 1.2ns after each edge. I am inferring (since you didn't say) that the clock period is 8ns (125MHz, which is normal for RGMII).

 

The "bre/are" stuff is merely a fiction of the constraint wizard (and the language templates), the real "set_input_delay" tells the tool the propagation delay from the edge of the clock at the external device to the data becoming valid. Since the half clock period is 4ns, and the data becomes valid 1.2ns before the edge, that means that it was generated (4.0-1.2) = 2.8ns after the previous edge.

 

Furthermore, the min is correct - the data will start to change as early as 1.2ns after an edge...

 

But, the analysis of the timing is incorrect - there is something wrong with the edges..

 

The clocks for the startpoint and endpoint are not the same - one is rgmii_rxc and the other is tri_mode_ethernet_mac_0_rgmii_rx_clk. Once would expect these to be the same clock - the clock that enters the FPGA. That being said, assuming they are both defined normally (as 8ns clocks), then it shouldn't really matter that they are different, although it would help if you included the definitions of the clocks...

 

You also haven't given us enough information about the analysis - is this a setup check or a hold check (i.e. Delay Type min, or max)?

 

But in the end, assuming this is a setup check (and it looks like one), then the tools are using the wrong edges for the analysis - a launch at 4ns should be captured at 8ns, not at 4ns (as is the case here). This is either due to something funny in the way the clocks are defined, or due to a "set_multicycle_path 0" between these clocks...

 

If you post the constraint file as well as the complete failing timing path (including the headers) we may be able to say more.

 

Avrum

0 Kudos
Highlighted
Contributor
Contributor
20,032 Views
Registered: ‎10-17-2014

Re: Input Delay Timing Constraints Doubts

Jump to solution

Hi Avrum,

 

Yup. It is a setup check. The full constraints:

 

############################################################
# RX Clock period Constraints (per instance) #
############################################################
# Receiver clock period constraints: please do not relax
create_clock -period 8 [get_ports rgmii_rxc]

 

############################################################
# RX Clock period Constraints (per instance) #
############################################################
# Receiver clock period constraints: please do not relax
set rx_clk [get_clocks -of [get_ports rgmii_rxc]]

 

############################################################
# For Setup and Hold time analysis on RGMII inputs #
############################################################


# define a virtual clock to simplify the timing constraints
create_clock -name tri_mode_ethernet_mac_0_rgmii_rx_clk -period 8

# Identify RGMII Rx Pads only.
# This prevents setup/hold analysis being performed on false inputs,
# eg, the configuration_vector inputs.

set_input_delay -clock [get_clocks tri_mode_ethernet_mac_0_rgmii_rx_clk] -max -1.5 [get_ports {rgmii_rxd[*] rgmii_rx_ctl}]
set_input_delay -clock [get_clocks tri_mode_ethernet_mac_0_rgmii_rx_clk] -min -2.8 [get_ports {rgmii_rxd[*] rgmii_rx_ctl}]
set_input_delay -clock [get_clocks tri_mode_ethernet_mac_0_rgmii_rx_clk] -clock_fall -max -1.5 -add_delay [get_ports {rgmii_rxd[*] rgmii_rx_ctl}]
set_input_delay -clock [get_clocks tri_mode_ethernet_mac_0_rgmii_rx_clk] -clock_fall -min -2.8 -add_delay [get_ports {rgmii_rxd[*] rgmii_rx_ctl}]

set_false_path -rise_from [get_clocks tri_mode_ethernet_mac_0_rgmii_rx_clk] -fall_to $rx_clk -setup
set_false_path -fall_from [get_clocks tri_mode_ethernet_mac_0_rgmii_rx_clk] -rise_to $rx_clk -setup
set_false_path -rise_from [get_clocks tri_mode_ethernet_mac_0_rgmii_rx_clk] -rise_to $rx_clk -hold
set_false_path -fall_from [get_clocks tri_mode_ethernet_mac_0_rgmii_rx_clk] -fall_to $rx_clk -hold

set_multicycle_path -from [get_clocks tri_mode_ethernet_mac_0_rgmii_rx_clk] -to $rx_clk -setup 0
set_multicycle_path -from [get_clocks tri_mode_ethernet_mac_0_rgmii_rx_clk] -to $rx_clk -hold -1

 

These are the constraints provided along with the IP core, Tri-Mode MAC v8.3. Besides this, there is also a user_phytiming.xdc provided with IP which allows the user to modify the constraints provided with the core as this user_phytiming.xdc is set to be processed after all other xdc files. The content of user_phytiming.xdc:

 

set rx_clk_var [get_clocks -of [get_ports rgmii_rxc]]

## If the interface timing constraints cannot be met then these can be relaxed by adjusting the values in this
## xdc file which is set to be processed after all other xdc files
## this also allows for the IODELAY tap delay setting to be adjusted without needing to modify the xdc's
## provided with the core
## All commands in this file can be used directly in the tcl command window if the synthesized or implemented design is open.

# The RGMII receive interface requirement allows a 1ns setup and 1ns hold - this is met but only just so constraints are relaxed
set_input_delay -clock [get_clocks tri_mode_ethernet_mac_0_rgmii_rx_clk] -max 2.8 [get_ports {rgmii_rxd[*] rgmii_rx_ctl}]
set_input_delay -clock [get_clocks tri_mode_ethernet_mac_0_rgmii_rx_clk] -min 1.2 [get_ports {rgmii_rxd[*] rgmii_rx_ctl}]
set_input_delay -clock [get_clocks tri_mode_ethernet_mac_0_rgmii_rx_clk] -clock_fall -max 2.8 -add_delay [get_ports {rgmii_rxd[*] rgmii_rx_ctl}]
set_input_delay -clock [get_clocks tri_mode_ethernet_mac_0_rgmii_rx_clk] -clock_fall -min 1.2-add_delay [get_ports {rgmii_rxd[*] rgmii_rx_ctl}]

 

I changed the min/max values of the rise/fall edged in user_phytiming.xdc to specfication of 1.2ns valid before rise/fall edge and remain valid 1.2ns valid after rise/fall edge. The external PHY chip will transmit the rxd with rxc in the center of data valid window. And, the board trace are equal in length and routed as short as posible. Thus, i maked an asumption that the data/clock phase relationship will remain the same at the interface of the FPGA as all the signals will have the same amount of delay. The full timing analysis summary is as below. Kindly advice am i missing anything? or i have done a mistake.

 

1.PNG

2.PNG

Thanks very very much. :-) 

 

 

 

 

 

 

 

0 Kudos
Highlighted
Contributor
Contributor
20,017 Views
Registered: ‎10-17-2014

Re: Input Delay Timing Constraints Doubts

Jump to solution

Hi @avrumw,

 

i changed the contraints of the input clock, rgmii_rxc, from just a simple period defination to:

 

create_clock -period 8 -waveform {2 6} [get_ports rgmii_rxc]

 

which create a 90 degree phase shift with the virtual clock, tri_mode_ethernet_mac_0_rgmii_rx_clk.  I have also changed the input delay constraints to a senario something like this: tri_mode_ethernet_mac_0_rgmii_rx_clk is act as the launch clock and rgmii_rxc is the capture clock at the IOB , thus, the whole valid window is at the right of rise/fall edges of tri_mode_ethernet_mac_0_rgmii_rx_clk.  The new input constraints is as below:

 

set_input_delay -clock [get_clocks tri_mode_ethernet_mac_0_rgmii_rx_clk] -max 0.8 [get_ports {rgmii_rxd[*] rgmii_rx_ctl}]
set_input_delay -clock [get_clocks tri_mode_ethernet_mac_0_rgmii_rx_clk] -min 3.2 [get_ports {rgmii_rxd[*] rgmii_rx_ctl}]
set_input_delay -clock [get_clocks tri_mode_ethernet_mac_0_rgmii_rx_clk] -clock_fall -max 0.8 -add_delay [get_ports {rgmii_rxd[*] rgmii_rx_ctl}]
set_input_delay -clock [get_clocks tri_mode_ethernet_mac_0_rgmii_rx_clk] -clock_fall -min 3.2 -add_delay [get_ports {rgmii_rxd[*] rgmii_rx_ctl}]

 

I have also removed the multicycle constraints of the rgmii_rx interface. With the multicycle constraints, i am getting wired edges being analyzed on the setup and hold check.  I need to go and study more on this. :-)

 

Kindly clarify am i doing the right things. :-)

 

And now, the setup check make sence as the figure below:

1.PNG

2.PNG

 

Thanks & Regards,

Aaron

0 Kudos
Guide
Guide
20,008 Views
Registered: ‎01-23-2009

Re: Input Delay Timing Constraints Doubts

Jump to solution

Yup. It is a setup check. The full constraints:

 

OK - so the issue is that you have two sets of constraints in your files and they are conflicting.

 

First, read this post (pretty carefully). There are two ways to define constraints for a source synchronous DDR interface, and I describe them in that post as the "cheating way" and the "right way". In that post, though, we are talking about an edge aligned interface (where the data and clock change together), whereas this one is a center aligned interface. In center aligned interface, both ways are pretty much equally correct (the "cheating way" isn't really cheating)...

 

The two sets of constraints actually describe almost exactly the same timing.

 

In the first, they describe windows that start 1.5ns before the clock and end 1.2ns after the clock. In the second, the timing is just a little different - the window starts 1.2ns before the clock and ends 1.2ns after the clock.

 

However, they are described two ways.

 

In the first, the window associated with the rising edge starts 1.5ns before the rising edge and ends 1.2ns after the rising edge. Clearly, the intent of this one is to capture that window with the rising edge of the clock. To do this, you need the

  - set_multicycle_path 0

  - set_multicycle_path -1 -hold

  - set_false_path between different combinations of the external and internal rising and falling clock edges for setup and hold checks

 

These constraints look correct for defining the interface the "correct way".

 

Then there is the second set of constraints. In this one, the data window associated with the rising edge starts at time 2.8 and ends at time 5.2 - clearly centered around the falling edge of the clock. Thus the intent is to capture it with the falling edge of the clock. Defined this way, it doesn't need any other constraints (no set_multicycle_path/false_path commands) - the edge relationships are correct for the default analysis. This is consistent witht he "cheating way", which really isn't cheating for a center aligned interface.

 

The problem is that the 2nd set of set_input_delays override the first. BUT nothing does (nor really can) override the rest of the constraints associated with the first mechanism - hence the set_multicycle_path 0 (and all the associated other constraints) remain in effect. These additional constraints are inconsistent with the windows defined by the second set of set_input_delays (which overrode the first). This leads to the incorrect analysis being done - where window is being captured by the wrong clock edge.

 

So, you have to find a way to do one or the other - not both. One set needs to be removed from the constraint files that are read in by the project.

 

Avrum

Tags (1)
0 Kudos
Highlighted
Guide
Guide
35,074 Views
Registered: ‎01-23-2009

Re: Input Delay Timing Constraints Doubts

Jump to solution

i changed the contraints of the input clock, rgmii_rxc, from just a simple period defination to:

 

While this may get you closer to getting timing to pass, there is nothing in the RGMII interface timing definition that makes this a valid change to perform. The timing of the RGMII is defined by what the external device is giving you (which, in turn, is defined by the RGMII specification). Remember, the whole point of input constraints is to describe the timing of the inputs to Vivado.

 

These input timings need to be relative to the FPGA's clock. In the case of the "correct way" timing (again, refer to my referenced post) we need a virtual clock because it will be used for the set_false_path relationships. But, the virtual clock and the real clock are defined with the same timing - since all clocks in Vivado are related by default it doesn't matter that there are two clocks involved, as long as they have the same timing characteristics - rise at 0, fall at 4.

 

By putting an edge specification (in reality a 90 degree phase shift of the clock) in the definition of the virtual clock, you are basically pushing your data windows forward by 1/4 of a clock phase. This isn't correct - the windows will be where RGMII says they will be (which is what your original constraints define) - not 2ns delayed from that.

 

So while you might get your static timing analysis to pass, they are passing based on an incorrect set of constraints. When you put this on the board where the timing will be the correct RGMII timing, the interface will fail.

 

Avrum

View solution in original post

0 Kudos