Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.

- Community Forums
- :
- Forums
- :
- Vivado RTL Development
- :
- Timing Analysis
- :
- Failing Inter-Clock paths

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page

Highlighted

shaikon

Voyager

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

04-06-2019 08:28 AM

1,001 Views

Registered:
04-12-2012

Hello,

I have a signal in my design originating from a 120 MHz clock domain and driven to a 55 MHz clock domain.

I have another signal in my design originating from a 60 MHz clock domain and driven to a 270 MHz clock domain.

No XDC execptions (false path, clock groups, etc...) are defined for the above paths.

Is it __absolutely guaranteed__ that Vivado's timing analyzer will show them as a failing inter-clock paths ?

1 Solution

Accepted Solutions

Highlighted

avrumw

Guide

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

04-06-2019 01:39 PM - edited 04-06-2019 01:49 PM

961 Views

Registered:
01-23-2009

More specifically (and this is a mantra for Vivado) "**All clocks in Vivado are considered synchronous by** **default**". It is up to us to correctly inform the tool when clocks are not synchronous by placing exceptions on the paths when the clocks are not synchronous.

So, without exceptions, the tool will assume the clocks are synchronous and perfectly phase aligned (they will both have a rising edge at "time 0"). It will then do setup and hold checks on each path using **the worst combinations of edges **given that the started aligned at time 0.

For the setup path (say between the 120 and 55), it will look at each edge of the 120MHz and find the first edge of the 55MHz that is strictly later than it:

- Edge 1 @ 8.33ns -> 18.18ns
- Edge 2 @ 16.67ns -> 18.18ns
- Edge 3 @ 25ns -> 36.36ns
- Edge 4 @ 33.33ns -> 36.36ns
- Edge 5 @ 41.67ns -> 54.55ns
- etc...

It will do this until it finds a periodicity between the two clocks (or the 1000th edge, whichever comes first). In this case, the periodicity is at the 24th edge of the 120MHz clock and the 11th edge of the 55MHz clock, both at 200ns. It will then take the smallest difference between the launch and capture edges and that will be the requirement of the path. Quickly looking at the combinations, I think the worst one is the 13th edge of the 120MHz clock at 108.33ns and the 6th edge of the 55MHz at 109.09ns, which is a difference of 0.758ns.

So it will do the setup check with a 0.758ns requirement. Can this be met? **Maybe** - its not impossible. The tool will do its very best to meet this timing requirement (along with an even more complex to calculate hold time requirement), but it **might** succeed.

For the 60MHz to 270MHz (which has a periodicity of 2x60MHz or 9x270MHz) the closeset approach is the 1st edge of the 60MHz (at 16.666) and the 5th edge of the 270MHz (at 18.518ns) for a difference of 1.85ns. The tools can **definitely** make (at least a simple) path meet timing with a 1.85ns requirement.

So your answer is "**no,** it is **not** guaranteed that the tools will show them as a failing path". At least from a static timing analysis point of view. And, if, for example, the two clocks are generated by the same MMCM with the same clock buffer, this analysis is correct - if the tools say the paths pass timing, then they will, in fact, work.

Of course, if the clocks are not, in fact, synchronous and phase aligned at time 0 at the pins of the FPGA, then this analysis is incorrect. In fact, if the clocks come from different oscillators, then, by definition, **any** alignment is possible (and will occur over time), and thus, in reality, a system failure is guaranteed - in spite of the fact that the tool will try (and maybe succeed) in getting the static timing analysis to pass.

So that's it from the static timing analysis point of view. Regardless of how the clocks are generated, **all clocks are in Vivado are treated as synchronous by** **default**. From the static timing analysis point of view, both of these above cases (two clocks from the same MMCM, two clocks from different pins) **may **pass timing.

But from a **structural** point of view, Vivado has tools that attempt to tell the difference between them. The report_clock_interaction report looks at the design structurally. If the two clocks come from the same MMCM, the tool will classify the paths as "Timed Safe" (and the graphical view will color them green). If the two clocks come from different pins, the tool will classify the paths as "Timed Unsafe" (and color them - I think - red). Again, this is not a static timing check, but a structural check... Similarly the report_cdc command will classify them as unsafe clock domain crossings if the two clocks come from different pins, but as safe if they come from the same MMCM.

So, it is up to you to constrain them correctly. If the two clocks are not actually synchronous, then

- any path between them must have a clock domain crossing circuit (CDCC) and
- the actual clock domain crossing path within the CDCC must have a timing exception on it

Doing anything else is incorrect...

Avrum

2 Replies

Highlighted

markg@prosensing.com

Curator

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

04-06-2019 11:55 AM

975 Views

Registered:
01-22-2015

Is it absolutely guaranteed that Vivado's timing analyzer will show them as a failing inter-clock paths ?

I feel like this is one of those tricky questions that I always got wrong back in school 😊 Anyway, here’s what I say/read. If the two clocks are identified as asynchronous (eg. coming from two different sources) then (without timing exceptions like set_false_path and set_clock_groups), Vivado timing analysis will absolutely show a failed path at the clock-crossing.

However, if the two clocks are synchronous then according to UG906 (on about page 223) Vivado will attempt to find a common period between the two clocks - by looking over 1000 cycles of both clocks if necessary. Then, the smallest possible difference between launch and capture edges of the two clocks during this common period will be used for timing analysis. If Vivado must resort to looking over 1000 cycles of both clocks for a common period, then it will look no further and simply use the smallest difference between launch and capture edges that it found over the 1000 cycles – and Vivado will call the two clocks **unexpandable**. UG906 warns us that timing analysis for unexpandable clocks might not be pessimistic enough. That is, the clock-crossing may pass timing analysis when it actually should have failed timing analysis! According to UG835, normal check_timing will report any unexpandable clocks to you.

I think the important lesson here is that *we should give every clock-crossing our special attention* (and not leave handling of the crossing up to the Vivado tools). That is, if we are attempting a direct-crossing (ie. without synchronizers) then we should know that the crossing is possible. If we know that a direct-crossing is not possible (or highly questionable) then we should build a synchronizer at the crossing (and not wait for Vivado to tell us that a synchronizer is needed).

Cheers,

Mark

Highlighted

avrumw

Guide

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

04-06-2019 01:39 PM - edited 04-06-2019 01:49 PM

962 Views

Registered:
01-23-2009

More specifically (and this is a mantra for Vivado) "**All clocks in Vivado are considered synchronous by** **default**". It is up to us to correctly inform the tool when clocks are not synchronous by placing exceptions on the paths when the clocks are not synchronous.

So, without exceptions, the tool will assume the clocks are synchronous and perfectly phase aligned (they will both have a rising edge at "time 0"). It will then do setup and hold checks on each path using **the worst combinations of edges **given that the started aligned at time 0.

For the setup path (say between the 120 and 55), it will look at each edge of the 120MHz and find the first edge of the 55MHz that is strictly later than it:

- Edge 1 @ 8.33ns -> 18.18ns
- Edge 2 @ 16.67ns -> 18.18ns
- Edge 3 @ 25ns -> 36.36ns
- Edge 4 @ 33.33ns -> 36.36ns
- Edge 5 @ 41.67ns -> 54.55ns
- etc...

It will do this until it finds a periodicity between the two clocks (or the 1000th edge, whichever comes first). In this case, the periodicity is at the 24th edge of the 120MHz clock and the 11th edge of the 55MHz clock, both at 200ns. It will then take the smallest difference between the launch and capture edges and that will be the requirement of the path. Quickly looking at the combinations, I think the worst one is the 13th edge of the 120MHz clock at 108.33ns and the 6th edge of the 55MHz at 109.09ns, which is a difference of 0.758ns.

So it will do the setup check with a 0.758ns requirement. Can this be met? **Maybe** - its not impossible. The tool will do its very best to meet this timing requirement (along with an even more complex to calculate hold time requirement), but it **might** succeed.

For the 60MHz to 270MHz (which has a periodicity of 2x60MHz or 9x270MHz) the closeset approach is the 1st edge of the 60MHz (at 16.666) and the 5th edge of the 270MHz (at 18.518ns) for a difference of 1.85ns. The tools can **definitely** make (at least a simple) path meet timing with a 1.85ns requirement.

So your answer is "**no,** it is **not** guaranteed that the tools will show them as a failing path". At least from a static timing analysis point of view. And, if, for example, the two clocks are generated by the same MMCM with the same clock buffer, this analysis is correct - if the tools say the paths pass timing, then they will, in fact, work.

Of course, if the clocks are not, in fact, synchronous and phase aligned at time 0 at the pins of the FPGA, then this analysis is incorrect. In fact, if the clocks come from different oscillators, then, by definition, **any** alignment is possible (and will occur over time), and thus, in reality, a system failure is guaranteed - in spite of the fact that the tool will try (and maybe succeed) in getting the static timing analysis to pass.

So that's it from the static timing analysis point of view. Regardless of how the clocks are generated, **all clocks are in Vivado are treated as synchronous by** **default**. From the static timing analysis point of view, both of these above cases (two clocks from the same MMCM, two clocks from different pins) **may **pass timing.

But from a **structural** point of view, Vivado has tools that attempt to tell the difference between them. The report_clock_interaction report looks at the design structurally. If the two clocks come from the same MMCM, the tool will classify the paths as "Timed Safe" (and the graphical view will color them green). If the two clocks come from different pins, the tool will classify the paths as "Timed Unsafe" (and color them - I think - red). Again, this is not a static timing check, but a structural check... Similarly the report_cdc command will classify them as unsafe clock domain crossings if the two clocks come from different pins, but as safe if they come from the same MMCM.

So, it is up to you to constrain them correctly. If the two clocks are not actually synchronous, then

- any path between them must have a clock domain crossing circuit (CDCC) and
- the actual clock domain crossing path within the CDCC must have a timing exception on it

Doing anything else is incorrect...

Avrum