UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
6,903 Views
Registered: ‎05-13-2016

Source Synchronous DDR Inputs

I have used the templates for a center aligned DDR input.  My input data has 1.2 nanos of setup and 1.2 nanos of hold.

 

My clock period is 8 nanos, so using a half period of 4 nanos, my max values would be 2.8 and my min would be 1.2.

 

My design uses DDRs in the IOB, BUFIO and BUFR clocking.  Some how the tools are reporting a failure, stating that I am missing my setup time by over 4 nanos, but have over 4 nanos of hold!!!!

 

Its like its using the wrong clock edge.  There is no inversion on the clock.

 

here are the constraints

 

create_clock -name [current_instance .]_rgmii_rx_clk -period 8
set rgmii_rx_clk [current_instance .]_rgmii_rx_clk

# 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 $rgmii_rx_clk] -max 2.8 [get_ports {rgmii_rxd[*] rgmii_rx_ctl}]
set_input_delay -clock [get_clocks $rgmii_rx_clk] -min 1.2 [get_ports {rgmii_rxd[*] rgmii_rx_ctl}]
set_input_delay -clock [get_clocks $rgmii_rx_clk] -clock_fall -max 2.8 -add_delay [get_ports {rgmii_rxd[*] rgmii_rx_ctl}]
set_input_delay -clock [get_clocks $rgmii_rx_clk] -clock_fall -min 1.2 -add_delay [get_ports {rgmii_rxd[*] rgmii_rx_ctl}]

 

 

 

 

 

 

input_delay6.jpg

 

 

 

 


# Center-Aligned Double Data Rate Source Synchronous Inputs
#
# For a center-aligned Source Synchronous interface, the clock
# transition is aligned with the center of the data valid window.
# The same clock edge is used for launching and capturing the
# data. The constraints below rely on the default timing
# analysis (setup = 1/2 cycle, hold = 0 cycle).
#
# input                  ____________________
# clock    _____________|                    |_____________
#                       |                    |                
#                dv_bre | dv_are      dv_bfe | dv_afe
#               <------>|<------>    <------>|<------>
#          _    ________|________    ________|________    _
# data     _XXXX____Rise_Data____XXXX____Fall_Data____XXXX_
#

set input_clock         <clock_name>;      # Name of input clock
set input_clock_period  <period_value>;    # Period of input clock (full-period)
set dv_bre              0.000;             # Data valid before the rising clock edge
set dv_are              0.000;             # Data valid after the rising clock edge
set dv_bfe              0.000;             # Data valid before the falling clock edge
set dv_afe              0.000;             # Data valid after the falling clock edge
set input_ports         <input_ports>;     # List of input ports

# Input Delay Constraint
set_input_delay -clock $input_clock -max [expr $input_clock_period/2 - $dv_bfe] [get_ports $input_ports];
set_input_delay -clock $input_clock -min $dv_are                                [get_ports $input_ports];
set_input_delay -clock $input_clock -max [expr $input_clock_period/2 - $dv_bre] [get_ports $input_ports] -clock_fall -add_delay;
set_input_delay -clock $input_clock -min $dv_afe                                [get_ports $input_ports] -clock_fall -add_delay;

Tags (1)
0 Kudos
11 Replies
Highlighted
Historian
Historian
6,881 Views
Registered: ‎01-23-2009

Re: Source Synchronous DDR Inputs

Are you using the GMII to RGMII conversion module from the IP catalog? If so, then this explains the problem you are seeing.

 

Like all IP, the GMII to RGMII module comes with its own set of constraints.

 

Take a look at this (virtually identical) post on an RGMII interfaces. (read the rest of this post first).

 

With many interfaces there are two ways to define the timing - particularly for source synchronous interfaces. The difference is based on which clock edge is going to capture which data window. In your case the interface is center aligned (1.2ns SU, 1.2ns hold provided). The way the timing of this is defined, it is normally expected that the rising edge of the clock at time 0 will capture the data eye it is centered in - the one from -1.2ns to 1.2ns. The falling edge will capture the next one, from 2.8 to 5.2. But, the "default" edge relationship is that a window defined with respect to a given clock edge will be captured by the next clock edge; so if you define the window from -1.2 to 1.2 with the rising edge of the clock, the default timing is that it will be captured by the falling edge (which is the wrong edge).

 

So there are two solutions. You can take a look at this post on center aligned source synchronous interfaces. One is you "lie" to the tools and define window 1 with respect to the rising edge, so that it is properly captured by the falling edge, or you do the "right" thing, and define window 0 with respect to the rising edge and then change the edge relationships.

 

Changing the edge relationships is done with the set_multicycle_path 0 command (and some associated false path commands - all described in the above post on center aligned source synchronous interfaces).

 

Your problem is that (now you can read the post on RGMII interfaces) you have two sets of constraints - one from the IP core that is doing it the "right" way (and applying the set_multicycle_path 0) and one from your XDC that is defining it the "cheater" way. The problem is that the set_multicycle_path constraints remain in effect even though you have overridden the input delays, and as such it is using the wrong (really right) set of edges for the setup check.

 

(You can tell this is the case since your timing report has the line "Timing Exception: MultiCycle path Setup -end 0")

 

My solution to you (which is the same as I gave in the RGMII post) is to define the windows correctly; window 0 with respect to the rising edge and window 1 with respect to the falling edge. With the set_multicycle_path commands from the IP core, these will all be correct.

 

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

 

Avrum

0 Kudos
6,830 Views
Registered: ‎05-13-2016

Re: Source Synchronous DDR Inputs

I am using the RGMII interface that comes with the Ethernet core that we purchased.

 

I went into the constraints supplied with the core and tried to modify the input and output delays to match the phy that we are using.

On the RX side, the interface is clock centered with 1.2 setup and hold.  On the TX side, since the RGMii out has the clock with a 90 phase shift, I am operating the PHY with a requirement of 1 nano setup and 0.8 nanos of hold.

 

I have modified the supplied constraints as follows; ( I have played with the signs, but I have not been able to get it to work).

 

I appreciate all the detail provided, but I just need to get this to work.....

 


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

############################################################
# Obtain input clocks from top level XDC                         #
############################################################
set ip_gtx_clk     [get_clocks -of [get_pins tri_mode_ethernet_mac_support_clocking_i/mmcm_adv_inst/CLKOUT0]]


#
####
#######
##########
#############
#################
#BLOCK CONSTRAINTS


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

 
# define a virtual clock to simplify the timing constraints
create_clock -name [current_instance .]_rgmii_rx_clk -period 8
set rgmii_rx_clk [current_instance .]_rgmii_rx_clk

# 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 $rgmii_rx_clk] -max -2.8 [get_ports {rgmii_rxd[*] rgmii_rx_ctl}]
set_input_delay -clock [get_clocks $rgmii_rx_clk] -min 1.2 [get_ports {rgmii_rxd[*] rgmii_rx_ctl}]
set_input_delay -clock [get_clocks $rgmii_rx_clk] -clock_fall -max -2.8 -add_delay [get_ports {rgmii_rxd[*] rgmii_rx_ctl}]
set_input_delay -clock [get_clocks $rgmii_rx_clk] -clock_fall -min 1.2 -add_delay [get_ports {rgmii_rxd[*] rgmii_rx_ctl}]

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

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

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

create_generated_clock -name [current_instance .]_rgmii_tx_clk -divide_by 1 -source [get_pins {tri_mode_ethernet_mac_i/rgmii_interface/rgmii_txc_ddr/C}] [get_ports rgmii_txc]
set rgmii_tx_clk [current_instance .]_rgmii_tx_clk

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

set_output_delay 1.0 -max -clock [get_clocks $rgmii_tx_clk] [get_ports {rgmii_txd[*] rgmii_tx_ctl}]
set_output_delay 0.8 -min -clock [get_clocks $rgmii_tx_clk] [get_ports {rgmii_txd[*] rgmii_tx_ctl}]
set_output_delay 1.0 -max -clock [get_clocks $rgmii_tx_clk] [get_ports {rgmii_txd[*] rgmii_tx_ctl}] -clock_fall -add_delay
set_output_delay 0.8 -min -clock [get_clocks $rgmii_tx_clk] [get_ports {rgmii_txd[*] rgmii_tx_ctl}] -clock_fall -add_delay

############################################################
# Crossing of Clock Domain Constraints: please do not edit #
############################################################

# CDC from the Rx statistics to the statistic counter logic
set_max_delay -from $rx_clk -to [get_cells {tri_mode_ethernet_mac_i/bd_8f31_eth_mac_0_core/*statistics_counters/general_statisic_control[*].general_statisics/sync_inc_vector/data_sync_reg0}] 6 -datapath_only
set_max_delay -from $rx_clk -to [get_cells {tri_mode_ethernet_mac_i/bd_8f31_eth_mac_0_core/*statistics_counters/frame_size_bin_control1[*].frame_size_stats1/sync_inc_vector/data_sync_reg0}] 6 -datapath_only
set_max_delay -from $rx_clk -to [get_cells {tri_mode_ethernet_mac_i/bd_8f31_eth_mac_0_core/*statistics_counters/frame_size_bin_control2[*].frame_size_stats2/sync_inc_vector/data_sync_reg0}] 6 -datapath_only
set_max_delay -from $rx_clk -to [get_cells {tri_mode_ethernet_mac_i/bd_8f31_eth_mac_0_core/*statistics_counters/*/accum_gray_resync[*].sync_accum_gray_i/data_sync_reg0}] 6 -datapath_only

# set a false path for the IPIF
set_max_delay -from [get_cells {tri_mode_ethernet_mac_i/axi4_lite_ipif/axi_lite_top/*/bus2ip_addr_i_reg[*]}] -to $ip_gtx_clk 6 -datapath_only

# set a false path for the static config registers
set_false_path -from [get_cells {tri_mode_ethernet_mac_i/bd_8f31_eth_mac_0_core/*managen/conf/int_*reg[*]}] -to $ip_gtx_clk
set_false_path -from [get_cells {tri_mode_ethernet_mac_i/bd_8f31_eth_mac_0_core/*managen/conf/int_*reg[*]}] -to $rx_clk
set_false_path -from [get_cells {tri_mode_ethernet_mac_i/bd_8f31_eth_mac_0_core/*managen/conf/int_*reg}] -to $ip_gtx_clk
set_false_path -from [get_cells {tri_mode_ethernet_mac_i/bd_8f31_eth_mac_0_core/*managen/conf/int_*reg}] -to $rx_clk

Tags (1)
0 Kudos
6,822 Views
Registered: ‎05-13-2016

Re: Source Synchronous DDR Inputs

Sorry, here are the corrected constraints

 

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

 

 

set_output_delay 1.0 -max -clock [get_clocks $rgmii_tx_clk] [get_ports {rgmii_txd[*] rgmii_tx_ctl}]
set_output_delay -0.8 -min -clock [get_clocks $rgmii_tx_clk] [get_ports {rgmii_txd[*] rgmii_tx_ctl}]
set_output_delay 1.0 -max -clock [get_clocks $rgmii_tx_clk] [get_ports {rgmii_txd[*] rgmii_tx_ctl}] -clock_fall -add_delay
set_output_delay -0.8 -min -clock [get_clocks $rgmii_tx_clk] [get_ports {rgmii_txd[*] rgmii_tx_ctl}] -clock_fall -add_delay

Tags (1)
0 Kudos
6,820 Views
Registered: ‎05-13-2016

Re: Source Synchronous DDR Inputs

So it looks like you are saying for the input delays, they need to be added as negative numbers, and does not match what the template is showing, due to the multi-cycle constraint, or something to that effect, and should be

 

set_input_delay -clock [get_clocks $rgmii_rx_clk] -max -2.8 [get_ports {rgmii_rxd[*] rgmii_rx_ctl}]
set_input_delay -clock [get_clocks $rgmii_rx_clk] -min -1.2 [get_ports {rgmii_rxd[*] rgmii_rx_ctl}]

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

Tags (1)
0 Kudos
6,813 Views
Registered: ‎05-13-2016

Re: Source Synchronous DDR Inputs

Ok, looking at the timing reports I can work backwards

 

This hold time for falling edge, and would seem to be correct with 1.2  for the min spec

 

time_rpt1.jpg

 

 

This is the falling edge setup time, and is incorrect, and should be a -1.2 for the max spec

 

time_rpt2.jpg

 

 This one is hold time for the rising edge, and looks correct with a 1.2 for the min spec

 

 time_rpt3.jpg

 

 

Finally for the setup for the rising edge and looks correct with a max of 2.8.

 

time_rpt4.jpg

Tags (1)
0 Kudos
Historian
Historian
6,802 Views
Registered: ‎01-23-2009

Re: Source Synchronous DDR Inputs

Ok, looking at the timing reports I can work backwards

 

These look correct for the "cheater" way; without the set_multicycle_path and false_paths and with the input constraints being -min 1.2 and -max 2.8.

 

Avrum

 

 

Tags (1)
0 Kudos
6,784 Views
Registered: ‎05-13-2016

Re: Source Synchronous DDR Inputs

Well, it looks like I have the none-cheater way of working for the LAN.

 

I am trying to replicate this method for the other two RGMII interfaces in our design, as follows....

 

I am having issues with it getting "rx_clk1" and "rx_clk2" as I do not thing the "get_clocks -of is working.

 

I_RGMII_RX_CLK_1 and I_RGMII_RX_CLK_2 are the top level inputs that the clock comes in on.....

 

 

#set rx_clk [get_clocks -of [get_ports rgmii_rxc]]
set rx_clk1 [get_clocks -of [get_ports I_RGMII_RX_CLK_1]]
set rx_clk2 [get_clocks -of [get_ports I_RGMII_RX_CLK_2]]

 

# define a virtual clock to simplify the timing constraints
create_clock -period 8.000 -name RGMII_RX_CLK_1
create_clock -period 8.000 -name RGMII_RX_CLK_2


set_input_delay -clock [get_clocks RGMII_RX_CLK_1] -max -add_delay -1.2 [get_ports {I_RGMII_RX_DATA_1[*]}]
set_input_delay -clock [get_clocks RGMII_RX_CLK_1] -max -add_delay -1.2 [get_ports I_RGMII_RX_CTL_1]
set_input_delay -clock [get_clocks RGMII_RX_CLK_1] -min -add_delay 1.2 [get_ports {I_RGMII_RX_DATA_1[*]}]
set_input_delay -clock [get_clocks RGMII_RX_CLK_1] -min -add_delay 1.2 [get_ports I_RGMII_RX_CTL_1]

 

set_input_delay -clock [get_clocks RGMII_RX_CLK_1] -clock_fall -max -add_delay -1.2 [get_ports {I_RGMII_RX_DATA_1[*]}]
set_input_delay -clock [get_clocks RGMII_RX_CLK_1] -clock_fall -max -add_delay -1.2 [get_ports I_RGMII_RX_CTL_1]
set_input_delay -clock [get_clocks RGMII_RX_CLK_1] -clock_fall -min -add_delay 1.2 [get_ports {I_RGMII_RX_DATA_1[*]}]
set_input_delay -clock [get_clocks RGMII_RX_CLK_1] -clock_fall -min -add_delay 1.2 [get_ports I_RGMII_RX_CTL_1]

 

set_input_delay -clock [get_clocks RGMII_RX_CLK_2] -max -add_delay -1.2 [get_ports {I_RGMII_RX_DATA_2[*]}]
set_input_delay -clock [get_clocks RGMII_RX_CLK_2] -max -add_delay -1.2 [get_ports I_RGMII_RX_CTL_2]
set_input_delay -clock [get_clocks RGMII_RX_CLK_2] -min -add_delay 1.2 [get_ports {I_RGMII_RX_DATA_2[*]}]
set_input_delay -clock [get_clocks RGMII_RX_CLK_2] -min -add_delay 1.2 [get_ports I_RGMII_RX_CTL_2]

 

set_input_delay -clock [get_clocks RGMII_RX_CLK_2] -clock_fall -max -add_delay -1.2 [get_ports {I_RGMII_RX_DATA_2[*]}]
set_input_delay -clock [get_clocks RGMII_RX_CLK_2] -clock_fall -max -add_delay -1.2 [get_ports I_RGMII_RX_CTL_2]
set_input_delay -clock [get_clocks RGMII_RX_CLK_2] -clock_fall -min -add_delay 1.2 [get_ports {I_RGMII_RX_DATA_2[*]}]
set_input_delay -clock [get_clocks RGMII_RX_CLK_1] -clock_fall -min -add_delay 1.2 [get_ports I_RGMII_RX_CTL_2]

 

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

 

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

 

set_multicycle_path -from [get_clocks RGMII_RX_CLK_1] -to rx_clk1 -setup 0
set_multicycle_path -from [get_clocks RGMII_RX_CLK_1] -to rx_clk1 -hold -1

set_multicycle_path -from [get_clocks RGMII_RX_CLK_1] -to rx_clk2 -setup 0
set_multicycle_path -from [get_clocks RGMII_RX_CLK_1] -to rx_clk2 -hold -1

0 Kudos
6,783 Views
Registered: ‎05-13-2016

Re: Source Synchronous DDR Inputs

modified the clocks as follows...

 

#set rx_clk [get_clocks -of [get_ports rgmii_rxc]]
#set rx_clk1 [get_clocks -of [get_ports I_RGMII_RX_CLK_1]]
#set rx_clk2 [get_clocks -of [get_ports I_RGMII_RX_CLK_2]]

create_clock -period 8.000 -name rx_clk1 [get_ports I_RGMII_RX_CLK_1]
create_clock -period 8.000 -name rx_clk2 [get_ports I_RGMII_RX_CLK_2]

 

# define a virtual clock to simplify the timing constraints
create_clock -period 8.000 -name RGMII_RX_CLK_1
create_clock -period 8.000 -name RGMII_RX_CLK_2

0 Kudos
Historian
Historian
6,754 Views
Registered: ‎01-23-2009

Re: Source Synchronous DDR Inputs

These constraints do not look correct...

 

set_input_delay -clock [get_clocks RGMII_RX_CLK_1] -max -add_delay -1.2 [get_ports {I_RGMII_RX_DATA_1[*]}]
set_input_delay -clock [get_clocks RGMII_RX_CLK_1] -max -add_delay -1.2 [get_ports I_RGMII_RX_CTL_1]
set_input_delay -clock [get_clocks RGMII_RX_CLK_1] -min -add_delay 1.2 [get_ports {I_RGMII_RX_DATA_1[*]}]
set_input_delay -clock [get_clocks RGMII_RX_CLK_1] -min -add_delay 1.2 [get_ports I_RGMII_RX_CTL_1]

 

As you have written them, the min value is larger than the max value - that should never be the case.

 

The min and max refer to the "same" transition; the -min says "it can occur as early as" and the -max says "it will happen no later than". The way you have defined it you are giving the max of one transition, and the min of the next - I have no idea what the tools will do with that...

 

With the set_multicycle_path commands, your -main should be -2.8... With it at 1.2 I suspect that you are grossly under-constraining the hold check (by 4ns) - so this will pass the timing check, but will not ultimately prove that your interface will work.

 

Avrum

Tags (1)
0 Kudos
Scholar pedro_uno
Scholar
3,252 Views
Registered: ‎02-12-2013

Re: Source Synchronous DDR Inputs

 

Even years after switching from ISE to Vivado I am confused by what the SDC commands are trying to accomplish in this case. 

 

Forty years ago when SDC was invented source synchronous interfaces were rare.  The model was system synchronous.  SDC has been kludged to work.  I think the I/O Timing wizard for source synchronous DDR could use some improvement, or the whole SDC language should be replaced with something more usable.

 

I usually end up just throwing on some gross set_max_delay constraint to make report_timing shut up.  Then I do thorough testing in hardware.   If you are using an IDDR or ISERDES component the constraints really do not influence the timing of the design. That is fixed by the logic there is no routing or synthesis to drive.

 

The constraint is just there to warn you.

----------------------------------------
DSP in hardware and software
-----------------------------------------
0 Kudos
Historian
Historian
3,211 Views
Registered: ‎01-23-2009

Re: Source Synchronous DDR Inputs

SDC has been kludged to work. 

 

I have to disagree.

 

SDC is a consistent "language" that was designed to be able to describe almost any timing scenario. The rules for how paths are timed based on the edges of the clocks involved is very consistent and well defined. The inclusion of commands that allow you to modify the launch/capture relationships (set_multicycle_path) allow you to describe timing relationships that don't conform to the "normal" synchronous launch/capture edge relationships.

 

While it is true that the "default" timing relationship fits naturally with system synchronous I/O, it is unfair to say that it cannot accommodate source synchronous interfaces - even ones with odd timing relationships. Again, with a good understanding of the fundamentals of SDC, these interfaces conform quite nicely to the mechanisms provided within SDC...

 

Xilinx offers course material on SDC and teaches all the fundamentals. The XDC/SDC stuff used to be available in one concentrated course, but is no longer available on the main Xilinx training page. However, some Authorized Training Providers (like Hardent) still offer the concentrated XDC training in the class "Vivado Design Suite Advanced XDC and Static Timing Analysis for ISE Design Suite Users"

 

Avrum

0 Kudos