cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Explorer
Explorer
533 Views
Registered: ‎09-18-2007

Understanding the Clock Interaction Report

Jump to solution

I have a design that is taking too long to build and subsequently fail timing. Approximately 30% of an XCKU085* (running Vivado 2019.2.1)

The places where the tool spends a long time are the subject of questions on this forum and that is what I am working through (Phase 6.1.1 timing report, 4.1 rip up and re-route etc). I have routing congestion and or never completes timing phase 6.1.1. I change the implementation strategy to spread the CLBs and this does build but still takes ~5 hours. I have yet to try some floorplanning. Because I'm using OSERDES lanes, a big section of the logic is already where I would floorplan it to be.

For now I am looking at the clocks and I'm not quite understanding what the Clock Interaction report is telling me. For instance:

1. The biggest clock pair with the worst TNS (-615ns in red text) is highlighted as green. Why is that? This clock pair meet at a FIFO. It would be dangerous to use a global false path on these two clocks because of the FIFO's need for CDC knowledge. So how do I resolve this issue?

2. When I right click that red -615ns number ie to set a constraint, it does not select CLKOUT2 from the MMCM as the source clock, but CLKOUT1. Why is that? CLKOUT1 goes through a BUFGCE to become the destination clock (div_clk) which is one of the clocks to the OSERDES.

 

* Since this is a stacked silicon part, it seems to always place the logic one one of the die. At what point does PAR decide to use the second die? I have a very full pinout design and surprised that all the I/Os can be reached from one die.

 

 

clock interptet.PNG

 

1 Solution

Accepted Solutions
Highlighted
Guide
Guide
479 Views
Registered: ‎01-23-2009

The clock interaction report is trying to analyze the structure of the clocking scheme - it is not concerned with whether timing is met or not, but trying to give you information about the interaction of the clocks.

First, realize that this has nothing to do with static timing analysis (STA). The rules of STA are clear; all clocks are related by default. No matter how you define them, whether they are primary, generated, auto-generated, propagated, whatever... all clocks are related; the tool will assume synchronous timing relationships on all paths, regardless of the the natures of the clocks used for the startpoint and endpoint of the path. In a real system, this may be correct for some clocks and incorrect for others. For ones where it isn't correct, it is up to the user to use proper clock domain crossing (CDC) techniques and use the appropriate timing exceptions for the clock domain crossing circuits (CDCCs).

The clock interaction report is different. It is trying to call attention to combinations of clocks where you might have problems. First it tries to determine if clocks are structurally related or not. Two clocks are structurally related if they can be traced back to a common point (essentially a common create_clock command). So two clocks coming from the same MMCM are structurally related. Two clocks coming from different MMCMs that share a common CLKIN or even when the CLKIN of one is derived from one of the CLKOUTs of the other are structurally related. The clock interaction report will color these green (Timed). Conversely, clocks from two different input ports are not structurally related (nor are any clocks that are derived from them). These will not be colored green, but what they are colored depends on the next step.

If two clocks are not structurally related, the clock interaction report (NOT STATIC TIMING ANALYSIS) assumes that these are probably asynchronous clocks. Again, to be clear, static timing analysis will treat them as synchronous, but the report clock interaction will assume they are not.

Now that it has determined if two clocks are unrelated, it looks at the constraints to see how they are treated. If two clocks are truly asynchronous, then the user should have implemented a proper CDCC. As part of this, an there should be exceptions on the actual clock domain crossing paths - usually these would be set_false_path exceptions or (preferably) set_max_delay -datapath_only exceptions. If it sees these exceptions on all paths  between two structurally unrelated clocks, it assumes these are safe - it colors them according to the exception. If there are only some (but not all) paths that are covered by exceptions, then they become "Partial False Path (unsafe)". If there are no exceptions, then these will be marked "Timed (unsafe)" - telling you that STA considers them a synchronous paths, but the structure makes these not look like synchronous paths, and the user hasn't put any exceptions on them telling the tools otherwise.

So that is what the clock interaction report is for. It is to call your attention to things that don't "look right" when analyzing the structure of your clocks and the constraints on paths between them. This has nothing to do with whether they pass timing or fail.

Furthermore, it doesn't tell you if your clocking structure is "good". There are lots of clocking structures that result in clocks being stucturally related, but effectively unusable clock relationships. A classic example is a (moderately fast) clock that goes to two different types of clock buffers (like a BUFR vs. a BUFG) or even different combinations of cascaded clock buffers (one goes through one BUFG and another goes through - say - a BUFG and a BUFGCE), or even one doesn't use a dedicated clock buffer. These are all "bad" clock topologies, but the clock interaction report will still determine the that the clocks are "structurally related" (and that's all it cares about).

Back to the original question. The clock interaction report tells you that these two clocks are "Timed" - this means they are structurally related and there are no exceptions on them. It doesn't tell you if the clocking topologies are "good" - it may be that one goes through an MMCM and one does not, or one goes through some kind of fabric clock divider (which is also a bad clock topology). Given this, the two most likely causes of the TNS numbers you are seeing are

  • The clock topologies are "bad" making these paths hard (or impossible) to meet timing
  • The logic on the paths between these two structurally related clocks is too complex and cannot meet timing

Only by looking at the detailed timing report for the failing paths can you really determine which of these it is.

Avrum

View solution in original post

2 Replies
Highlighted
Guide
Guide
480 Views
Registered: ‎01-23-2009

The clock interaction report is trying to analyze the structure of the clocking scheme - it is not concerned with whether timing is met or not, but trying to give you information about the interaction of the clocks.

First, realize that this has nothing to do with static timing analysis (STA). The rules of STA are clear; all clocks are related by default. No matter how you define them, whether they are primary, generated, auto-generated, propagated, whatever... all clocks are related; the tool will assume synchronous timing relationships on all paths, regardless of the the natures of the clocks used for the startpoint and endpoint of the path. In a real system, this may be correct for some clocks and incorrect for others. For ones where it isn't correct, it is up to the user to use proper clock domain crossing (CDC) techniques and use the appropriate timing exceptions for the clock domain crossing circuits (CDCCs).

The clock interaction report is different. It is trying to call attention to combinations of clocks where you might have problems. First it tries to determine if clocks are structurally related or not. Two clocks are structurally related if they can be traced back to a common point (essentially a common create_clock command). So two clocks coming from the same MMCM are structurally related. Two clocks coming from different MMCMs that share a common CLKIN or even when the CLKIN of one is derived from one of the CLKOUTs of the other are structurally related. The clock interaction report will color these green (Timed). Conversely, clocks from two different input ports are not structurally related (nor are any clocks that are derived from them). These will not be colored green, but what they are colored depends on the next step.

If two clocks are not structurally related, the clock interaction report (NOT STATIC TIMING ANALYSIS) assumes that these are probably asynchronous clocks. Again, to be clear, static timing analysis will treat them as synchronous, but the report clock interaction will assume they are not.

Now that it has determined if two clocks are unrelated, it looks at the constraints to see how they are treated. If two clocks are truly asynchronous, then the user should have implemented a proper CDCC. As part of this, an there should be exceptions on the actual clock domain crossing paths - usually these would be set_false_path exceptions or (preferably) set_max_delay -datapath_only exceptions. If it sees these exceptions on all paths  between two structurally unrelated clocks, it assumes these are safe - it colors them according to the exception. If there are only some (but not all) paths that are covered by exceptions, then they become "Partial False Path (unsafe)". If there are no exceptions, then these will be marked "Timed (unsafe)" - telling you that STA considers them a synchronous paths, but the structure makes these not look like synchronous paths, and the user hasn't put any exceptions on them telling the tools otherwise.

So that is what the clock interaction report is for. It is to call your attention to things that don't "look right" when analyzing the structure of your clocks and the constraints on paths between them. This has nothing to do with whether they pass timing or fail.

Furthermore, it doesn't tell you if your clocking structure is "good". There are lots of clocking structures that result in clocks being stucturally related, but effectively unusable clock relationships. A classic example is a (moderately fast) clock that goes to two different types of clock buffers (like a BUFR vs. a BUFG) or even different combinations of cascaded clock buffers (one goes through one BUFG and another goes through - say - a BUFG and a BUFGCE), or even one doesn't use a dedicated clock buffer. These are all "bad" clock topologies, but the clock interaction report will still determine the that the clocks are "structurally related" (and that's all it cares about).

Back to the original question. The clock interaction report tells you that these two clocks are "Timed" - this means they are structurally related and there are no exceptions on them. It doesn't tell you if the clocking topologies are "good" - it may be that one goes through an MMCM and one does not, or one goes through some kind of fabric clock divider (which is also a bad clock topology). Given this, the two most likely causes of the TNS numbers you are seeing are

  • The clock topologies are "bad" making these paths hard (or impossible) to meet timing
  • The logic on the paths between these two structurally related clocks is too complex and cannot meet timing

Only by looking at the detailed timing report for the failing paths can you really determine which of these it is.

Avrum

View solution in original post

Highlighted
Explorer
Explorer
419 Views
Registered: ‎09-18-2007

Thank you for taking the time to write such a detailed reply. I now understand

0 Kudos