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!

cancel
Showing results for 
Search instead for 
Did you mean: 
Adventurer
Adventurer
11,615 Views
Registered: ‎03-23-2015

Generated clocks timing problem

Jump to solution

Hi,

  I am getting timing error from 2 generated clocks from the same source.  Source is 125MHz and the 2 generated clocks are 625MHz and 312.5MHz respectively.  xdc file:

 

   create_clock -period 8.000 -name IntClk125M -waveform {0.000 4.000} [get_ports Clk_p_pin]

 

  I am passing data from one the faster clock domain (1.6ns period) to the slower domain (3.2ns) period.  Data path is just 1ns.

 

  The error can be seen from this screen cap.  It seems the timing analyzer trace the source all the way back to the clock io pin, thereby aggravate timing errors. If the timing analysis starts from the MMCM then there would not be any error.

 

  How can I rectify this?

 

Neo

 

timing error.png

timing error.png
0 Kudos
1 Solution

Accepted Solutions
Historian
Historian
22,254 Views
Registered: ‎01-23-2009

Re: Generated clocks timing problem

Jump to solution

From what I can see, the timing analysis is done correctly.

 

First, realize that the source clock starts at 1.6ns and the destination at 3.2 (which is correct), so you have to subtract those off...

 

So, the insertion delay from the clock pin to the output of the MMCM on the source clock is

 

7.114 - 1.600 = 5.514

 

On the destination delay it is

 

8.328 - 3.200  = 5.128

 

The difference in insertion is 0.386ns

 

Now, you are right - since these are the same path, there should be no skew up to this point. And there isn't.  If you look further down, you will see "clock pessimism" - this is the adjustment for the fact that the the common components in the source clock delay and the destination clock delay were attributed different delays (this 0.386ns difference). In the report, the clock pessimism of 0.386 is added back into the budget, removing this source of pessimism (this is how Vivado - and other SDC based timing analysis engines do it). Thus there is no difference to this point.

 

Now for the path itself...

 

You have 1.306ns of datapath delay, 0.019ns of setup requirement on the destination flip-flop, 0.176ns of clock uncertainty (the majority of this probably comes from the potential phase difference between two outputs of the same MMCM, which is around +/-100ps, the rest probably from system jitter - have you constrained your clock jitter on the input clcok?), and some clock skew from the routing difference past the point of the MMCM. Add this all together and it comes awfully close to 1.6 (you haven't shown us all the stuff at the top, so I can't see the complete analysis) - but clearly this path is very tight/failing...

 

But the analysis looks correct...

 

Avrum

View solution in original post

3 Replies
Historian
Historian
22,255 Views
Registered: ‎01-23-2009

Re: Generated clocks timing problem

Jump to solution

From what I can see, the timing analysis is done correctly.

 

First, realize that the source clock starts at 1.6ns and the destination at 3.2 (which is correct), so you have to subtract those off...

 

So, the insertion delay from the clock pin to the output of the MMCM on the source clock is

 

7.114 - 1.600 = 5.514

 

On the destination delay it is

 

8.328 - 3.200  = 5.128

 

The difference in insertion is 0.386ns

 

Now, you are right - since these are the same path, there should be no skew up to this point. And there isn't.  If you look further down, you will see "clock pessimism" - this is the adjustment for the fact that the the common components in the source clock delay and the destination clock delay were attributed different delays (this 0.386ns difference). In the report, the clock pessimism of 0.386 is added back into the budget, removing this source of pessimism (this is how Vivado - and other SDC based timing analysis engines do it). Thus there is no difference to this point.

 

Now for the path itself...

 

You have 1.306ns of datapath delay, 0.019ns of setup requirement on the destination flip-flop, 0.176ns of clock uncertainty (the majority of this probably comes from the potential phase difference between two outputs of the same MMCM, which is around +/-100ps, the rest probably from system jitter - have you constrained your clock jitter on the input clcok?), and some clock skew from the routing difference past the point of the MMCM. Add this all together and it comes awfully close to 1.6 (you haven't shown us all the stuff at the top, so I can't see the complete analysis) - but clearly this path is very tight/failing...

 

But the analysis looks correct...

 

Avrum

View solution in original post

Adventurer
Adventurer
11,514 Views
Registered: ‎03-23-2015

Re: Generated clocks timing problem

Jump to solution

Hi Avrumw,

  Thanks for the detailed analysis.  I got it now.  I was hoping that timing failure was due to wrong use of contraints, but I guess I really have to do some floor planning now.

 

  What is the benefits of extrapolating the analysis all the way back to input pin for generated clocks?  Would it not be easier for the generated clock path analysis starts from clkin of MMCM?  Why is it that common path from clk input pin to MMCM reports different delays?

 

  How does timing analyser behaves if the 2 generated clocks are say, source=2ns period, destination=6ns period?  THe difference is that now there are 2 source clock edges before first destination clock edge.  The first source clock edge is 4ns ahead of the destination clock, allowing data path <4ns, whereas the second source clock edge is 2ns ahead of the destination clock, allowing data path <2ns.   Will timing analyser wrongly use the first source clock edge for analysis?

 

  Anyway for completion sake, here's the summary of the timing analysis. Your calculation is spot on.

 

timing error top.png

 

Regards,

 

Neo

0 Kudos
Highlighted
Historian
Historian
11,396 Views
Registered: ‎01-23-2009

Re: Generated clocks timing problem

Jump to solution

What is the benefits of extrapolating the analysis all the way back to input pin for generated clocks?  Would it not be easier for the generated clock path analysis starts from clkin of MMCM?

 

It has to start somewhere. What if the clocks came from the same input pin, but went through two different MMCMs? What if only one of them went through an MMCM? In order to cover all cases (and also, fundamentally, due to how Vivado works), all clock propagation starts at the primary clock attach point. When there is clock reconvergence (the source and destination path contain common elements), the tools remove the pessimism with in the report (as we have seen).

 

How does timing analyser behaves if the 2 generated clocks are say, source=2ns period, destination=6ns period?

 

The way setup checks work is that the tool first looks at the unpropagated clocks to determine which edges are the launch and capture edges. Once this is determined, the clocks are propagated. So, in your case (lets assume both the source and destination are 1.6ns clocks), the setup launch edge would be at time 0, and the capture at time 1.6. After propagation, the datapath would start at time 2ns, and would have to make it before time 6+1.6, so 7.6ns.

 

Of course, this wouldn't really work, and it would be clearly reflected in the hold check - the hold would launch at 0 and be captured at 0, therefore the datapath propagation that starts at time 2ns would have to arrive after the clock arrival at time 6ns - clearly this would fail (by a lot).

 

Vivado (and Synopsys) timing analysis is very clearly defined, and is very consistent. There are a handful of rules that, if you know well, you can undertand exactly how the timing checks are performed, and exactly what the different constraints and exceptions will do. These are covered very well in the Xilinx Vivado Design Suite Advanced XDC and Static Timing Analysis for ISE Software Users class.

 

Avrum

 

 

Tags (2)
0 Kudos