cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
wuyouniyanhu
Adventurer
Adventurer
1,373 Views
Registered: ‎03-28-2020

CDC Timing Question

Jump to solution

Hello, many questions in the design process have been supported by many experts and friends. Thank you for the help of the community. Recently, regarding the analysis of clock interaction and CDC Timing in VIVADO, I ran into trouble again.

In the first design, I used two clocks generated from different MMCMs, and the frequencies of the two clocks are also different. Without any CDC measures between the two logic modules being driven, VIVADO can easily detect this error.

In the second design, I used two clocks generated by the same MMCM. The frequency division bases of the two clocks are different, so the final frequency is also different. There is also no CDC measure between the two logic modules being driven. Data flows directly from the fast clock domain to the slow clock domain. It is obvious that there is a design error here, but VIVADO did not detect this error. Including clock interaction analysis and CDC Timing analysis.

Please see the attachment for the clock structure of the two designs. Is the VIVADO tool not sensitive to "same-source and different-frequency clocks" with different frequency division bases for the same MMCM in cross-clock analysis?

Tags (2)
0 Kudos
1 Solution

Accepted Solutions
1,114 Views
Registered: ‎01-22-2015

@wuyouniyanhu 

…the two clocks generated by MMCM are 100MHz and 33MHz…

It is very difficult for an MMCM to create clocks that are exactly 100MHz and 33MHz.   From other things you have shown, I suspect you have specified the clocks to be 100.000MHz and 33.333MHz (ie. one is exactly 3x the frequency of the other).

 

I use in the xdc file
"create_clock -period 30.303 ...
 create_clock -period 10.000 ... ”

Clocks created by an MMCM are called automatically-derived clocks (see pg 91 of UG903(v2020.1)).  That is, Vivado will automatically write create_generated_clock constraints for the clock outputs of the MMCM.  You should not write create_clock constraints for the clock outputs of the MMCM.

 

When VIVADO performs static timing analysis, does it only analyze the edges where the two clocks can be aligned initially?

For your clock crossing, you say data is sent from the 100MHz clock domain and received in the 33MHz clock domain.  If data is launched by a rising-edge of the 100MHz clock, then Vivado assumes it will be received by the very next rising-edge of the 33MHz clock.  This launch/capture edge concept is described by Fig 176 in UG906(v2020.1) that is shown below.  Note from Fig 176 that the time separation between the launch and capture edge varies (ie. it could be either 4ns or 2ns).  That is, the setup timing requirement could be either 4ns or 2ns.  However, for the timing analysis of all paths using these two clocks, Vivado will (by default) use the smallest setup requirement of 2ns.

Fig176_UG906.jpg

 

What puzzles me most is that even if it is based on the static timing analysis of the setup and hold time, because the two clock signals have no multiple ratio relationship, except for the alignment at the start time, the data transmission is basically unable to meet the timing requirements.

The “Timing Checks -Setup” report you have shown, indicates a “Setup Requirement” of 10.000ns for the crossing of data between the domains of the two clocks.  This tells me that Vivado found the smallest setup requirement between your two clocks (100MHz and 33MHz) to be 10ns.  This tells me that your 33MHz clock is actually a 33.333MHz clock (ie. this clock has exactly 3x the period of the 100MHz clock).

In summary, Vivado has found that your two clocks have a frequency ratio of exactly 3:1.  Vivado has also found that the minimum time separation between launch and capture edges of the two clocks is 10ns.  So, when performing timing analysis of the crossing of data between the two clock domains, Vivado will use a setup timing requirement of 10ns.

 

View solution in original post

6 Replies
1,353 Views
Registered: ‎01-22-2015

@wuyouniyanhu 

 Is the VIVADO tool not sensitive to "same-source and different-frequency clocks" with different frequency division bases for the same MMCM in cross-clock analysis?

In short, Vivado assumes that all clocks in your design are synchronous.  As you have discovered, this assumption is sometimes wrong.  

So, every clock domain crossing (CDC) of data requires your special attention.  You must identify whether the CDC is between synchronous clocks or between asynchronous clocks.  However, it is sometimes difficult to determine whether clocks are synchronous or not as discussed in <this> post.

If the CDC is between synchronous clocks then don't need to do anything and Vivado will correctly run timing analysis on the crossing.  If the CDC is between asynchronous clocks then you will need to insert a clock domain crossing circuit (CDCC) and write appropriate timing exceptions/constraints.

As Avrum often warns us, blanket timing exceptions like set_clock_groups -async are seldom the correct timing exception to use at a CDC between asynchronous clocks.  Instead, use targeted timing exceptions like set_max_delay -datapath_only.

Finally, use Vivado reports like report_cdc as described in <this> post to help you check on CDCs in your design.

Cheers,
Mark

avrumw
Expert
Expert
1,315 Views
Registered: ‎01-23-2009

The frequency division bases of the two clocks are different, so the final frequency is also different.

Just because they are different frequencies does not mean you can't cross data between them synchronously. In fact, if Vivado does not flag them as a timing violation, then the tools succeeded in meeting timing on this path in spite of the fact that they are different frequencies. And, unless the ratios between the clocks are really bad, this will be the case more often than not.

To go flip-flop to flip-flop, even with the inherent uncertainties of different clocks from the same MMCM and clock tree skew, the tools probably need something in the neighborhood of 1ns or a bit more to do a successful synchronous clock crossing. So unless the ratios between these frequencies create an edge separation of under 1ns (or so) then this path can be done synchronously.

So tell us what the frequencies are - using that we can see what the timing should look like. Even better, simply get a timing report on this path - the tools will tell you what Vivado thinks the requirements on this path are, and will show you how it managed to meet them.

All that being said, though, Vivado is only looking at the static timing analysis - whether a value can be brought from one domain to the other regardless of which edges of the source and destination clock are used. This doesn't do anything to ensure that each value on one domain is sampled once and only once on the destination domain - that is not a static timing problem - that is a dynamic problem that you have to solve (if it needs solving at all) through an appropriate architecture. Tell us what you expect to happen to data as it moves between these domains.

Avrum

wuyouniyanhu
Adventurer
Adventurer
1,147 Views
Registered: ‎03-28-2020

Thank you for your guidance. @avrumw @markg@prosensing.com 

I would like to add some details about this test:

In the second design, the two clocks generated by MMCM are 100MHz and 33MHz, with periods of 10ns and 30.303ns, respectively. The logic of the data sending end works in the faster clock domain (100MHz), and the logic of the receiving end works in the slower clock domain (33MHz). At the same time, I use in the xdc file
"create_clock -period 30.303 ...
create_clock -period 10.000 ... ”
 marked two clock cycles. In the report_CDC report, the path through the two clock domains is displayed as "Safely Timed".

What puzzles me most is that even if it is based on the static timing analysis of the setup and hold time, because the two clock signals have no multiple ratio relationship, except for the alignment at the start time, the data transmission is basically unable to meet the timing requirements. When VIVADO performs static timing analysis, does it only analyze the edges where the two clocks can be aligned initially?

 

I read your previous discussion. It seems that about VIVADO's timing analysis tools and principles, I still need to study carefully for some time.

Thank you again for your generous guidance and help!

Timing Check hold.png
Timing Check Setup.png
Timing Interaction.png
0 Kudos
1,115 Views
Registered: ‎01-22-2015

@wuyouniyanhu 

…the two clocks generated by MMCM are 100MHz and 33MHz…

It is very difficult for an MMCM to create clocks that are exactly 100MHz and 33MHz.   From other things you have shown, I suspect you have specified the clocks to be 100.000MHz and 33.333MHz (ie. one is exactly 3x the frequency of the other).

 

I use in the xdc file
"create_clock -period 30.303 ...
 create_clock -period 10.000 ... ”

Clocks created by an MMCM are called automatically-derived clocks (see pg 91 of UG903(v2020.1)).  That is, Vivado will automatically write create_generated_clock constraints for the clock outputs of the MMCM.  You should not write create_clock constraints for the clock outputs of the MMCM.

 

When VIVADO performs static timing analysis, does it only analyze the edges where the two clocks can be aligned initially?

For your clock crossing, you say data is sent from the 100MHz clock domain and received in the 33MHz clock domain.  If data is launched by a rising-edge of the 100MHz clock, then Vivado assumes it will be received by the very next rising-edge of the 33MHz clock.  This launch/capture edge concept is described by Fig 176 in UG906(v2020.1) that is shown below.  Note from Fig 176 that the time separation between the launch and capture edge varies (ie. it could be either 4ns or 2ns).  That is, the setup timing requirement could be either 4ns or 2ns.  However, for the timing analysis of all paths using these two clocks, Vivado will (by default) use the smallest setup requirement of 2ns.

Fig176_UG906.jpg

 

What puzzles me most is that even if it is based on the static timing analysis of the setup and hold time, because the two clock signals have no multiple ratio relationship, except for the alignment at the start time, the data transmission is basically unable to meet the timing requirements.

The “Timing Checks -Setup” report you have shown, indicates a “Setup Requirement” of 10.000ns for the crossing of data between the domains of the two clocks.  This tells me that Vivado found the smallest setup requirement between your two clocks (100MHz and 33MHz) to be 10ns.  This tells me that your 33MHz clock is actually a 33.333MHz clock (ie. this clock has exactly 3x the period of the 100MHz clock).

In summary, Vivado has found that your two clocks have a frequency ratio of exactly 3:1.  Vivado has also found that the minimum time separation between launch and capture edges of the two clocks is 10ns.  So, when performing timing analysis of the crossing of data between the two clock domains, Vivado will use a setup timing requirement of 10ns.

 

View solution in original post

wuyouniyanhu
Adventurer
Adventurer
1,068 Views
Registered: ‎03-28-2020

I started to understand a little bit.

As you said, by checking the frequency division coefficient of MMCM, the output 33MHz is indeed 33.333MHz. Thank you for your reminder. In the previous design, when considering the clock components inside the FPGA, my idea was always too ideal.

Yesterday I changed the two outputs of MMCM to 100MHz and 27MHz (the frequency division factor D=37, so the actual frequency is 27.027027...),  ran the Implementation and analyzed the timing analysis report. Among them, the CDC Timing report still believes that this path is safe, but after Interaction Clock analysis, I report this path separately, VIVADO got the result that the setup time is not satisfied, and the minimum setup time requirement at this time is also from the last time. The test 10ns was changed to 1ns.

 

Since I didn't know much about the internal structure of FPGA and the mechanism of static timing analysis, the design mistake this time was really careless. Fortunately, I was able to get your patient help and explanation in the end. The information you provided was very helpful, thank you again

 

Timing Check Setup1  27MHz.png
Timing Check Setup2  27MHz.png
CDC Timing Check 27MHz.png
0 Kudos
1,018 Views
Registered: ‎01-22-2015

@wuyouniyanhu 

Among them, the CDC Timing report still believes that this path is safe, but after Interaction Clock analysis, I report this path separately, VIVADO got the result that the setup time is not satisfied...

The CDC Timing report (report_cdc) does not check whether the path passes timing analysis.  Instead, report_cdc is looking at topology/architecture of the clock-crossing path (see pages 80-82 of UG906(v2020.1)).

The important thing to remember is that you must personally inspect every clock-crossing of data in your design.  

At a clock-crossing of data, if you determine that the clocks are synchronous then:

  1. you should know what the common period is for the two clocks
  2. you should know (roughly) what the setup relationship is from drawings like Fig 176 in UG906
  3. you should check Vivado setup timing for the crossing to ensure it is using the setup relationship that you expect
  4. you should check the methodology report (report_methodology) for warnings that your clocks may be asynchronous - see also <this> blog
  5. Please read the IMPORTANT! note on page 223 of UG906(v2020.1) about how Vivado will search over 1000 clock periods for the common period of the two clocks.  If you must rely on the 1000 clock period search (instead of doing things mentioned in 1. 2. 3.) then you should probably consider the clocks to be asynchronous.


At a clock-crossing of data, if you determine that the clocks are not synchronous then:

  1. you should build a clock-domain crossing circuit (CDCC) at the clock crossing
  2. you must write timing exceptions (eg. set_max_delay -datapath_only)
  3. you must set ASYNC_REG=TRUE for registers used to build the CDCC
  4. you must check report_cdc, which will help you determine whether 1. 2. and 3. have been done correctly


In summary, at a clock-crossing of data, there are many things that you must do because either:

  • Vivado cannot do them, or
  • you can do them much better than Vivado.


Cheers,
Mark

0 Kudos