7. Best Practices for the Quartus II TimeQuest Timing Analyzer

December 2010 

QII53024-10.1.0 

QII53024-10.1.0 

© 2010 Altera Corporation. All rights reserved. ALTERA, ARRIA, CYCLONE, HARDCOPY, MAX, MEGACORE, NIOS, QUARTUS and STRATIX are Reg. U.S. Pat. & Tm. Off. 

and/or trademarks of Altera Corporation in the U.S. and other countries. All other trademarks and service marks are the property of their respective holders as described at 

www.altera.com/common/legal.html. Altera warrants performance of its semiconductor products to current specifications in accordance with Altera’s standard warranty, but 

reserves the right to make changes to any products and services at any time without notice. Altera assumes no responsibility or liability arising out of the application or use of any 

information, product, or service described herein except as expressly agreed to in writing by Altera. Altera customers are advised to obtain the latest version of device 

specifications before relying on any published information and before placing orders for products or services. 

Quartus II Handbook Version 11.0 Volume 3: Verification 

December 2010 

7. Best Practices for the Quartus II 

TimeQuest Timing Analyzer 

Timing constraints and exceptions are vital to all designs that target FPGAs because 

they allow designers to specify requirements and verify timing of their systems or 

FPGAs. Constraints and exceptions allow the Fitter to spend more time fitting the 

critical paths in your design and reduce the amount of time spent on noncritical parts 

of the design. 

This chapter provides recommendations on how to fully constrain an FPGA design 

with the Quartus ® II TimeQuest Timing Analyzer. The sections are ordered in the 

recommended flow for applying timing constraints and exceptions in the TimeQuest 

analyzer. 

f For more information about interactive timing analysis, refer to the TimeQuest Timing 

Analyzer Quick Start Tutorial. 

f For more information about Altera resources available for the TimeQuest analyzer, 

refer to the TimeQuest Timing Analyzer Resource Center of the Altera website. 

f For more information about constraining circuits and reporting timing analysis 

results in the TimeQuest analyzer, including examples, refer to the TimeQuest Design 

Examples page of the Altera website and the Quartus II TimeQuest Timing Analyzer 

Cookbook. 

f For more information about constraints and exceptions supported by the TimeQuest 

analyzer, refer to the Quartus II TimeQuest Timing Analyzer chapter in volume 3 of the 

Quartus II Handbook. 

h For more information about TimeQuest analyzer Tcl commands and a complete list of 

commands, refer to ::quartus::sta in Quartus II Help. For more information about 

standard SDC commands and a complete list of commands, refer to ::quartus::sdc in 

Quartus II Help. For more information about Altera extensions of SDC commands 

and a complete list of commands, refer to ::quartus::sdc_ext in Quartus II Help. 

This chapter contains the following sections: 

■ “Creating Clock Requirements” on page 7–2 

■ “Creating I/O Requirements” on page 7–5 

■ “Creating Timing Exceptions” on page 7–7 

Subscribe

7–2 Chapter 7: Best Practices for the Quartus II TimeQuest Timing Analyzer 

Creating Clock Requirements 


The TimeQuest analyzer supports the following types of clocks: 

■ Base clocks 

■ Derived clocks 

■ Virtual clocks 

Clocks are used to specify register-to-register requirements for synchronous transfers 

and guide the Fitter optimization algorithms to achieve the best possible placement 

for your design. 

Specify clock constraints first in Synopsys Design Constraint Files (.sdc) because other 

constraints may reference previously defined clocks. The TimeQuest analyzer reads 

SDC constraints and exceptions from top to bottom in the file. 

f For more information about creating clocks and clock constraints, refer to the 

Quartus II TimeQuest Timing Analyzer chapter in volume 3 of the Quartus II Handbook. 

Base Clocks 

Base clocks are the primary input clocks to the FPGA. Unlike clocks from 

phase-locked loops (PLLs) that are derived within the FPGA, base clocks are usually 

generated in off-chip oscillators or forwarded from an external device. Define base 

clocks first because derived clocks and other constraints can reference the base clocks. 

Use the create_clock command to constrain all primary input clocks. The target for 

the create_clock command is usually an FPGA device pin. To specify the FPGA 

device pin as the target, use the get_ports command. Example 7–1 shows how to 

specify a 100-MHz requirement on a clk_sys input clock port. 

Example 7–1. create_clock Command 

create_clock -period 10 -name clk_sys [get_ports clk_sys] 

You can apply multiple clocks on the same clock node with the -add option. 

Example 7–2 shows how to specify that two oscillators drive the same clock port on 

the FPGA. 

Example 7–2. Two Oscillators Driving the Same Clock Port 

create_clock -period 10 -name clk_100 [get_ports clk_sys] 

create_clock -period 5 -name clk_200 [get_ports clk_sys] -add 

h For more information about the create_clock and get_ports commands—including 

full syntax information, options, and example usage—refer to create_clock and 

get_ports in Quartus II Help. 

Quartus II Handbook Version 11.0 Volume 3: Verification December 2010 Altera Corporation

Chapter 7: Best Practices for the Quartus II TimeQuest Timing Analyzer 7–3 


Derived Clocks 

Derived clocks are generated in the FPGA when you modify the properties, including 

phase, frequency, offset, and duty cycle, of a source clock signal. Derived clocks, 

which are PLLs or register clock dividers, are constrained after all base clocks are 

constrained in the .sdc. Derived clocks capture all clock delays and clock latency 

where the derived clock target is defined, ensuring that all base clock properties are 

accounted for in the derived clock. 

You can use the create_generated_clock command to constrain all generated clocks 

in your design. The source of the create_generated_clock command should be a 

node in your design and not a previously constrained clock. 

Example 7–3 shows a divide-by-two clock divider. 

Use the create_generated_clock command with the -source option when you 

specify multiple clock constraints for the same pin in a design. When you use the 

create_generated_clock command, the -source option should refer to the nearest 

clock pin of the specified target. Do not use the clock port as the source for a generated 

clock, because multiple source clocks can feed the clock port. In Example 7–3, the 

-source option assigns the clock pin of the register as the source for the generated 

clock instead of the clock port clk feeding the register’s reg clock pin. 

The TimeQuest analyzer provides the derive_pll_clocks command to automatically 

generate derived clocks for all PLL clock outputs. The properties of the generated 

clocks on the PLL outputs match the properties defined for the PLL. 

h For more information about the create_generated_clock and derive_pll_clocks 

commands—including for full syntax information, options, and example usage—refer 

to create_generate_clock and derive_pll_clocks in Quartus II Help. 

Virtual Clocks 

Example 7–3. Clock Divider 

create_clock -period 10 -name clk_sys [get_ports clk_sys] 

create_generated_clock -name clk_div_2 -divide_by 2 -source 

[get_pins reg|clk] [get_pins reg|regout] 

A virtual clock does not have a real source in your design and does not interact 

directly with your design. You can create virtual clocks with the create_clock 

command, with no targets specified. Example 7–4 shows how to create a 10 ns virtual 

clock. 

Example 7–4. Create Virtual Clock 

create_clock -period 10 -name my_virt_clk 

If you use the derive_clock_uncertainty command for your design, use virtual 

clocks with the set_input_delay and set_output_delay commands. It is important to 

use virtual clocks to allow the TimeQuest analyzer to calculate clock uncertainty 

separately for I/O interfaces and internal register-to-register paths. 

December 2010 Altera Corporation Quartus II Handbook Version 11.0 Volume 3: Verification



If an FPGA interfaces with an external device, and both the FPGA and external device 

have different clock sources, you should model the clock source for the external 

device with a virtual clock. 

h For more information about the set_input_delay, set_output_delay, and 

derive_clock_uncertainty commands—including full syntax information, options, 

and example usage—refer to set_input_delay, set_output_delay, and 

derive_clock_uncertainty in Quartus II Help. 

Figure 7–1 shows a typical I/O interface that contains an FPGA that interfaces with an 

external device and also shows a virtual clock. Example 7–5 shows how to create an 

equivalent virtual clock for each clock in your design that feeds an input or output 

port. 

Figure 7–1. Design with Virtual Clock 

External Device 

Altera FPGA 

data_in 

D reg1 Q D reg1 Q 

Example 7–5. Commands to Create Clocks 

100 MHz 

# Create the base clock for the clock port 

create_clock –period 10 –name clk_in [get_ports clk_in] 

# Create a virtual clock with the same properties of the base clock 

# driving the source register 

create_clock –period 10 –name virt_clk_in 

# Create the input delay referencing the virtual clock and not the base 

# clock 

# DO NOT use set_input_delay –clock clk_in 

# [get_ports data_in] 

set_input_delay –clock virt_clk_in [get_ports data_in] 

Quartus II Handbook Version 11.0 Volume 3: Verification December 2010 Altera Corporation 

clk_in


Creating I/O Requirements 


Figure 7–2 shows a design that contains an FPGA that interfaces with an external 

device and also shows the base clock and the virtual clock. Example 7–6 shows how to 

create virtual clock for the design. 

Figure 7–2. Design with Base Clock and Virtual Clock 


Example 7–6. Commands to Create Clocks 

D 

reg1 

data_out 

data_in 

Altera FPGA 

Q D Q 

50 MHz 100 MHz 

#create base clock for the design 

create_clock -period 10 -name clk_in [get_ports clk_in] 

#create the virtual clock for the external register 

create_clock -period 20 -name virt_clk -waveform {0 10} 

#set the output delay referencing the virtual clock 

set_output_delay -clock virt_clk -max 1.5 [get_ports data_out] 

You should specify timing requirements, including internal and external timing 

requirements, before you fully analyze a design. With external timing requirements 

specified, the TimeQuest analyzer verifies the I/O interface, or periphery of the 

FPGA, against any system specification. The TimeQuest analyzer supports input and 

output external delay modeling. 

You should specify I/O requirements after you constrain all clocks in your design. 

When specifying I/O requirements, reference a virtual clock in the constraints. 

f For more information about specifying I/O interface requirements and uncertainty, 

refer to the Quartus II TimeQuest Timing Analyzer chapter in volume 3 of the Quartus II 

Handbook. 

December 2010 Altera Corporation Quartus II Handbook Version 11.0 Volume 3: Verification 

clk_in 

Virtual Clock Base Clock 

reg1



Input Constraints 

Input constraints allow you to specify all the external delays feeding into the FPGA. 

Specify input requirements for all input ports in your design. 

You can use the set_input_delay command to specify external input delay 

requirements. Use the -clock option to reference a virtual clock. Using a virtual clock 

allows the TimeQuest analyzer to correctly derive clock uncertainties for interclock 

and intraclock transfers. The virtual clock defines the launching clock for the input 

port. The TimeQuest analyzer automatically determines the latching clock inside the 

device that captures the input data, because all clocks in the device are defined. 

Figure 7–3 shows an example of an input delay referencing a virtual clock. 

Figure 7–3. Input Delay 

Equation 7–1 shows a typical input delay calculation. 

Equation 7–1. Input Delay Calculation 

Output Constraints 


tco_ext 

cd_ext 

Oscillator 

Altera Device 

Output constraints allow you to specify all external delays from the FPGA for all 

output ports in your design. 

You can use the set_output_delay command to specify external output delay 

requirements. Use the -clock option to reference a virtual clock. The virtual clock 

defines the latching clock for the output port. The TimeQuest analyzer automatically 

determines the launching clock inside the device that launches the output data, 

because all clocks in the device are defined. Figure 7–4 shows an example of an output 

delay referencing a virtual clock. 


dd 

cd_altr 

input delayMAX = �cd_extMIN – cd_altrMAX�+ tco_extMAX + ddMAX input delayMIN = �cd_extMAX – cd_altrMIN�+ tco_extMIN + ddMIN Figure 7–4. Output Delay 

Altera Device 

cd_altr 

Oscillator 

dd 

cd_ext 


tsu_ext/th_ext


Creating Timing Exceptions 

Equation 7–2 shows a typical output delay calculation. 

h For more information about the set_input_delay and set_output_delay 

commands—including full syntax information, options, and example usage—refer to 

set_input_delay and set_output_delay in Quartus II Help. 

Creating Timing Exceptions 

Timing exceptions in the TimeQuest analyzer provide a way to modify the default 

timing analysis behavior to match the analysis required by your design. Specify 

timing exceptions after clocks and input and output delay constraints because timing 

exceptions can modify the default analysis. The TimeQuest analyzer supports the 

following three major categories of timing exceptions: 

■ False paths 

■ Minimum and maximum delays 

■ Multicycle paths 

f For more information about creating timing exceptions, refer to the Quartus II 

TimeQuest Timing Analyzer chapter in volume 3 of the Quartus II Handbook. 

False Paths 

Equation 7–2. output Delay Calculation 

input delayMAX = ddMAX – tsu_ext + �cd_altrMIN – cd_extMAX� input delayMIN = ddMIN – th_ext + �cd_altrMAX – cd_extMIN� Specifying a false path in your design removes the path from timing analysis. Use the 

set_false_path command to specify false paths in your design. You can specify 

either a point-to-point or clock-to-clock path as a false path. For example, a path you 

should specify as false path is a static configuration register that is written once 

during power-up initialization, but does not change state again. Although signals 

from static configuration registers often cross clock domains, you may not want to 

make false path exceptions to a clock-to-clock path, because some data may transfer 

across clock domains. However, you can selectively make false path exceptions from 

the static configuration register to all endpoints. 

Example 7–7 shows how to make false path exceptions from all registers beginning 

with A to all registers beginning with B. 

Example 7–7. False Path 

set_false_path -from [get_pins A*] -to [get_pins B*] 

The TimeQuest analyzer assumes all clocks are related unless you specify otherwise. 

You can use clock groups to make false path exceptions for clock-to-clock timing 

relationships in your design. Clock groups are a more efficient way to make false path 

exceptions between clocks, compared to writing multiple set_false_path exceptions 

between every clock transfer you want to eliminate. 



Creating Multicycle Exceptions 

1 The TimeQuest analyzer runs more efficiently with clock groups rather than 

individual false path assignments. 

Use the set_clock_groups command to collect groups of signals related to each other, 

and use the -asynchronous option to specify that each group of clocks is 

asynchronous with each other. If you apply multiple clocks to the same port, use the 

set_clock_groups command with the -exclusive option to place the clocks into 

separate groups and declare that the clocks are mutually exclusive. The clocks cannot 

physically exist in your design at the same time. 

h For more information about the set_clock_groups and set_false_path commands— 

including full syntax information, options, and example usage—refer to 

set_clock_groups and set_false_path in Quartus II Help. 

Minimum and Maximum Delays 

Specifying minimum and maximum delay constraints in your design creates a 

bounded minimum and maximum path delay. Use the set_min_delay and 

set_max_delay commands to create constraints for asynchronous signals that do not 

have a specific clock relationship in your design, but require a minimum and 

maximum path delay. You can create minimum and maximum delay exceptions for 

port-to-port paths through the FPGA without a register stage in the path. If you use 

minimum and maximum delay exceptions to constrain the path delay, specify both 

the minimum and maximum delay of the path; do not constrain only the minimum or 

maximum value. 

You can also use the set_net_delay command to specify the minimum delay, 

maximum delay, or skew for any edge in your design when no clock relationships are 

defined or required. 

h For more information about the set_min_delay, set_max_delay, and set_net_delay 

commands—including full syntax information, options, and example usage—refer to 

set_min_delay, set_max_delay, and set_net_delay in Quartus II Help. 


By default, the TimeQuest analyzer uses single-cycle path analysis. The TimeQuest 

Timing Analyzer examines all register-to-register paths and performs setup and hold 

check analysis on those paths. The setup and hold check analysis evaluates the launch 

and latch edge relationships. When analyzing a path, the TimeQuest analyzer 

determines the setup launch and latch edge times by finding the closest two active 

edges in the respective waveforms. When analyzing setup and hold relationships, the 

TimeQuest analyzer analyzes the path against two timing conditions for every 

possible setup relationship, not just the worst-case setup relationship; therefore, the 

hold launch and latch times may be unrelated to the setup launch and latch edges. 

The TimeQuest analyzer does not report negative setup or hold relationships. When 

either a negative setup or a negative hold relationship is calculated, the TimeQuest 

analyzer moves both the launch and latch edges such that the setup and hold 

relationship becomes positive. 




Multicycle exceptions relax the timing requirements for a register-to-register path, 

allowing the Fitter to optimally place and route a design in an FPGA. Multicycle 

exceptions also can reduce compilation time and increase the quality of results. 

For example, if your design contains a long combinational path in which the latching 

register does not require data stability on every clock edge, but only on every second 

clock edge, you can assign a multicycle exception to the path. The multicycle path is 

dependent on the endpoint register’s use of the clock signal. Example 7–8 shows how 

to create a multicycle path for the combinational path where the data is stable at the 

endpoint every two clock cycles of the endpoint latch clock. 

Example 7–8. Multicycle Path 

set_multicycle_path -setup 2 

If you specify a multicycle path, define both the setup and hold multicycle 

relationships. For the preceding example, setting data at the endpoint can take two 

clock cycles and the minimum hold time relationship is defined with a multicycle 

exception as well. Use the set_multicycle_path command with the -hold option to 

define the hold relationship. The value of the -hold option is (N – 1), where N is equal 

to the multicycle setup assignment value for a register-to-register path in the same 

clock domain. However, if data crosses different clock domains, the phase and period 

of the launch and latch clock may change the default multicycle setup and hold 

values. If you use multicycle paths that cross different clock domains, you must 

carefully examine the timing paths in the TimeQuest analyzer before and after 

applying the multicycle exception to determine if the launch and latch clock edges 

function as you intend. 

h For more information about the set_multicycle_path command, including full 

syntax information, options, and example usage, refer to set_multicycle_path in 

Quartus II Help. 

Multicycle Clock Setup Check and Hold Check Analysis 

You can modify the setup and hold relationship when you apply a multicycle 

exception to a register-to-register path. Figure 7–5 shows a register-to-register path 

with various timing parameters labeled. 

Figure 7–5. Register-to-Register Path 

CLK 

T clk1 

REG1 REG2 

SET Combinational 

SET 

D Q D Q 

Logic 

CLR CLR 

TCO Tclk2 T / T SU H 


T data



Multicycle constraints adjust setup or hold relationships by the specified number of 

clock cycles based on the source (-start) or destination (-end) clock. An end 

multicycle setup constraint of two extends the worst-case setup latch edge by one 

destination clock period. 

Hold multicycle constraints are based on the hold position—the default hold position 

is zero. An end multicycle hold constraint of one effectively subtracts one destination 

clock period from the default hold latch edge. 

To specify the multicycle constraints in your design, use the set_multicycle_path 

command. 

h For more information about the set_multicycle_path command, including full 

syntax information, options, and example usage, refer to set_multicycle_path in 

Quartus II Help. 

Table 7–1. Common Multicycle Assignments 

If you specify a multicycle constraint between timing nodes, the multicycle constraint 

applies only to the path between the two nodes. If you specify a multicycle constraint 

for a clock, the multicycle constraint applies to all paths where the source node 

(-from) or destination node (-to) is clocked by the clock. 

Table 7–1 summarizes commonly used multicycle assignments. 

Type Clock Timing Check SDC Command 

End Multicycle Setup Destination Setup 

End Multicycle Hold Destination Hold 

Start Multicycle Setup Source Setup 

Start Multicycle Hold Source Hold 

Multicycle Clock Setup 

set_multicycle_path 

–end –setup 


–end –hold 


–start –setup 


–start -hold 

The setup relationship is defined as the number of clock periods between the latch 

edge and the launch edge. By default, the TimeQuest analyzer performs a single-cycle 

path analysis, which results in the setup relationship being equal to one clock period 

(latch edge – launch edge). When analyzing a path, the TimeQuest analyzer 

determines the setup launch and latch edge times by finding the closest two active 

edges in the respective waveforms. Applying a multicycle setup assignment, 

increases—or relaxes—the setup relationship by the multicycle setup value. 




Figure 7–6. End Multicycle Setup Values 

For every register-to-register path, the TimeQuest analyzer calculates the setup slack 

for the path. Equation 7–3 shows the setup slack calculation. 

Equation 7–3. Setup Slack (1) (2) (3) (4) (5) (6) 

setup slack = data required time – data arrival time 

= �latch edge + tclk2 – tSU�– �launch edge + tclk1 + tCO + tdata� = �latch edge – launch edge�+ 

�tclk2 – tclk1�– �tCO + tdata + tSU� Notes to Equation 7–3: 

(1) tclk1 = the propagation delay from clock source to clock input on source register 

(2) tclk2 = the propagation delay from clock source to clock input on destination register 

(3) tdata = the propagation delay from source register to data input on destination register 

(4) tCO = the clock to output delay of source register 

(5) tSU = the setup requirement of destination register 

(6) tH = the hold requirement of destination register 

An end multicycle setup assignment modifies the latch edge of the destination clock 

by moving the latch edge the specified number of clock periods to the right of the 

determined default latch edge. Figure 7–6 shows various values of the end multicycle 

setup assignment and the resulting latch edge. 

REG1.CLK 

REG2.CLK 

-10 0 10 20 

EMS = 1 

(default) 


EMS = 2 

EMS = 3



Figure 7–7. Start Multicycle Setup Values 

Source Clock 

Destination Clock 

A start multicycle setup assignment modifies the launch edge of the source clock by 

moving the launch edge the specified number of clock periods to the left of the 

determined default launch edge. Figure 7–7 shows various values of the start 

multicycle setup assignment and the resulting launch edge. 

-20 -10 

0 10 20 

SMS = 3 

SMS = 2 

Figure 7–8 shows the setup relationship reported by the TimeQuest analyzer for the 

negative setup relationship shown in Figure 7–7. 

Multicycle Clock Hold 

SMS = 1 

(default) 

Figure 7–8. Start Multicycle Setup Values Reported by the TimeQuest Analyzer 

Source Clock 


-10 0 10 20 

SMS = 1 

(default) 

The hold relationship is defined as the number of clock periods between the launch 

edge and the latch edge. By default, the TimeQuest analyzer performs a single-cycle 

path analysis, which results in the hold relationship being equal to one clock period 

(launch edge – latch edge). When analyzing a path, the TimeQuest analyzer performs 

two hold checks. The first hold check determines that the data launched by the 

current launch edge is not captured by the previous latch edge. The second hold check 

determines that the data launched by the next launch edge is not captured by the 

current latch edge. The TimeQuest analyzer reports only the most restrictive hold 

check. Equation 7–4 shows the calculation that the TimeQuest analyzer performs to 

determine the hold check. 

Equation 7–4. Hold Check 


SMS = 2 

hold check 1 = current launch edge – previous latch edge 

hold check 2 = 

next launch edge – current latch edge 

SMS = 3



1 If a hold check overlaps a setup check, the hold check is ignored. 

Figure 7–9. Start Multicycle Hold Values 

Applying a multicycle hold assignment, increases—or relaxes—the hold slack 

equation by the number of specified clock cycles. 

For every register-to-register path, the TimeQuest analyzer calculates the hold slack 

for the path. Equation 7–5 shows the hold slack calculation. 

Equation 7–5. Hold Slack (1) (2) (3) (4) (5) (6) 

hold slack = data arrival time – data required time 

= �launch edge + tclk1 + tCO + tdata�– �latch edge + tclk2 – tH� = �launch edge – latch edge�– 

�tclk2 – tclk1�+ �tCO + tdata – tH� Notes to Equation 7–5: 

(1) tclk1 = the propagation delay from clock source to clock input on source register 

(2) tclk2 = the propagation delay from clock source to clock input on destination register 

(3) tdata = the propagation delay from source register to data input on destination register 

(4) tCO = the clock to output delay of source register 

(5) tSU = the setup requirement of destination register 

(6) tH = the hold requirement of destination register 

A start multicycle hold assignment modifies the launch edge of the destination clock 

by moving the latch edge the specified number of clock periods to the right of the 

determined default launch edge. Figure 7–9 shows various values of the start 

multicycle hold assignment and the resulting launch edge. 

Source Clock 


-10 0 10 20 

SMH = 0 

(default) 


SMH = 1 

SMH = 1



Figure 7–10. End Multicycle Hold Values 

Source Clock 


An end multicycle hold assignment modifies the latch edge of the destination clock by 

moving the latch edge the specific ed number of clock periods to the left of the 

determined default latch edge. Figure 7–10 shows various values of the end 

multicycle hold assignment and the resulting latch edge. 

-20 -10 

0 10 20 

EMH = 2 

EMH = 1 

Figure 7–11 shows the hold relationship reported by the TimeQuest analyzer for the 

negative hold relationship shown in Figure 7–10. 

Examples of Basic Multicycle Exceptions 

This section describes the following examples of combinations of multicycle 

exceptions: 

■ “Default Settings” on page 7–15 

EMH= 0 

(default) 

Figure 7–11. End Multicycle Hold Values Reported by the TimeQuest Analyzer 

Source Clock 


-10 0 10 20 

EMH = 0 

default) 

EMH = 2 

EMH = 1 

■ “End Multicycle Setup = 2 and End Multicycle Hold = 0” on page 7–17 



■ “Start Multicycle Setup = 2 and Start Multicycle Hold = 0” on page 7–26 






Each example explains how the multicycle exceptions affect the default setup and 

hold analysis in the TimeQuest analyzer. The multicycle exceptions are applied to a 

simple register-to-register circuit. Both the source and destination clocks are set to 

10 ns. 

Default Settings 

Figure 7–12. Default Timing Diagram 

By default, the TimeQuest analyzer performs a single-cycle analysis to determine the 

setup and hold checks. Also, by default, the TimeQuest Timing Analyzer sets the end 

multicycle setup assignment value to one and the end multicycle hold assignment 

value to zero. 

Figure 7–12 shows the source and the destination timing waveform for the source 

register and destination register, respectively. 

REG1.CLK 

REG2.CLK 

-10 0 10 20 

Current Launch 

HC1 

0 1 2 

Current Latch 

Equation 7–6 shows the calculation that the TimeQuest analyzer performs to 

determine the setup check. 

Equation 7–6. Setup Check 

setup check = current latch edge – closest previous launch edge 

= 10ns – 0ns 

= 10ns 

The most restrictive setup relationship with the default single-cycle analysis, that is, a 

setup relationship with an end multicycle setup assignment of one, is 10 ns. 


SC 

HC2



Figure 7–13. Setup Report 

Figure 7–13 shows the setup report for the default setup in the TimeQuest analyzer 

with the launch and latch edges highlighted. 


determine the hold check. Both hold checks are equivalent. 

Equation 7–7. Hold Check 

hold check 1 = next launch edge – current latch edge 

= 0ns – 0ns 

= 0ns 

hold check 2 = 10 ns – 10 ns 

= 0 ns 

The most restrictive hold relationship with the default single-cycle analysis, that a 

hold relationship with an end multicycle hold assignment of zero, is 0 ns. 




Figure 7–14. Hold Report 

Figure 7–14 shows the hold report for the default setup in the TimeQuest analyzer 

with the launch and latch edges highlighted. 

End Multicycle Setup = 2 and End Multicycle Hold = 0 

In this example, the end multicycle setup assignment value is two, and the end 

multicycle hold assignment value is zero. Example 7–9 shows the multicycle 

exceptions applied to the register-to-register design for this example. 

Example 7–9. Multicycle Exceptions 

set_multicycle_path -from [get_clocks clk_src] -to [get_clocks clk_\ 

dst] -setup -end 2 

1 An end multicycle hold value is not required because the default end multicycle hold 

value is zero. 

In this example, the setup relationship is relaxed by a full clock period by moving the 

latch edge to the next latch edge. The hold analysis is unchanged from the default 

settings. 




Figure 7–15. Setup Timing Diagram 

Figure 7–15 shows the setup timing diagram. The latch edge is a clock cycle later than 

in the default single-cycle analysis. 

REG1.CLK 

REG2.CLK 


-10 0 


10 20 

Current Latch 





= 20 ns – 0 ns 

= 20 ns 

The most restrictive setup relationship with an end multicycle setup assignment of 

two is 20 ns. 

Figure 7–16 shows the setup report in the TimeQuest analyzer with the launch and 

latch edges highlighted. 


SC



Figure 7–17. Hold Timing DIagram 

Because the multicycle hold latch and launch edges are the same as the results of hold 

analysis with the default settings, the multicycle hold analysis in this example is 

equivalent to the single-cycle hold analysis. Figure 7–17 shows the timing diagram for 

the hold checks for this example. The hold checks are relative to the setup check. 

Usually, the TimeQuest analyzer performs hold checks on every possible setup check, 

not only on the most restrictive setup check edges. 

REG1.CLK 

REG2.CLK 

-10 0 


10 20 

Data HC1 SC 

HC2 

Current Latch 





= 0 ns – 10 ns 

= – 10 ns 


= 10 ns – 20 ns 

= – 

10 ns 

The most restrictive hold relationship with an end multicycle setup assignment value 

of two and an end multicycle hold assignment value of zero is 10 ns. 





Figure 7–18 shows the hold report for this example in the TimeQuest analyzer with 

the launch and latch edges highlighted. 


In this example, the end multicycle setup assignment value is one, and the end 

multicycle hold assignment value is one. Example 7–10 shows the multicycle 




dst] -hold -end 1 

1 An end multicycle setup value is not required because the default end multicycle 

setup value is one. 

In this example, the hold relationship is relaxed by one clock period by moving the 

latch edge to the previous latch edge. The setup analysis is unchanged from the 

default settings. 





Figure 7–19 shows the setup timing diagram. The latch edge is the same as the default 

single-cycle analysis. 

SRC.CLK 

DST.CLK 

-10 0 

Current 

Launch 

10 20 

HC1 



The most restrictive setup relationship with an end multicycle setup assignment of 

one is 10 ns. 


SC 

HC2 

Current 

Latch 



= 10 ns – 0 ns 

= 10 ns




Figure 7–21. Hold Timing Diagram 



Figure 7–21 shows the timing diagram for the hold checks for this example. The hold 

checks are relative to the setup check. 

SRC.CLK 

DST.CLK 

-10 0 

Current 

Launch 

10 20 

HC1 


SC 

HC2 

Current 

Latch








= 0 ns – �– 10 ns� 

= 10 ns 


= 10 ns – 0 ns 

= 10 ns 


of one and an end multicycle hold assignment value of one is 10 ns. 




In this example, the end multicycle setup assignment value is two, and the end 




set_multicycle_path -from [get_clocks clk_src] -to [get_clocks clk_dst] 

-setup -end 2 


-hold -end 1 





In this example, the setup relationship is relaxed by two clock periods by moving the 

latch edge to the left two clock periods. The hold relationship is relaxed by a full 

period by moving the latch edge to the previous latch edge. 

Figure 7–23 shows the setup timing diagram. 

SRC.CLK 

DST.CLK 

-10 0 

Current 

Launch 

10 20 

0 1 2 




of two is 20 ns. 


SC 

Current 

Latch 



= 20 ns – 0 ns 

= 20 ns





Figure 7–24 shows the setup report for this example in the TimeQuest analyzer with 




SRC.CLK 

DST.CLK 

-10 0 

Current 

Launch 

10 20 

HC1 


SC 

HC2 

Current 

Latch








= 0 ns – 0 ns 

= 0 ns 


= 10 ns – 10 ns 

= 0 ns 


of two and an end multicycle hold assignment value of one is 0 ns. 



Start Multicycle Setup = 2 and Start Multicycle Hold = 0 

In this example, the start multicycle setup assignment value is two, and the start 

multicycle hold assignment value is zero. Example 7–12 shows the multicycle 




dst] -setup -start 2 

1 A start multicycle hold value is not required because the default start multicycle hold 

value is zero. 




Figure 7–27. Setup TIming Diagram 

In this example, the setup relationship is relaxed by moving the latch edge to the left 

two clock periods. Hold analysis is unchanged from the default settings. 


REG1.CLK 

REG2.CLK 

-10 0 

Current 

Launch 

2 

SC 

1 

10 20 



The most restrictive hold relationship with a start multicycle setup assignment value 



0 

Current 

Latch 



= 10 ns – �– 10 ns� 

= 20 ns




Figure 7–29. Hold TIming Diagram 



Because the multicycle hold latch and launch edges are the same as the results of hold 

analysis with the default settings, the multicycle hold analysis in this example is 

equivalent to the single-cycle hold analysis. Figure 7–29 shows the timing diagram for 

the hold checks for this example. 

REG1.CLK 

REG2.CLK 

-10 

Current 

Launch 

0 10 20 

HC1 

SC 

HC2 


Current 

Latch








= 0 ns – 10 ns 

= – 10 ns 


= 10 ns – 0 ns 

= 10 ns 


of two and a start multicycle hold assignment value of zero is 10 ns. 




In this example, the start multicycle setup assignment value is one, and the start 





dst] -hold -start 1 

1 A start multicycle setup value is not required, because the default start multicycle 

hold value is one. 





In this example, the hold relationship is relaxed by one clock period by moving the 

launch edge to the left. 


REG1.CLK 

REG2.CLK 


-10 0 

Current 

Launch 

10 20 

2 1 0 



The most restrictive setup relationship with a start multicycle setup assignment of one 

is 10 ns. 




SC 

Current 

Latch 



= 10 ns – 0 ns 

= 10 ns






REG1.CLK 

REG2.CLK 

-10 

Current 

Launch 

0 10 20 

HC1 

SC 

HC2 




of one and a start multicycle hold assignment value of one is 10 ns. 


Current 

Latch 

Equation 7–17. Hold Check 


= 10 ns – 0 ns 

= 10 ns 


= 20 ns – 10 ns 

= 10 ns








In this example, the start multicycle setup assignment value is two, and the start 





-setup -start 2 


-hold -start 1 

In this example, the setup relationship is relaxed by two clock periods by moving the 

launch edge to the left two clock periods. 


SRC.CLK 

Data 

DST.CLK 

-10 0 

2 

SC 

1 

SC 

(default) ( 

10 20 


0




Figure 7–37. Hold Timing Diagram 





= 10 ns – �– 10 ns� 

= 20 ns 







SRC.CLK 

DST.CLK 

-10 0 

Current 

Launch 

10 20 

HC1 

SC HC2 


Current 

Latch








= 0 ns – 0 ns 

= 0 ns 


= 10 ns – 10 ns 

= 0 ns 


of two and a start multicycle hold assignment value of one is 0 ns. 






Application of Multicycle Exceptions 

This section shows the following examples of applications of multicycle exceptions: 

■ “Same Frequency Clocks with Destination Clock Offset” on page 7–35 

■ “The Destination Clock Frequency is a Multiple of the Source Clock Frequency” on 

page 7–37 

■ “The Destination Clock Frequency is a Multiple of the Source Clock Frequency 

with an Offset” on page 7–40 

■ “The Source Clock Frequency is a Multiple of the Destination Clock Frequency” on 

page 7–42 

■ “The Source Clock Frequency is a Multiple of the Destination Clock Frequency 

with an Offset” on page 7–45 

Each example explains how the multicycle exceptions affect the default setup and 

hold analysis in the TimeQuest analyzer. All of the examples are between related 

clock domains. If your design contains related clocks, such as PLL clocks, and paths 

between related clock domains, you can apply multicycle constraints. 

Same Frequency Clocks with Destination Clock Offset 

In this example, the source and destination clocks have the same frequency, but the 

destination clock is offset with a positive phase shift. Both the source and destination 

clocks have a period of 10 ns. The destination clock has a positive phase shift of 2 ns 

with respect to the source clock. Figure 7–39 shows an example of a design with same 

frequency clocks and a destination clock offset. 

Figure 7–39. Same Frequency Clocks with Destination Clock Offset 

In 

clk0 

clk1 

Figure 7–40 shows the timing diagram for default setup check analysis performed by 

the TimeQuest analyzer. 


REG1.CLK 

REG2.CLK 

REG1 REG2 


SET 

D Q D Q 

Logic 

CLR CLR 

-10 0 

Launch 

1 2 

10 20 


SC 

Latch 

Out







= 2 ns – 0 ns 

= 2 ns 

The setup relationship shown in Figure 7–40 is too pessimistic and is not the setup 

relationship required for typical designs. To correct the default analysis, you must use 

an end multicycle setup exception of two. Example 7–15 shows the multicycle 

exception used to correct the default analysis in this example. 



-setup -end 2 

Figure 7–41 shows the timing diagram for the preferred setup relationship for this 

example. 

. 

Figure 7–41. Preferred Setup Relationship 

REG1.CLK 

REG2.CLK 

-10 0 

Launch 

Figure 7–42 shows the timing diagram for default hold check analysis performed by 

the TimeQuest analyzer with an end multicycle setup value of two. 

Figure 7–42. Default Hold Check 

REG1.CLK 

REG2.CLK 

1 2 

10 20 


SC 

Latch 

-10 0 

Current 

Launch 

10 20 

SC 

HC1 HC2 

Current 

Latch







= 0 ns – 2 ns 

= – 2 ns 


= 10 ns – 12 ns 

= 2 ns 

In this example, the default hold analysis returns the preferred hold requirements and 

no multicycle hold exceptions are required. 

Figure 7–43 shows the associated setup and hold analysis if the phase shift is –2 ns. In 

this example, the default hold analysis is correct for the negative phase shift of 2 ns, 

and no multicycle exceptions are required. 

Figure 7–43. Negative Phase Shift 

REG1.CLK 

REG2.CLK 

-10 0 

Current 

Launch 

10 20 

The Destination Clock Frequency is a Multiple of the Source Clock 

Frequency 

In this example, the destination clock frequency value of 5 ns is an integer multiple of 

the source clock frequency of 10 ns. The destination clock frequency can be an integer 

multiple of the source clock frequency when a PLL is used to generate both clocks 

with a phase shift applied to the destination clock. Figure 7–44 shows an example of a 

design where the destination clock frequency is a multiple of the source clock 

frequency. 

Figure 7–44. Destination Clock is Multiple of Source Clock 

In 

clk 

clk0 

clk1 


HC1 

SC 

Current 

Latch 

HC2 

REG1 REG2 


SET 

D Q D Q 

Logic 

CLR CLR 

Out






REG1.CLK 

REG2.CLK 

-10 0 

1 2 

10 20 



The setup relationship shown in Figure 7–45 demonstrates that the data does not need 

to be captured at edge one, but can be captured at edge two; therefore, you can relax 

the setup requirement. To correct the default analysis, you must shift the latch edge by 

one clock period with an end multicycle setup exception of two. Example 7–16 shows 

the multicycle exception used to correct the default analysis in this example. 


Launch 

SC 

Latch 



= 5 ns – 0 ns 

= 5 ns 



-setup -end 2




example. 

Figure 7–46. Preferred Setup Analysis 

REG1.CLK 

REG2.CLK 

-10 0 


the TimeQuest analyzer with an end multicycle setup value of two. 

Figure 7–47. Default Hold Check 

REG1.CLK 

REG2.CLK 

1 2 





= 0 ns – 5 ns 

= – 5 ns 


= 10 ns – 10 ns 

= 0 ns 

10 20 

In this example, hold check one is too restrictive. The data is launched by the edge at 

0 ns and should check against the data captured by the previous latch edge at 0 ns, 

which does not occur in hold check one. To correct the default analysis, you must use 

an end multicycle hold exception of one. 


Launch 

SC 

Latch 

-10 0 

Current 

Launch 

10 20 

HC1 

SC 

HC2 

Current 

Latch



The Destination Clock Frequency is a Multiple of the Source Clock 

Frequency with an Offset 

This example is a combination of the previous two examples. The destination clock 

frequency is an integer multiple of the source clock frequency and the destination 

clock has a positive phase shift. The destination clock frequency is 5 ns and the source 

clock frequency is 10 ns. The destination clock also has a positive offset of 2 ns with 

respect to the source clock. The destination clock frequency can be an integer multiple 

of the source clock frequency with an offset when a PLL is used to generate both 

clocks with a phase shift applied to the destination clock. Figure 7–48 shows an 

example of a design in which the destination clock frequency is a multiple of the 

source clock frequency with an offset. 

Figure 7–48. Destination Clock is Multiple of Source Clock with Offset 






. 


In 

clk 

REG1.CLK 

REG2.CLK 

clk0 

clk1 

-10 0 

REG1 REG2 


SET 

D Q D Q 

Logic 

CLR CLR 

1 2 3 

10 20 


= 2 ns – 0 ns 

= 2 ns 

The setup relationship shown in Figure 7–49 demonstrates that the data does not need 

to be captured at edge one, but can be captured at edge two; therefore, you can relax 

the setup requirement. To correct the default analysis, you must shift the latch edge by 

one clock period with an end multicycle setup exception of three. 


Launch 

SC 

Latch 

Out



Example 7–17 shows the multicycle exception used to correct the default analysis in 

this example. 

Example 7–17. Multicycle Exceptions 


-setup -end 3 


example. 

Figure 7–50. Preferred Setup Analysis 

REG1.CLK 

REG2.CLK 

-10 0 


the TimeQuest analyzer with an end multicycle setup value of three. 


REG1.CLK 

REG2.CLK 


Launch 

SC 

1 2 3 

SC 

10 20 

Latch 

-10 0 

Current 

Launch 

10 20 

HC1 

HC2 

Current 

Latch







= 0 ns – 5 ns 

= – 5 ns 


= 10 ns – 10 ns 

= 0 ns 

In this example, hold check one is too restrictive. The data is launched by the edge at 

0 ns and should check against the data captured by the previous latch edge at 2 ns, 

which does not occur in hold check one. To correct the default analysis, you must use 

an end multicycle hold exception of one. 

The Source Clock Frequency is a Multiple of the Destination Clock 

Frequency 

In this example, the source clock frequency value of 5 ns is an integer multiple of the 

destination clock frequency of 10 ns. The source clock frequency can be an integer 

multiple of the destination clock frequency when a PLL is used to generate both 

clocks and different multiplication and division factors are used. Figure 7–52 shows 

an example of a design where the source clock frequency is a multiple of the 

destination clock frequency. 

Figure 7–52. Source Clock Frequency is Multiple of Destination Clock Frequency 

In 

clk 

clk0 

clk1 

REG1 REG2 


SET 

D Q D Q 

Logic 

CLR CLR 


Out





Figure 7–53. Default Setup Check Analysis 

REG1.CLK 

REG2.CLK 




-10 0 


= 10 ns – 5 ns 

= 5 ns 

The setup relationship shown in Figure 7–53 demonstrates that the data launched at 

edge one does not need to be captured, and the data launched at edge two must be 

captured; therefore, you can relax the setup requirement. To correct the default 

analysis, you must shift the launch edge by one clock period with a start multicycle 

setup exception of two. 


this example. 


2 1 




Launch 

SC 

10 20 

Latch




example. 

Figure 7–54. Preferred Setup Check Analysis 


the TimeQuest analyzer with a start multicycle setup value of two. 




. 

REG1.CLK 

REG2.CLK 

REG1.CLK 

REG2.CLK 

Equation 7–27. Hold Check 

-10 0 

2 1 


= 0 ns – 0 ns 

= 0 ns 


= 5 ns – 10 ns 

= – 5 ns 

In this example, hold check two is too restrictive. The data is launched next by the 

edge at 10 ns and should check against the data captured by the current latch edge at 

10 ns, which does not occur in hold check two. To correct the default analysis, you 

must use a start multicycle hold exception of one. 


Launch 

SC 

HC1 SC HC2 

10 20 

Latch 

-10 0 

Current 

Launch 

10 20 

Current 

Latch



The Source Clock Frequency is a Multiple of the Destination Clock 

Frequency with an Offset 

In this example, the source clock frequency is an integer multiple of the destination 

clock frequency and the destination clock has a positive phase offset. The source clock 

frequency is 5 ns and destination clock frequency is 10 ns. The destination clock also 

has a positive offset of 2 ns with respect to the source clock. The source clock 

frequency can be an integer multiple of the destination clock frequency with an offset 

when a PLL is used to generate both clocks, different multiplication and division 

factors are used, and a phase shift applied to the destination clock. Figure 7–56 shows 

an example of a design where the source clock frequency is a multiple of the 

destination clock frequency with an offset. 

Figure 7–56. Source Clock Frequency is Multiple of Destination Clock Frequency with Offset 



Figure 7–57. Setup Timing Diagram 



. 

Equation 7–28. setup Check 

In 

clk 

REG1.CLK 

REG2.CLK 

clk0 

clk1 

REG1 REG2 


SET 

D Q D Q 

Logic 

-10 0 

CLR CLR 

3 2 1 


= 12 ns – 10 ns 

= 2 ns 

The setup relationship shown in Figure 7–57 demonstrates that the data is not 

launched at edge one, and the data that is launched at edge three must be captured; 

therefore, you can relax the setup requirement. To correct the default analysis, you 

must shift the launch edge by two clock periods with a start multicycle setup 

exception of three. 


C 

Out 

10 20 

Launch 

Latch




this example. 





example. 

Figure 7–58. Preferred Setup Check Analysis 

REG1.CLK 

REG2.CLK 

-10 0 


the TimeQuest analyzer with a start multicycle setup value of three. 

Figure 7–59. Default Hold Check Analysis 

REG1.CLK 

REG2.CLK 

3 2 1 

10 20 


Launch 

SC 

Latch 

-10 0 

Current 

Launch 

10 20 

HC1 

SC 

HC2 

Current 

Latch


Document Revision History 





= 0 ns – 2 ns 

= – 2 ns 

In this example, hold check two is too restrictive. The data is launched next by the 

edge at 10 ns and should check against the data captured by the current latch edge at 

12 ns, which does not occur in hold check two. To correct the default analysis, you 

must use a start multicycle hold exception of one. 


Table 7–2. Document Revision History 


= 5 ns – 12 ns 

= – 7 ns 

Table 7–2 shows the revision history for this chapter. 

Date Version Changes 

■ Changed to new document template. 

December 2010 10.1.0 

■ Edited document and linked to other resources. 

■ Added information that previously appeared in Application Note 481: Applying Multicycle 

Exceptions in the TimeQuest Timing Analyzer. 

July 2010 10.0.0 Minor editorial changes to document. No updates to technical content. 

November 2009 9.1.0 

■ 

■ 

Added example to “Derived Clocks” on page 7–3. 

Updated “Base Clocks” on page 7–2. 

March 2009 9.0.0 Initial release. 

f For previous versions of the Quartus II Handbook, refer to the Quartus II Handbook 

Archive. 

f Take an online survey to provide feedback about this handbook chapter.

7. Best Practices for the Quartus II TimeQuest Timing Analyzer

Create successful ePaper yourself

Delete template?

Save as template?