TimeQuest User Guide

TimeQuest User Guide

Default Relationships

By default, all clocks are related in TimeQuest and hence have a default setup relationship and hold relationship. This is easy to see when the clocks are straightforward, such as the following which have the same period and are edge-aligned:

Most paths fall into this simple relationship, but it is important to understand how default relationships are calculated for anything more complicated. Examples would include clocks with different periods, clocks with phase-shifts or offsets, registers clocked on the falling edge, etc.

Determining Default Setup and Hold Relationships in Three Steps

There are three simple steps for determining default setup and hold relationships:

1) Draw clock waveforms based on SDC constraints

2) The default setup relationship comes from the closest edge pairs where Launch Edge

< Latch Edge

3) The default hold relationship comes from the closest edges where Launch Edge +

Setup Relationship < Latch Edge

4) Optional - Verify/Validate in TimeQuest

Note that I use equations for steps 2) and 3), but rely on the waveforms to really determine the relationships, as we'll see. Let's go through these steps in more detail:

1) Draw clock waveforms based on SDC constraints

This is the step most users want to skip. Waveforms seem simple and the user can picture them in their head, but note that I use TimeQuest every day, and still find benefit in drawing out waveforms, no matter how simple they may be. So taking some SDC constraints:

create_clock -period 10.0 -name system_clk [get_ports system_clk] create_clock -period 8.0 -name adc_clk -waveform {1.0 5.0} [get_ports adc_clk] create_clock -period 10.0 sys_clk_ext derive_pll_clocks

Info: Calling derive_pll_clocks { create_generated_clock -name sys_clk \

-source [get_ports system_clk] sys_pll|c[0] create_generated_clock -name sys_clk_shift -phase 90 \

-source [get_ports system_clk] sys_pll|c[1] create_generated_clock -name alu_clk -multiply_by 4 -divide_by 5 \



-source [get_ports system_clk] sys_pll|c[2] create_generated_clock -name sys_div2 -divide_by 2 \

-source sys_pll|c[0] [get_keepers sys_div_reg]

I show derive_pll_clocks since I recommend having that in the .sdc, but then show what generated clocks were created from that, copied from the TimeQuest messages. I also shortened the PLL names for readability. The final generated clock is on a divide-by-2 register in the design.

Anyway, drawing out the waveforms shows:

The purpose of this is not to show how to draw waveforms. Instead, let's take note of a few things:

- The waveforms are not dependent on the whether they are from create_clock or

create_generated_clock. System_clock comes in on a port, while sys_clk is the output of a PLL, but their waveforms look the same.

- The waveforms are not dependent on their target. Clock sys_clk_ext is a virtual clock that is not applied to any target, yet has the same waveform as system_clk and sys_clk.

Likewise, sys_div_2 is applied to a ripple clock register in the design, yet it's waveform is aligned with the other clocks.

- Only explicit options in the .sdc affect the waveform. Clock adc_clk has a -waveform option that offsets it by 1ns. Clock sys_clk_shift has -phase option that shifts it 90 degrees.

Clocks alu_clk and sys_div_2 use -multiply_by and -divide_by that affect the waveform.

Nothing from the user’s HDL affects what the clock waveform looks like. Obviously the clocks


in the .sdc should match the clocks in hardware, the point is that making changes in the hardware will not change these waveforms.

Now that we’ve drawn the waveforms, let's go to step 2:

2) The default setup relationship comes from the closest edge pairs where

Launch Edge < Latch Edge

This is an equation, but easier to do from our waveforms. In essence, assume every edge launches data. Start with the first launch edge in your waveform and move forward to the nearest latch edge AFTER the launch edge. A difference as littls as 1ps counts. Then go to the next launch edge and repeat. Continue until a pattern shows up(values start repeating). The smallest latch-launch value is the default setup relationship.

Let's look at a complicated example, where a register clocked by adc_clk feeds another register clocked by sys_clk. As shown above, adc_clk is an 8ns clock with a 1ns offset, and sys_clk is a 10ns clock. Finding the default setup relationship looks like so:

The waveforms were drawn per step 1, then a line was drawn from every launch edge to the nearest latch edge after it. The default setup relationship is the smallest of these lines. So in this example, any transfers from adc_clk to sys_clk will default to a 1ns setup relationship. Note that we’re not saying the other relationships don’t matter, but that if we can meet the 1ns relationship then we’ve automatically met the other setup relationships. Of course, 1ns might be too tight of a requirement, and we will shortly be analyzing exceptions, which tell TimeQuest that the default relationship is not correct.

Now, the two clocks above are definitely strange, and most designs wouldn't transfer data between them. Most transfers are between clocks that are edge-aligned, or perhaps have a manual phase shift. Some common examples:


Case #1 is just a 10ns clock edge-aligned with another 10ns clock. In the original constraints above, system_clk is what comes in the FPGA input port while sys_clk is this signal going through the PLL. Even though the clocks are created differently and applied to different targets in the design, they still have a 10ns setup relationship. Only once the placed and routed design is analyzed will the skew between these clocks be analyzed.

Cases #2 and #3 deal with sys_clk and sys_clk_shift, which is the same period as sys_clk but phase-shifted 90 degrees, or 2.5ns. When the latch clock is phase-shifted forward, the amount of that phase-shift amount of 2.5ns becomes the setup relationship. When the launch clock is phase-shifted forward, then (period - phase-shift) becomes the setup relationship.

Cases #4 and #5 deal with transfers between edge-aligned clocks, where one clock is a multiple of the other clock. In each case, the period of the faster clock becomes the default setup relationship.


These are just common examples. If ever unsure, follow Step 2) for determining the default setup relationship.

3) The default hold relationship comes from the closest edges where

Launch Edge + Setup Relationship < Latch Edge

Again this is an equation, but let's look at it from the waveforms. We have drawn them out and determined the most restrictive setup relationship. For the hold relationship, we will similarly assume that every launch edge sends data. So start with the first launch edge in the waveform, moving forward by the amount of the Setup Relationship, and then look for the first

Latch Edge before that. Let's take our previous clock transfer used for the setup relationship:

In the diagram we start at each launch edge and move forward by the setup relationship(straight green arrow). We then move back to find the first latch edge before that(curving blue arrow). The difference between the launch edge and latch edge is the hold relationship, and TimeQuest will use the most restrictive one. Note that for hold, the most restrictive is the largest number, since we need to make sure the data arrival path is larger than the data required path by the hold relationship.

Rather than strange clock relationships like this, most designs have related clocks like the following examples:


- Note that Cases #1, #4 and #5 all have hold relationships of 0ns. For transfers with aligned edges, the default hold relationship will be 0ns.

- The 0ns hold relationship is independent of the clock period. The clocks in Case #1 could have a period of 1 Hertz, and the hold relationship would still be 0ns. When designs have a timing failure, users often try to slow the clock down until it works. This is often valid for setup failures, but hold failures are generally immune and will fail at any frequency.

- Case #4 has different launch edges used for the setup relationship and the hold relationship. There is no requirement that the launch edge be the same edge for setup and hold analysis, it just works out that way most of the time. Remember that we assume all edges launch data and all edges latch data. If the user only looked at the launch edge at 10ns, they would determine the most restrictive latch edge to be at 0ns, for a hold relationship of -10ns. By looking at the other launch edges, specifically 0ns, we find a more restrictive hold relationship of

0ns, that still meets our requirement of being less than the setup relationship.


- Cases #2 and #3 are phase-shifted clocks. Note that the setup relationship - hold relationship adds up to the clock period. This is not guaranteed, but for most clock relationships this is true. It also makes sense, as that would be the fastest rate at which data can be passed between these clocks.

4) Optional - Verify/Validate in TimeQuest

The previous three steps show how to determine the default setup and hold relationship.

They are mainly for understanding, since TimeQuest will be doing this on its own and reporting it to the user. Since TimeQuest is doing this, all the user needs to do is run report_timing on a path between the specified clock domains to get the relationships. For the difficult case above, where the launch clock has an 8ns period with a 1ns offset, and the latch clock has a 10ns period, we calculated the default setup relationship to be 1ns and the default hold relationship to be -1ns.

Running report_timing -setup and report_timing -hold between these clocks in TimeQuest shows:

The left timing report shows the setup analysis, where the setup relationship is 1ns. The launch edge time is 9ns and the latch edge time is 10ns. Likewise on the right panel we see the hold analysis, where the hold relationship is -1ns, shown with a launch edge time of 1ns and latch edge time of 0ns.

Now, we already knew this would be the setup and hold relationships based on our analysis, but it's good to see the correlation with TimeQuest. Most importantly, if you're not completely sure how to calculate a relationship, you can always have TimeQuest do it for you.

Points of Interest for Default Relationships

Now that we know how to determine default setup and hold relationships, there are some points of interest worth noting:


Falling Edge Analysis

Up until now, this section has assumed the registers are clocked on the rising edge, but the analysis can also be done for registers clocked on the falling edge. Note that the steps for determining setup and hold relationships should be run independently for these transfers. In fact, when a user defines two clocks, TimeQuest determine 16 different relationships between those clocks. For example, if we define sys_clk and adc_clk, TimeQuest determines: sys_clk rising -> adc_clk rising setup relationship sys_clk rising -> adc_clk rising hold relationship sys_clk rising -> adc_clk falling setup relationship sys_clk rising -> adc_clk falling hold relationship sys_clk falling -> adc_clk rising setup relationship sys_clk falling -> adc_clk rising hold relationship sys_clk falling -> adc_clk falling setup relationship sys_clk falling -> adc_clk falling hold relationship adc_clk rising -> sys_clk rising setup relationship adc_clk rising -> sys_clk rising hold relationship adc_clk rising -> sys_clk falling setup relationship adc_clk rising -> sys_clk falling hold relationship adc_clk falling -> sys_clk rising setup relationship adc_clk falling -> sys_clk rising hold relationship adc_clk falling -> sys_clk falling setup relationship adc_clk falling -> sys_clk falling hold relationship

Now, in most designs these relationships will be the same for multiple scenarios. In determining the default setup and hold relationship for falling edge registers, just follow the same steps used, but the launch and/or latch edges should use the falling edge, depending on the situation. For example, let's look at the clock transfers we've been using, but re-analyze them when the source register is clocked on the falling edge:


Since we’re analyzing a falling launch edge to a rising latch edge, the edge of concern have been highlighted. Most falling to rising edge transfers(or vice-versa) occur within a domain, and so most relationships are like Case #1, where the setup relationship is a half period and the hold relationship is a negative half period.

Also note that the Setup Relationship - Hold Relationship still adds up to the period of the faster clock. I also think, if I had this hooked up in my design, this is the relationship I would expect. When there are problems with falling edge registers, it's usually not that the user doesn't understand the default relationships, or that the defaults are not the user's intent, it's usually that they don't realize a register is clocked on the falling edge. This results in case #1 above, where the setup relationship is half the clock period, and they end up not meeting timing. There are


some identifiable points in TimeQuest. The following report timing is on a design where there are a chain of registers, and one in the middle is clocked on the falling edge:

As can be seen, two paths have a 5ns setup relationhip. This is the Rise->Fall transfer to the register, and the Fall -> Rise transfer from the register. In the Data Path tab, the launch clock is shown with R for a rising edge while the latch clock is shown with an F for falling edge. The

Waveform tab also clearly identifies the Launch edge is rising while the Latch edge is falling.


The way to determine default setup and hold relationships requires the user to look at edges over time. Admittedly, in most cases the first edge or two is the correct one to use, but as

we'll see in a moment with unrelated clocks , it may be many cycles out in time before the most

restrictive setup or hold is found. The nice thing about this is that our waveforms are considered periodic, not just a single snapshot. For example, a designer could take a clock coming out of a

PLL and phase-shift it +270 degrees or -90 degrees, and they would get the same relationships to other clocks:


Other examples of periodicity are:

- Moving the launch clock back 90 degrees or the latch clock forward 90 degrees will result in the same relationships between those two clocks.

- Inverting a clock to a register or phase-shifting it +/-180 degrees results in the same relationships to other clocks.

This periodicity matches what occurs in hardware, so it's good to see timing analysis reflect that.

Relationships between Unrelated Clocks

What happens when two clocks are clearly unrelated? For example, what is the setup relationship if the launch clock has a 4.567ns period and the latch clock has a 7.777ns period?

TimeQuest will do exactly what it is supposed to, and find the most restrictive setup relationship over time:


Following the procedure, it finds that after launching data at time 1407.636ns, there is a latch edge exactly 1ps after that, which becomes the setup relationship. The path naturally fails timing and shows up at the top of their list.

How is a user supposed to calculate that? They're not. In reality, these clocks can't be related and the user shouldn't care how TimeQuest relates them. Instead, the user should either be fixing the data path or applying a set_clock_groups or set_false_path assignment on the path or between the clocks, to tell TimeQuest not to analyze this path in a synchronous manner. The important point is being able to recognize why this occurs.

Some users rely on this phenomenon to find code problems. For example, if they mistakenly modify their RTL so there is a path from adc_clk to sys_clk, it will get a 1ps setup relationship, fail timing, and show up at the top of their list as a failure for that domain. They then analyze the path and either realize they need to synchronize properly between the domains, or apply a set_false_path directly on the path. The problem with this is that there is no guarantee the default setup relationship will be 1ps. For example, let's say the user has two independent

20ns clocks coming into the FPGA, which they constrain like so: create_clock -period 20.0 -name clk_a [get_ports clk_a] create_clock -period 20.0 -name clk_b [get_ports clk_b]

Now, if the clocks are from independent sources, the will have no known phaserelationship and will vary from each other by some parts-per-million(PPM) difference. In essence, it will be impossible to synchronously pass data between these clock domains. But if a


user mistakenly passes a data bus from clk_a to clk_b, TimeQuest will see a default setup relationship of 20ns, the fitter will try to meet timing on those paths, and assuming it can, the paths will not show up as a timing failure. So in this case, relying on a tight relationship between unrelated clocks to identify mistakes in the code did not work.

Phase-Shift Affect on Setup and Hold

Manually phase-shifting a clock, usually done with a PLL, naturally affects the setup and hold relationships to other clocks, but it is important to understand exactly how. Let’s look at some quick examples usingthree 10ns clocks, one without any phase-shift, one with a 9ns phaseshift, and one with a 100ps phase-shift.

Case #1 shows transfers from the base clock to the 9ns phase-shifted clock. The setup relationship is 9ns and the hold is -1ns. This makes sense and probably what the user wants. But when we go to Case #2, which are transfers in the other direction, the setup relationship is 1ns


Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Related manuals

Download PDF


Table of contents