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: 
Scholar dwisehart
Scholar
17,138 Views
Registered: ‎06-23-2013

set_max_delay -datapath_only and destination clock delays

Jump to solution

I am looking into some timing failures and wondering what the correct value is for set_max_delay.  The have two paths I am comparing.  One (failing timing) that needs no set_max_delay exception and one (meets timing) that needs and has a set_max_delay exception.  I see very different things in the destination clock path area of the two paths.

 

2014-11-15_13-57-35.jpg

 

2014-11-15_13-58-27.jpg

 

In the first, non-exception case, the destination clock path delays include destination FD setup time, clock uncertainty, clock pessimism and the route the clock took up to the FD.  In the second case with a set_max_delay exception, only the FD setup time is included.  This means that my system jitter setting (0.500) is being ignored (I think that is clock uncertainty) as is clock pessimism, which I don't know what that is.  At some level this makes sense because the set_max_delay exception says there is no destination clock to consider, but what is the proper set_max_delay setting?  It seems to me it is the shorter of the two clock periods minus some amount, but what amount?

 

Thanks,

Daniel

 

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Historian
Historian
29,457 Views
Registered: ‎01-23-2009

Re: set_max_delay -datapath_only and destination clock delays

Jump to solution

Daniel,

 

For your first one, the latency of the capture will be the sum of:

  - The value of the set_max_delay (which constrains the path from the clock-to-q of the source flip-flop, the routing and has an allowance for the setup time of the destination flip-flop)

  - one clock period

  - the worst case jitter

 

This can be figured out by the fact that after the clock-to-q of the source flip-flop and the routing delay, the new signal may arrive just after the beginning of the setup window of the flip-flop. Since it wasn't stable for the whole setup/hold window, it could be missed on that clock edge. When that happens, you have to wait for the next clock edge, which occurs one clock period plus the jitter after the previous edge, which we missed by the remainder of the setup time.

 

So, you can never "guarantee" that it happens in one destination clock cycle, unless you can specify (and meet) a set_max_delay of 0 (which is impossible).

 

As for the second case, you nailed the requirement - that the skew on the bits be less than one clock period. The skew on each bit is really the difference between the sum of

  - the source clock "delay"

  - the routing delay

  - the (negative of) the destination clock "delay"

 

The source and destination clock delay are only relative things - they can be relative to an arbitrary point in time or to the minimum insertion delay of the respective clock or whatever - the skew on the bits will be the subtraction of these values from different bits in the bus, so when you do the subtraction, all that will remain is the difference in the insertions - i.e. the skew (their absolute values won't matter).

 

Other factors exist. In theory, one bit could just miss the beginning of the setup window where the previous change could just miss the end of the hold window. Furthermore, the subsequent edges of the clock may be one destination clock period minus the peak jitter. So therefore, the skew calculated above must be strictly less than

    one destination clock period -

    peak clock jitter -

    setup time of destination FF -

    hold time of destination FF

 

The set_max_delay, though, really constrains the routing delay (including clock-to-q) and the setup time of the destination FF. There is no allowance for the hold time of the FF, nor the jitter. So, if you wanted to be hyper conservative, you would set the set_max_delay to

   one destination clock period -

   worst case source clock skew -

   worst case destination clock skew -

   worst case jitter -

   hold time of the destination FF

 

But, this is constraining delay - not skew. So, the maximum delay above will be mitigated by the minimum delay of this path, which includes the minimum routing delay of the path (including minimum clock-to-q of the FF), at a "similar" process (see the CRPR discussion below). Unfortunately, this is hard to quantify. In general, people assume that this minimum delay is larger then the other factors above (the source and desitanation clock skew + jitter + hold time), and specify the value of the set_max_delay to be the destination clock period.

 

As for clock pessimism, you have to understand how the Vivado timer deals with source and destination clock delay (for normal timing paths). For a setup time (say, at slow process corner), it uses the true worst case process/voltage/temperuature delay for all components on the source clock path and the data path. But for the destination clock path, it uses "the fastest delays that can occur on a die that has at least some components at the true slowest corner". In Vivado parlance, it uses "slow_max" for the source clock and data path delays and "slow_min" for the destination clock delay. This is "on chip variation (OCV)" analysis.

 

However, doing so can be "pessimistic". If the source clock path and destination clock path both (say), go through the same IBUFG, MMCM and BUFG, then in the source clock path they will be timed at slow_max, and in the destination clock pathat slow_min. But these are the same components! They can't have two different sets of delays associated with them. Therefore this "Reconvergence" of the "Clock" paths creates some "Pessimism" that needs to be "Removed" - this is "Clock Reconvergence Pessimism Removal (CRPR)". The difference in how these components were timed in the two paths has to be "added back" to the budget for the path. This is what the "clock pessimism" line is for - it is adding back a fudge factor for this pessimism (note that in normal paths it is increasing the slack, not reducing it).

 

In a set_max_delay -datapath_only, neither the source clock delay nor the destination clock delays were considered, hence there is no "pessimism", so the "clock pessimism" doesn't apply.

 

Avrum

Tags (1)
7 Replies
Instructor
Instructor
17,114 Views
Registered: ‎08-14-2007

Re: set_max_delay -datapath_only and destination clock delays

Jump to solution

I guess I'm not seeing the point here.  When you use -datapath_only, you're telling the tools not to consider the clock paths.  The fact that a portion of the data path delay is listed in the clock section (setup to destination clock) doesn't really change the fact that it is really part of the data path timing, which starts at the clock edge reaching the source flop and ends when some clock edge reaches the destination flop.  So basically -datapath_only should only be used when you consider the clocks to be unrelated, and in this case there is no "proper" max_delay setting.  If the clocks are related and you want the clock timing analyzed, you need to leave out "-datapath_only" and use a max_delay that defines the actual requirement of the design, usually a multiple of one of the clock periods, but it all depends on how the signal is used.  If the clocks are really related and this path has no reason to be treated as multicycle or other exception case, then you don't really need to add the max_delay at all.

-- Gabor
0 Kudos
Scholar dwisehart
Scholar
17,101 Views
Registered: ‎06-23-2013

Re: set_max_delay -datapath_only and destination clock delays

Jump to solution

There are two different cases where I use set_max_delay.  Both involve crossing clock domains, so I cannot leave out datapath_only or timing will fail.  Using set_false_path does not give me the implementation I am looking for.

 

The first case I use set_max_delay is where I have a single signal moving between clock domains and I want it to arrive at the first FD in one destination clock cycle.  If I use the period of the destination clock and the signal is launched within the setup and hold keepout window of the previous destination clock cycle, it will take two clocks before the first FD has a valid input.  So if I subtract the setup and hold keepout from the destination clock period, a signal that arrives at first FD within the setup and hold keepout will have launched on the same clock cycle, allowing a valid input to arrive on the first FD after a single clock cycle.  But clock uncertainty and perhaps clock pessimism have to accounted for as well.

 

The second case is where multiple signals are crossing clock domains--such as a grey counter--and I want to make sure the skew between the signals is one clock cycle or less.  The problem is really the same as first case: if I do not account for the setup and hold keepout, the clock uncertainty and perhaps the clock pessimism, some signals could arrive in less than one clock cycle and some could land in the setup and hold keepout of the second clock and not be valid until the third clock.  That could allow the destination to see two different grey counter bits change at the same time, completely missing one step.

 

How is the clock uncertainty calculated?  What is clock pessimism and how is it calculated?

 

Daniel

 

0 Kudos
Highlighted
Historian
Historian
29,458 Views
Registered: ‎01-23-2009

Re: set_max_delay -datapath_only and destination clock delays

Jump to solution

Daniel,

 

For your first one, the latency of the capture will be the sum of:

  - The value of the set_max_delay (which constrains the path from the clock-to-q of the source flip-flop, the routing and has an allowance for the setup time of the destination flip-flop)

  - one clock period

  - the worst case jitter

 

This can be figured out by the fact that after the clock-to-q of the source flip-flop and the routing delay, the new signal may arrive just after the beginning of the setup window of the flip-flop. Since it wasn't stable for the whole setup/hold window, it could be missed on that clock edge. When that happens, you have to wait for the next clock edge, which occurs one clock period plus the jitter after the previous edge, which we missed by the remainder of the setup time.

 

So, you can never "guarantee" that it happens in one destination clock cycle, unless you can specify (and meet) a set_max_delay of 0 (which is impossible).

 

As for the second case, you nailed the requirement - that the skew on the bits be less than one clock period. The skew on each bit is really the difference between the sum of

  - the source clock "delay"

  - the routing delay

  - the (negative of) the destination clock "delay"

 

The source and destination clock delay are only relative things - they can be relative to an arbitrary point in time or to the minimum insertion delay of the respective clock or whatever - the skew on the bits will be the subtraction of these values from different bits in the bus, so when you do the subtraction, all that will remain is the difference in the insertions - i.e. the skew (their absolute values won't matter).

 

Other factors exist. In theory, one bit could just miss the beginning of the setup window where the previous change could just miss the end of the hold window. Furthermore, the subsequent edges of the clock may be one destination clock period minus the peak jitter. So therefore, the skew calculated above must be strictly less than

    one destination clock period -

    peak clock jitter -

    setup time of destination FF -

    hold time of destination FF

 

The set_max_delay, though, really constrains the routing delay (including clock-to-q) and the setup time of the destination FF. There is no allowance for the hold time of the FF, nor the jitter. So, if you wanted to be hyper conservative, you would set the set_max_delay to

   one destination clock period -

   worst case source clock skew -

   worst case destination clock skew -

   worst case jitter -

   hold time of the destination FF

 

But, this is constraining delay - not skew. So, the maximum delay above will be mitigated by the minimum delay of this path, which includes the minimum routing delay of the path (including minimum clock-to-q of the FF), at a "similar" process (see the CRPR discussion below). Unfortunately, this is hard to quantify. In general, people assume that this minimum delay is larger then the other factors above (the source and desitanation clock skew + jitter + hold time), and specify the value of the set_max_delay to be the destination clock period.

 

As for clock pessimism, you have to understand how the Vivado timer deals with source and destination clock delay (for normal timing paths). For a setup time (say, at slow process corner), it uses the true worst case process/voltage/temperuature delay for all components on the source clock path and the data path. But for the destination clock path, it uses "the fastest delays that can occur on a die that has at least some components at the true slowest corner". In Vivado parlance, it uses "slow_max" for the source clock and data path delays and "slow_min" for the destination clock delay. This is "on chip variation (OCV)" analysis.

 

However, doing so can be "pessimistic". If the source clock path and destination clock path both (say), go through the same IBUFG, MMCM and BUFG, then in the source clock path they will be timed at slow_max, and in the destination clock pathat slow_min. But these are the same components! They can't have two different sets of delays associated with them. Therefore this "Reconvergence" of the "Clock" paths creates some "Pessimism" that needs to be "Removed" - this is "Clock Reconvergence Pessimism Removal (CRPR)". The difference in how these components were timed in the two paths has to be "added back" to the budget for the path. This is what the "clock pessimism" line is for - it is adding back a fudge factor for this pessimism (note that in normal paths it is increasing the slack, not reducing it).

 

In a set_max_delay -datapath_only, neither the source clock delay nor the destination clock delays were considered, hence there is no "pessimism", so the "clock pessimism" doesn't apply.

 

Avrum

Tags (1)
Scholar dwisehart
Scholar
17,087 Views
Registered: ‎06-23-2013

Re: set_max_delay -datapath_only and destination clock delays

Jump to solution

In the first case I should have said between one and two destination clock periods, which is what I meant but said poorly.  I make the assumption that no matter what the delay is between FD's, there can always be a setup and hold violation the first destination clock cycle when you are crossing clock domains.

 

Many thanks for the answer, Avrum.

 

Daniel

 

0 Kudos
Visitor mander
Visitor
8,086 Views
Registered: ‎10-03-2016

Re: set_max_delay -datapath_only and destination clock delays

Jump to solution

Thanks avrumw this clarifies the topic and helps a lot.

But this leads to the following question. [Are there some in-depth documents, tutorials, etc. I didn't find anything which provides such a detail. :/]
I could see that the  "Clock Reconvergence Pessimism Removal (CRPR)" is used in the "Clock Path Skew" equation. But where is the Clock Path Skew used in the in the paths delays? If I manually subtract that pessimism 40.029-0.737 = 39.292, the timing would be met.

I would like to build something similar to this one: https://eprint.iacr.org/2015/124.pdf
Here we need an LUT which does not glitch and does not evaluate until all data are stable. We used a CLK signal to ensure this behavior of the LUT, as the CLK is always the latest arrived signal. If you have some other ideas with your inside knowledge, this would be fantastic.


0 Kudos
Historian
Historian
8,080 Views
Registered: ‎01-23-2009

Re: set_max_delay -datapath_only and destination clock delays

Jump to solution

The "Clock Path Skew" is information only. This is the subtraction in the path delays on the "Source Clock Delay" and the "Destination Clock Delay"; so it is already accounted for in the complete timing analysis.

 

The CRPR is separate, it shows up in the "clock pessimism" line of the analysis.

 

Similarly, the "clock uncertainty" is a subtraction for jitter. The calculation for the uncertainty is based on input clock jitter and system clock jitter as well as jitter added/modified by the MMCM/PLL.

 

Avrum

0 Kudos
Historian
Historian
8,076 Views
Registered: ‎01-23-2009

Re: set_max_delay -datapath_only and destination clock delays

Jump to solution

I would like to build something similar to this one: https://eprint.iacr.org/2015/124.pdf
Here we need an LUT which does not glitch and does not evaluate until all data are stable. We used a CLK signal to ensure this behavior of the LUT, as the CLK is always the latest arrived signal. If you have some other ideas with your inside knowledge, this would be fantastic.

 

I haven't read the paper, but my first response is that you should probably not be trying this in an FPGA - at least not through the tools.

 

First of all, there is nothing in any Xilinx documentation that ensures that a LUT is glitch free - even if the "last arriving" signal is a controlling value of the LUT function. Remember, LUTs are look-up tables, not actual gates...

 

Second, all the tools in the tool chain are designed for synchronous design. What you are trying to do is "outside" normal synchronous design practices, and hence the tools are going to fight you all the way. Xilinx already does aggressive optimizations (based on the architecture) for area, performance and power - including automatic fine-grain clock gating. So anything you try and code in your "RTL" (and it isn't truly RTL if you try and do stuff like this) will likely either confuse the tool or be optimized out.

 

Next, it is bad design practice to use the clock as a data input. Due to the dedicated clock networks in the FPGA, this requires weird routing to get the clock "off" the dedicated clock network and into the data routing channels. This is likely to have very bad (and uncontrollable) timing characteristics, and nasty impact on the router. In some architectures (mostly the earlier spartan family) there were VERY limited opportunities to route global clock nets to LUT inputs - even in newer families, I don't know how robust these connections are.

 

Finally, the constraints are going to choke on this stuff... How are the tools going to time these "paths" where the startpoint of the path is a clock generation cell (i.e. an MMCM) rather than a clocked element clocked by a clock - it just doesn't fit Vivado's timing model...

 

Avrum

0 Kudos