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!

AR# 63222

Vivado Constraints - Why and when is set_multicycle_path needed to constrain the input and output paths?

Description

The set_multicycle_path constraint is used to relax the path requirement when the default worst requirement is too restrictive based on the waveform relationship between the source and destination clocks and the data toggle rate that is transferred on the path. 

The set_multicycle_path constraint is normally used for intra-chip paths among sequential elements inside the FPGA such as FFs, RAMs, DSPs and etc.

However, when constraining inter-chip paths with the set_input_delay and set_output_delay constraints, the set_multicycle_path constraint might also be also needed in the same way as with intra-chip paths.

This answer record explains why and when the set_multicycle_path constraint is needed to constrain the input and output paths.

Solution

1. Why do we need set_multicycle_path for inter-chip paths?

As shown in the following diagram, an inter-chip path is the same as an intra-chip path except that part of the path delay that is outside the FPAG device is unknown to the Vivado Timing Engine.

When set_input_delay and set_output_delay are used to specify the external path delays, Vivado Timing Engine is able to analyze the inter-chip paths just like a path inside the FPGA.

So the principles of using set_multicycle_path to relax the path requirement are the same for both intra-chip and inter-chip paths.

For more information on the set_multicycle_path constraint, please refer to (UG903) - "Using Constraints".

http://www.xilinx.com/support/documentation/sw_manuals/xilinx2015_1/ug903-vivado-using-constraints.pdf




2.Typical use cases in which set_multicycle_path is needed to constrain the inter-chip paths.

  • Use Case #1
The data toggles every two cycles of the capture clock.

The default setup requirement determined by the Timing Engine is a single-cycle, which is 8-0=8.

If it is acceptable to have the second rising edge to capture the data after it is launched, we can use set_multicycle_path constraints to relax the setup requirement but keep the hold check unchanged.

Note
: the set_multicycle_path constraint is applicable only when the intermediate edges do not capture data.

After the multicycle adjustment, the setup requirement becomes 16-0=16.



If this is on the input side:

create_clock -name clk0 -period 8.0 [get_ports CLK0]
set_input_delay -max 3.0 -clock clk0 [get_ports DIN]
set_input_delay -min 2.0 -clock clk0 [get_ports DIN]
set_multicycle_path -setup 2 -from [get_ports DIN] -to [get_clocks clk0] # relax the setup requirement
set_multicycle_path -hold 1 -from [get_ports DIN] -to [get_clocks clk0] # keep the hold requirement unchanged

If this is on the output side:

create_clock -name clk0 -period 8.0 [get_ports CLK0]
set_output_delay -max 5.0 -clock clk0 [get_ports DOUT]
set_output_delay -min -2.0 -clock clk0 [get_ports DOUT]
set_multicycle_path -setup 2 -from [get_clocks clk0] -to [get_ports DOUT] # relax the setup requirement
set_multicycle_path -hold 1 -from [get_clocks clk0] -to [get_ports DOUT] # keep the hold requirement unchanged


  • Use Case #2
The capture clock has a phase shift compared to the launch clock.

The default setup requirement determined by the Timing Engine is the time difference between the two closest launch and capture clock edges, which is 1-0=1 in the following case.

In general the 1ns requirement is too tight and unrealistic.

So we need to use set_multicycle_path to relax the setup requirement.

After the multicycle adjustment, the setup requirement becomes 9-0=9.


If this is on the input side:

create_clock -name clk0 -period 8.0 [get_ports CLK0]
set_input_delay -max 3.0 -clock clk0 [get_ports DIN]
set_input_delay -min 2.0 -clock clk0 [get_ports DIN]
set_multicycle_path -setup 2 -from [get_ports DIN] -to [get_clocks clk0]
Note: In this case, it is not necessary to modify the hold relationship with an additional set_multicycle_path constraint because it is already properly established relative to the setup relationship.

If this is on the output side (Source Synchronous interface):

create_clock -name clk0 -period 8.0 [get_ports CLK0]
create_generated_clock -name fwclk -multiply_by 1 -source [get_pins oddr_inst/C] [get_ports CLKOUT]
set_output_delay -max 6.0 -clock fwclk [get_ports DOUT]
set_output_delay -min -1.0 -clock fwclk [get_ports DOUT]
set_multicycle_path -setup 2 -from [get_clocks clk0] -to [get_ports DOUT]

Note: In this case, it is not necessary to modify the hold relationship with an additional set_multicycle_path constraint because it is already properly established relative to the setup relationship


AR# 63222
Date Created 12/25/2014
Last Updated 07/03/2015
Status Active
Type General Article
Tools
  • Vivado Design Suite