Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.

- Community Forums
- :
- Forums
- :
- Vivado RTL Development
- :
- Timing Analysis
- :
- Re: Confused by humongous time delay

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page

helmutforren

Scholar

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

02-24-2018 06:56 AM - edited 11-20-2018 12:28 PM

2,138 Views

Registered:
06-23-2014

**[EDIT: This problem was caused by missing or incorrect Clock Domain Crossing logic. If this happens to me again, or to you, go looking around for missing or incorrect CDC logic first.]**

I'm confused by the 20,000+ nanosecond delay in the timing report and code excerpts below. I've never seen anything this big, and I can't imagine there's any accuracy in it proportionally. (That is, my clock is 5000ns. The source and destination clocks each have 4 times that in initial delay. Without considering their common ancestry, any small percentage error in these clock path delays translates into a large error for the time for the data path to fit in.)

I thought Vivado should deal with the PLL appropriately and have smaller numbers?

Now, it's true that I crossed a clock domain and I'm going to fix that. But I want to better understand this before I make it go away. Specifically, the PLL has two outputs. One output (12MHz) is used to generate the beginning of the data path (name fully blacked out). The other output (31.875MHz) , not an even multiple of the first output, is divided by 8 using a 7SERIES BUFR to produce a third clock; this third clock is used to generate the end of the data path by using the result of the beginning of the data path. This is the clock domain crossing and I can fix that with dual flip flops / metastable / constraint set_false_path. So I think I can make the error go away and I believe it's appropriate to do this.

But still, why the 20,000+ nanosecond initial delay in the two clock paths?

-------------------------------------

-------------------------------------

1 Solution

Accepted Solutions

helmutforren

Scholar

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

11-20-2018 12:27 PM

1,175 Views

Registered:
06-23-2014

@austin is correct below. I'm posting now to try and add additional info, marked as correct solution.

SPECIFICALLY, if you get such huge times in a timing report, go look for missing or incorrect clock domain crossing logic.

@austin wrote:Vivado assumes all paths are synchronous,

So this is a natural result. You require false path constraints and CDC async stages crossing the clock domains.

As you see, the numbers are meaningless: a result of arithmetic on async clocks assumed to be synchronous.

7 Replies

austin

Scholar

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

02-24-2018 07:36 AM

2,863 Views

Registered:
02-27-2008

Vivado assumes all paths are synchronous,

So this is a natural result. You require false path constraints and CDC async stages crossing the clock domains.

As you see, the numbers are meaningless: a result of arithmetic on async clocks assumed to be synchronous.

Austin Lesea

Principal Engineer

Xilinx San Jose

Principal Engineer

Xilinx San Jose

helmutforren

Scholar

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

02-24-2018 08:30 AM

2,117 Views

Registered:
06-23-2014

@austin thanks for the quick reply. I don't __fully__ understand what you're saying. I do understand that I need the false path constraint, and I think "CDC async stages" means what I understand as two sequential flip flops. When you say its the result of assumption, **do you mean that after I add the constraint/stages, those very large numbers should disappear from the timing report?**

(((*Well, I have since built that. The timing error indeed went away, as expected. With no timing error to get me there, I'm currently opening the implemented design and trying to look for the same path. (There won't be exactly the same path because I cleaned something up.) I can NOT find the "...falling_edge" signal at all, anymore. I'm looking at the [Device] Netlist, inside the appropriate module, at the Nets. *

*Thanks for the answer. I will NOT pursue this any further. That is, I won't try to confirm/prove the large numbers went away, because I can't find them in the implemented design.)))*

avrumw

Guide

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

02-24-2018 07:16 PM

2,071 Views

Registered:
01-23-2009

Your numbers are not consistent.

The RTL code says the clocks should be 31.875MHz and 12MHz, which would be a ratio of 85/32.

However, the periods reported by the clocks are 41.667ns (24MHz) and 125.49ns (7.968762)MHz for a ratio of 256/85. These are a very odd ratio.

Since 256 and 85 have no common divisors, the pattern of these clocks will only repeat after 256 cycles of the 41.6667ns clock and 85 cycles of the 125.49ns clock; the next alignment (after time 0) of the edges occurs at time 10,666.67ns (assuming the ratios are really 256/85 - they may not be, but that is my best guess due to the limit of the accuracy I can see from the report).

The way static timing works with different clocks in Vivado is that the tool looks at the first 1000 edges of the clock of the startpoint and the first thousand edges of the clock of the endpoint. For each startpoint edge, it finds the endpoint edge that follows it most closely. Of all these edges, it finds the ones that are closest together; these becomes the launch edge and capture edge of the static timing check, and, in turn, determine the requirement of the path.

In this case, the tools found that the startpoint edge at 21583.334, which appers to be the 518th edge of the 41.667ns clock, comes the closest to the endpoint edge at 21584.312, which appears to be the 172nd edge of the 125.49ns clock; these two clocks come within 0.979ns of each other. These are the launch and capture edges that the tool used.

So, I can't fully explain **why** these edges - if I were correct about the PLL ratios (256/85), then the closest approach should have been somewhere before 10,666.67, rather than where they are (at more than twice that). So either my estimate of the ratios is wrong, or you are falling into a case where the rounding error of the two periods is messing up the calculation and ending up with different edges.

In either case, though, the tools are basically telling you "You cannot cross synchronously between these domains - even though they are synchronous domains - due to the fact that the ratios are just too odd". So even though these two clocks come from the same source (and hence are technically synchronous), if you need to bring data between them, you need to do some kind of clock domain crossing, since, as the tool show, the 0.979ns requirement cannot be met.

Once you put a clock domain crossing circuit between them, this allows you to bring data across these domains **asynchronously** - the presence of a (correct) clock domain crossing circuit would allow you to put a timing exception on the path between the domains; the type and magnitude of the exception would depend on the clock domain crossing circuit.

Avrum

helmutforren

Scholar

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

02-25-2018 05:59 AM

2,047 Views

Registered:
06-23-2014

@avrumw thanks.

1) Note that I was immediately aware of needing the clock crossing logic. I just wasn't aware that this itself was causing the 20,000+ numbers.

2) I understand your numerical analysis. One factor you may be missing is the BUFR doing the divide by 8. This converts the 31.875MHz into 3.984375MHz (appears to be half of one number you mentioned). This may not help the common factor calculation you're doing, but it might be involved.

3) I understand your numerical analysis. It doesn't matter any more, since I've added the clock crossing logic. Let's not lose any more time over this!

Thanks again,

Helmut

avrumw

Guide

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

02-25-2018 08:28 AM

2,036 Views

Registered:
01-23-2009

It is worth pointing out that a BUFG->BUFR connection is an unusual connection. There is no dedicated connection between these two domains, and there is no skew matching for domains using these different resources.

The division function of the BUFR is intended to be used pretty much only for cases where you are using an ISERDES/OSERDES; where the high speed clock of the ISERDES/OSERDES is driven by the BUFIO and the low speed is driven by the BUFR (with division). It is not intended to be a "general purpose" clock divider...

Avrum

helmutforren

Scholar

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

02-25-2018 12:42 PM

2,011 Views

Registered:
06-23-2014

@avrumw : acknowledged

helmutforren

Scholar

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

11-20-2018 12:27 PM

1,176 Views

Registered:
06-23-2014

@austin is correct below. I'm posting now to try and add additional info, marked as correct solution.

SPECIFICALLY, if you get such huge times in a timing report, go look for missing or incorrect clock domain crossing logic.

@austin wrote:Vivado assumes all paths are synchronous,

So this is a natural result. You require false path constraints and CDC async stages crossing the clock domains.

As you see, the numbers are meaningless: a result of arithmetic on async clocks assumed to be synchronous.