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: 
Visitor lior.glass
Visitor
4,134 Views
Registered: ‎10-06-2016

set_max_delay on all clocks

Hi,

 

By adding the following constrain on all clocks in the design, it makes the xdc file very short and properly constrains all clock domains crossing:

set_max_delay -datapath_only -from [get_clocks clk1]  -to [get_clocks -filter { NAME !~ clk1 }] clk1_period

 

Is there any disadvantages by adding this constrain on all the clocks in the xdc ?

0 Kudos
4 Replies
Scholar watari
Scholar
4,125 Views
Registered: ‎06-16-2013

Re: set_max_delay on all clocks

Hi @lior.glass

 

It spends a lot of time to analyze timing violation, when you set set_max_delay.

Because of you set "datapath_only" and "[get_clocks -filter {NAME !~ clk1}]".

 

Thank you.

Best regards,

0 Kudos
Highlighted
Historian
Historian
4,091 Views
Registered: ‎01-23-2009

Re: set_max_delay on all clocks

In principle, "blanket" set_max_delay -datapath_only commands between clocks are "reasonable" in at least many cases (they are certainly a heck of a lot better than set_clock_group commands). While it isn't my preferred mechanism of constraining clock domain crossing (CDC) paths, it is acceptable for many (even most) CDCs.

 

However, there are two things that worry me about this "complete and automated" mechanism you are proposing.

 

The first is that it is going to apply this constraint between all pairs of clocks - even "related" clocks. For example if you have a 1x and 2x clock coming out of the same MMCM and are planning to cross between them synchronously (i.e. without a CDC), then this constraint is wrong for these paths. First, for at least one direction, the value is incorrect; the requirement on these paths are complicated, depending on a lot of thing - even in the "simplest" case, the requirement should be the shorter of the two periods. In your mechanism, the requirement is always set to the period of the source clock, so paths from the 1x to the 2x will be constrained to the 1x, rather than the 2x.

 

But even worse, the set_max_delay -datapath_only even with the correct value is not equivalent to the correct requirement on these synchronous paths. When no exception is used, the tools figure out the requirements between "related" clocks correctly, using the relationship between the clocks correctly (so we don't have the problem above), but even more, the timing checks take into account a whole bunch of things

  - clock skew

  - clock jitter

  - which clock edge (rising/falling) is used

  - clock phase (if the two clocks have non-zero phase values in the MMCM)

  - duty cycle

 

WIth the set_max_delay -datapath_only NONE of this is considered, so these paths end up incorrectly constrained.

 

[So in summary, this mechanism will completely break paths between related clocks that you plan to treat as synchronous paths - i.e. with no CDC]

 

Even with unrelated clocks (ones that do have a CDC), this concept has some flaws. The value of the set_max_delay -datapath_only needs to take into account a number of issues. The two biggies are the structure of the CDC and the required maximum latency of the CDC.

 

Not all CDCs need the same constraints. For example, a Gray Code CDC needs a constraint less than the period of the source clock. A MUX CDC needs a constraint that is less than smaller period of the source and destination clock. For yet other CDCs that have tight latency requirements, a full clock of either period may be more than you can afford. So your blanket mechanism of setting the constraint to the period of the source clock will be insufficient for some CDCs.

 

So, in summary, in some applications

 

set_max_delay -from [get_clocks clk1] -to [get_clocks clk2] -datapath_only <value>

 

is a valid constraint to use, but

  - only when the paths are part of a valid CDC between the clocks and

  - when the <value> is according to the requirements of the "tightest" CDC requirement between the domains

 

Avrum

Visitor lior.glass
Visitor
4,027 Views
Registered: ‎10-06-2016

Re: set_max_delay on all clocks

Hi,

Assuming clock jitter=0 and the design uses only rise clock, do you see any reason why <value> is different than clk1_period ?

0 Kudos
Historian
Historian
4,019 Views
Registered: ‎01-23-2009

Re: set_max_delay on all clocks

Assuming clock jitter=0 and the design uses only rise clock, do you see any reason why <value> is different than clk1_period ?

 

No - please re-read my previous post.

 

Aside from the fact that jitter is never 0, jitter is only one of the reasons this is a bad idea. This command disables all clock skew analysis between clocks, and this is significant and unavoidable. It also underconstrains syncrhonous paths from a slow domain to a fast domain.

 

This is really not a good idea...

 

Avrum

0 Kudos