EEPW论坛

作者：balacha

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.

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.

感谢作者的辛苦创作。

本喵是EEPW论坛新劳工，主要负责搜集、搬运、整理各类干货，以后大家将在论坛的各个板块中见到我。因个人力量有限，如有任何需要的资料都可私信本喵，喵会尽力满足大家。

你们的回帖是喵搬运的动力，劳烦各位看官留下宝贵的意见。

喵~