cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
4,354 Views
Registered: ‎02-07-2008

Input delay constraints for GMII-to-RGMII IP

Jump to solution

Hi,

 

I'm hoping that someone could help me to make sense of the input delay constraints that are automatically generated by Vivado for the GMII-to-RGMII IP.

 

My specific concern is the value of the min and max values of the set_input_delay constraints (see bold text below). The GMII-to-RGMII IP expects center aligned data on the RGMII RX interface. Due to the set_multicycle_path constraints, and the center aligned data, I expect both the min and max values of the set_input_delay constraints to be negative, which they are. However, I would have expected the min value to be LESS than the max value, which is not the case.

 

Let me use an example: When I take setup and hold times from a particular Marvell device being 1.2ns and 1.2ns respectively, I would calculate min and max input delay values to be -2.8ns (4-1.2ns) and -1.2ns respectively (accounting for the fact that we are using the set_multicycle_path constraints). In the auto-generated constraints, they are -1ns and -1.5ns respectively, and I cannot make any sense of that.

 

# Identify RGMII Rx Pads only.  
# Receiver clock period constraints: please do not relax
set rx_clk [get_clocks -include_generated_clocks -of [get_ports rgmii_rxc]]

# define a virtual clock to simplify the timing constraints
create_clock -name prj_gmii_to_rgmii_0_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 prj_gmii_to_rgmii_0_0_rgmii_rx_clk] -max -1.5 [get_ports {rgmii_rxd[*] rgmii_rx_ctl}]
set_input_delay -clock [get_clocks prj_gmii_to_rgmii_0_0_rgmii_rx_clk] -min -1.0 [get_ports {rgmii_rxd[*] rgmii_rx_ctl}]
set_input_delay -clock [get_clocks prj_gmii_to_rgmii_0_0_rgmii_rx_clk] -clock_fall -max -1.5 -add_delay [get_ports {rgmii_rxd[*] rgmii_rx_ctl}]
set_input_delay -clock [get_clocks prj_gmii_to_rgmii_0_0_rgmii_rx_clk] -clock_fall -min -1.0 -add_delay [get_ports {rgmii_rxd[*] rgmii_rx_ctl}]

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

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

set ip_gtx_clk     [get_clocks -include_generated_clocks -of_objects [get_pins -of [get_cells -hier -filter {name =~ *i_bufgmux_gmii_clk}] -filter {name =~ *O}]]
create_generated_clock -add -name prj_gmii_to_rgmii_0_0_rgmii_tx_clk -divide_by 1 -source [get_pins -of [get_cells -hier -filter {name =~ *rgmii_txc_out}] -filter {name =~ *CLK}] -master_clock [get_clocks -of [get_ports gmii_clk_125m*]] [get_ports rgmii_txc]


set_false_path -fall_from $ip_gtx_clk -rise_to [get_clocks prj_gmii_to_rgmii_0_0_rgmii_tx_clk] -setup
set_false_path -rise_from $ip_gtx_clk -fall_to [get_clocks prj_gmii_to_rgmii_0_0_rgmii_tx_clk] -setup
set_false_path -fall_from $ip_gtx_clk -fall_to [get_clocks prj_gmii_to_rgmii_0_0_rgmii_tx_clk] -hold
set_false_path -rise_from $ip_gtx_clk -rise_to [get_clocks prj_gmii_to_rgmii_0_0_rgmii_tx_clk] -hold

set_output_delay -clock [get_clocks prj_gmii_to_rgmii_0_0_rgmii_tx_clk] -max -1.0 [get_ports {rgmii_txd[*] rgmii_tx_ctl}]
set_output_delay -clock [get_clocks prj_gmii_to_rgmii_0_0_rgmii_tx_clk] -min -2.6 [get_ports {rgmii_txd[*] rgmii_tx_ctl}] -add_delay
set_output_delay -clock [get_clocks prj_gmii_to_rgmii_0_0_rgmii_tx_clk] -clock_fall -max -1.0 [get_ports {rgmii_txd[*] rgmii_tx_ctl}] 
set_output_delay -clock [get_clocks prj_gmii_to_rgmii_0_0_rgmii_tx_clk] -clock_fall -min -2.6 [get_ports {rgmii_txd[*] rgmii_tx_ctl}] 

set_multicycle_path 0 -setup -end -rise_from $ip_gtx_clk -rise_to [get_clocks prj_gmii_to_rgmii_0_0_rgmii_tx_clk]
set_multicycle_path 0 -setup -end -fall_from $ip_gtx_clk -fall_to [get_clocks prj_gmii_to_rgmii_0_0_rgmii_tx_clk]

I have been using the GMII-to-RGMII IP for many versions of Vivado, and the constraints have been set to these values for as long as I can remember. I've never had issues with the IP on hardware (even now), which is why I have never questioned the constraints.

 

An interesting point: If you create a design with the AXI Ethernet Subsystem IP, it has auto-generated constraints that align with my calculations for the Marvell device being a min and max value of -2.8ns and -1.5ns respectively.

 

Are the input delay constraints of the GMII-to-RGMII IP just incorrect? Or is my interpretation incorrect?

 

Jeff

 

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Guide
Guide
6,998 Views
Registered: ‎01-23-2009

Are the input delay constraints of the GMII-to-RGMII IP just incorrect? Or is my interpretation incorrect?

 

They are incorrect. But then again, they should always be assumed to be incorrect...

 

As with all interfaces, the numbers for the set_input_delay and set_output_delay need to be extracted from the datasheet of the device on the other end of the interface (as well as the board skew). So, from one point of view, the "default" timing in the IP's XDC file should always be overridden in your top level XDC file using numbers extracted from your system.

 

That being said, it is clearly illegal to have a min > max, so these numbers are nonsense... (whereas, at least based on other posts to the forum I have seen in previous versions, in previous versions, they have at least been "reasonable").

 

Avrum

View solution in original post

2 Replies
Highlighted
Guide
Guide
6,999 Views
Registered: ‎01-23-2009

Are the input delay constraints of the GMII-to-RGMII IP just incorrect? Or is my interpretation incorrect?

 

They are incorrect. But then again, they should always be assumed to be incorrect...

 

As with all interfaces, the numbers for the set_input_delay and set_output_delay need to be extracted from the datasheet of the device on the other end of the interface (as well as the board skew). So, from one point of view, the "default" timing in the IP's XDC file should always be overridden in your top level XDC file using numbers extracted from your system.

 

That being said, it is clearly illegal to have a min > max, so these numbers are nonsense... (whereas, at least based on other posts to the forum I have seen in previous versions, in previous versions, they have at least been "reasonable").

 

Avrum

View solution in original post

Highlighted
4,299 Views
Registered: ‎02-07-2008

Thanks Avrum. As usual your answer is precise and complete. Very much appreciated!

 

Jeff

0 Kudos