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!

How to Constrain Clock Interactions correctly

by Xilinx Employee on ‎09-14-2017 03:27 PM (625 Views)

In today's designs it is typical to have a large number of clocks that interact with each other. In order to ensure that Vivado optimizes paths that are critical, it is essential to understand how the clocks interact and how they are related – synchronous and asynchronous clocks.

Synchronous clocks are clocks that are related to each other. For example, generated clocks from an MMCM or PLL are typically synchronous clocks provided the two clocks have a common period. If the clocks from the output of MMCM or PLL do not have a common period, then it is recommended to treat these clocks as asynchronous with proper synchronization techniques. You can easily identify clocks that are synchronous by running the report_clock_interaction report and then looking at the “Path Req (WNS)”, the “Clock Pair Classification” and the “Inter-Clock Constraints” columns. Here are three scenarios where you would treat clocks relationships as asynchronous and apply appropriate timing constraints:

  1. If the clock interaction report has many (or even one) Red "Timed (unsafe)" and/or Orange "Partial False Path (unsafe)" rectangles then you have not constrained asynchronous clocks correctly. If your design has a number of asynchronous clock crossing domains, then you need to constrain those clock interactions.
  2. Look at  the "Clock Pair Classification" and "Inter-Clock Constraints" columns in the Report Clock Interactions reports. If  the clock pair classification is "No Common Clock" or "No Common Period" and/or the Inter-clock Constraints says "Timed (unsafe)" then treat the interactions as asynchronous.
  3. If the “Path Requirement (WNS)” column is very tight, typically less than 1 ns, or the “Inter-Clock Constraints” is Timed “Unsafe” or “Partial False Path (unsafe)” then it is recommended that you treat the clock interaction as asynchronous.

    If the “WNS Path Requirement (ns)” is reasonable (>1 ns) and the "Inter-Clock Constraints is "Timed" and the “Clock Pair Classification” is “clean” then the clock interaction can be treated as synchronous meaning you don't need to add any timing constraints. The timer has automatically timed these paths as synchronous.

Clock_interaction_report.PNG

 

In order to constrain asynchronous clock domain crossings correctly, there are four things to consider:

  1. If there are no paths between the two clocks, the simply use set_clock_groups or set_false_path between the two clocks.
  2. If the paths are all single big CDCs then you can use set_clock_groups or set_false_path between the two clocks.
  3. If the paths are all multi-bit paths, and you are concerned about the latency and the skew in the data bits, then use set_max_delay –datapath_only and the set_bus_skew constraint.
  4.  If there are a mix of single bit and multi-bit CDCs between two clocks then use explicit path-to-path false path constraints for the single bit CDCs and for the multi-bit CDCs use set_max_delay –datapath_only and set_bus_skew constraints.

If the clocks are synchronous, there is no need for any constraints. The STA engine in Vivado will automatically time the paths.

Comments
by Instructor
‎09-16-2017 07:31 AM - edited ‎10-05-2017 11:03 AM

First, a quick comment

  

         1) If there are no paths between the two clocks, the simply use set_clock_groups or set_false_path between the two clocks.

 

If there are no paths between the clocks (the clock interaction box is black), then there is no need to put an exception between them. In fact, this is almost specifically the point of the clock interaction report - it tells you which clocks have paths between them, and how those paths are timed (and makes a judgement call as to whether it thinks the constraints are "safe" or not).

 

But now on to the larger discussion of the clock interaction report...

 

The clock interaction report is a tool for the designer to reflect on the design... Do I understand the paths between these two domains? Did I consider them when I created the design and (importantly) wrote the constraints? Are the constraints between them correct?

 

While the "rules of thumb" outlined in this post are more or less correct, they may be simplifying  the process a bit - again, the point is for the designer to consider all the paths and think about whether they make sense. If they do not, then correct them. Really this report should be more of a sanity check - the designer should be thinking about the correct constraints as the design is being constructed (and not relying on the clock interaction report as a mechanism for writing constraints).

 

Finally, it is important to note that this report looks only at the constraints associated with clocks and clock crossing paths. This does not replace the need for proper clock domain crossing circuits - even if the exceptions are correct, this doesn't mean the clock crossing paths are safe. Vivado also has the report_cdc command that helps you further in analyzing the structure of the clock domain crossing circuits.

 

Avrum

 

by Xilinx Employee
on ‎10-10-2017 11:31 AM

The main focus on this blog is getting the constraints correct.

 

While technically there may be no need to constrain clocks that have no paths, I'd err on the side of caution and constrain them for the sake of completeness. If the clock relationships are constrained then there is one less thing to be worried about in case the design changes. 

 

Constraining all clock relationships, irrespective of whether they have paths or not, is a standard ASIC practice - in ASICs setting clock relationships is essential ( with set_clock_groups -asynchronous) if you want crosstalk analysis. 

 

 I'd like to also find out what parts are 'more or less correct' :-).  So Avrum, let us have coffee one of these days. :-)

 

While 'disagree' is probably is very strong word, I'd say, my opinion is different to Avrumw's comment about using the report_clock_interaction report only 'as a sanity check'.The point of the report, in my opinion, is to remove any guesswork. Today's designs are very complex with possibly hundreds of clocks that might come from different individual or teams and even IPs that may or may not come with constraints. The person in charge of the top level constraints may or may not know all the details of the complex clocking topology of the design and the report is to make the job easier. Irrespective of whether you know the design or not you should be able to identify how clocks are related to each other and how to constrain them based on the path topology - 1-bit vs multi-bit. The report allows the designer to easily constrain the design without any guesswork. Get it right, first time (if you are only looking at it towards the end of a project) or everytime (throughout the design cycle as recommended by the UltraFast Design Methodology).

 

Yes, this blog doesn't talk about the CDC topology (safe CDC circuits) as the main focus as I mentioned earlier, is getting the constraints correct. Safe CDC topology is a blog post in itself and as one of the architects of report_cdc I intend to talk about safe CDC topologies in the near future.

by Instructor
on ‎10-10-2017 12:50 PM

      I'd like to also find out what parts are 'more or less correct' :-)

 

As Balachander said, our views are "different".

 

My views are that the constraints between different clocks are not based (at least solely) on the clocks themselves, but on the mechanism in which these clocks transfer data. Specifically, it is my view that any clock domain crossing needs to have a proper clock domain crossing circuit implemented on it, and it is the clock domain crossing circuit that requires constraints.

 

For example, a Gray code clock domain crossing circuit requires a set_max_delay -datapath_only (or a set_bus_skew) that uses a value that is less than or equal to one source clock period, independent of what the destination clock is. A MUX clock crosser needs a set_max_delay -datapath_only (or set_bus_skew) that has a period that is related to the separation of data going through the clock crosser and the number of synchronization flip-flops. Most event synchronizers need a set_max_delay -datapath_only with a value that is less than or equal to the period of the faster of the two clocks. A single slow changing signal can be constrained by a set_false_path if the latency is not an issue for you, or is determined by how much latency you can tolerate.

 

Each of these clock domain crossing circuits requires a different constraint. It is my view that you write the constraint appropriate for the clock domain crossing circuit. The design of your clock domain crossing circuit is part of the architecture, and hence your constraints should come from the architecture.

 

By the time you get to a synthesized design (where you can get the Clock Interaction Report), you should have long completed your architecture. As a result, your constraints should already be in place. It is for this reason that I view the Clock Interaction Report as a "sanity check".

 

But I agree - clock interactions are complicated, and we don't always live in an ideal world where all the steps are followed in order. And there are cases where the top level designer is not intimitely aware of all the details of the clock crossing that takes place throughout the design (although scoped constraints for the clock domain crossing circuits deep within the design can be a big help here). So, on this we agree - the Clock Interaction Report is an invaluable tool for helping in these situations. Where we "differ" is in the solution to the case where we find something unexpected in the Clock Interaction Report. In my view, rather than apply a constraint based on the report, the structure of the circuit around the paths covered by this interaction should be analyzed to make sure that a proper clock domain crossing circuit is in place, and, if so, what constraint that clock domain crossing circuit should have.

 

    So Avrum, let us have coffee one of these days. :-)

 

Absolutely! I am always willing to have a methodology discussion!

 

Avrum

About the Author
  • Balachander Krishnamurthy is a Sr. Product Marketing Manager for SDSoC. His responsibilities include product planning, inbound and outbound marketing for Xilinx’s Vivado SDx Design Software. Bala holds a Master's degree in Electrical Engineering from San Jose State University. He has worked at Sun Microsystems and Altera for several years in multiple roles in verification, RTL design, first silicon and board bring-up and as an ASIC Product Manager. He has more than 17 years’ experience in the GPU, CPU, ASIC and FPGA industries. His current focus is FPGA methodology for synthesis, implementation and timing closure.
  • Sanjay is Senior Director, Software Validation, at Xilinx, where he and his team validate the company’s Vivado and SDx tool chains. For more than 20 years, Sanjay has worked in EDA and VLSI in India as well as in Silicon Valley in the United States. He has worked extensively on library characterization and modeling, HDLs (focusing more on Verilog than VHDL), simulation, synthesis, static timing analysis, power, clock domain crossing and synchronization, and rule checker-based verification. Sanjay has been learning Vivado in recent years. He has published three books as co-author and editor: Principles of VLSI RTL Design – A Practical Guide, Constraining Designs for Synthesis and Timing Analysis – Using Synopsys Design Constraints, and Designing with Xilinx FPGAs – Using Vivado. In addition, Sanjay has written numerous articles and papers for trade journals and conferences. He holds three patents related to clock gating and isolation cells. A resident of Hyderabad in India, Sanjay is a graduate of the India Institute of Technology Kharagpur in electronics and electrical communications engineering.