Timing Analysis
Section II. Timing Analysis
As designs become more complex, advanced timing analysis capability requirements
grow. Static timing analysis is a method of analyzing, debugging, and validating the
timing performance of a design. The Quartus® II software provides the features
necessary to perform advanced timing analysis for today’s system-on-aprogrammable-chip (SOPC) designs.
Synopsys PrimeTime is an industry standard sign-off tool, used to perform static
timing analysis on most ASIC designs. The Quartus II software provides a path to
enable you to run PrimeTime on your Quartus II software designs, and export a
netlist, timing constraints, and libraries to the PrimeTime environment.
This section explains the basic principles of static timing analysis, the advanced
features supported by the Quartus II Timing Analyzer, and how you can use
PrimeTime to analyze your Quartus II projects.
This section includes the following chapters:
■
Chapter 6, The Quartus II TimeQuest Timing Analyzer
This chapter describes the Quartus II TimeQuest Timing Analyzer, which is a
powerful ASIC-style timing analysis tool that validates the timing performance of
all logic in your design using an industry-standard constraint, analysis, and
reporting methodology.
■
Chapter 7, Best Practices for the Quartus II TimeQuest Timing Analyzer
This chapter provides the steps to fully constrain an FPGA design with the
Quartus II TimeQuest Timing Analyzer.
■
Chapter 8, Switching to the Quartus II TimeQuest Timing Analyzer
This chapter describes the benefits of switching to the Quartus II TimeQuest
Timing Analyzer, the differences between the Quartus II TimeQuest and
Quartus II Classic Timing Analyzers, and the process you should follow to switch
a design from using the Quartus II Classic Timing Analyzer to the Quartus II
TimeQuest Timing Analyzer.
■
Chapter 9, Synopsys PrimeTime Support
This chapter describes the PrimeTime software that uses data from either best-case
or worst-case Quartus II timing models to measure timing. The PrimeTime
software is controlled using a Tcl script generated by the Quartus II software that
you can customize to direct the PrimeTime software to produce violation and
slack reports.
May 2011
Altera Corporation
Quartus II Handbook Version 11.0 Volume 3: Verification
II–2
Quartus II Handbook Version 11.0 Volume 3: Verification
Section II: Timing Analysis
May 2011 Altera Corporation
6. The Quartus II TimeQuest
Timing Analyzer
May 2011
QII53018-11.0.0
QII53018-11.0.0
The Quartus® II TimeQuest Timing Analyzer is a powerful ASIC-style timing analysis
tool that validates the timing performance of all logic in your design using an
industry-standard constraint, analysis, and reporting methodology. Use the
TimeQuest analyzer GUI or command-line interface to constrain, analyze, and report
results for all timing paths in your design.
This chapter contains the following sections:
■
“Understanding Timing Analysis with the TimeQuest Analyzer” on page 6–1
■
“Getting Started with the TimeQuest Analyzer” on page 6–16
■
“Constraining and Analyzing with Tcl Commands” on page 6–22
■
“Creating Clocks and Clock Constraints” on page 6–26
■
“Creating I/O Constraints” on page 6–36
■
“Creating Delay and Skew Constraints” on page 6–37
■
“Creating Timing Exceptions” on page 6–38
■
“Timing Reports” on page 6–40
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 the TimeQuest Timing Analyzer, refer to the Altera
Training page of the Altera website.
Understanding Timing Analysis with the TimeQuest Analyzer
A comprehensive static timing analysis involves analysis of register-to-register, I/O,
and asynchronous reset paths. The TimeQuest analyzer uses data required times, data
arrival times, and clock arrival times to verify circuit performance and detect possible
timing violations. The TimeQuest analyzer determines the timing relationships that
must be met for the design to correctly function, and checks arrival times against
required times to verify timing.
© 2011 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
May 2011
Subscribe
6–2
Chapter 6: The Quartus II TimeQuest Timing Analyzer
Understanding Timing Analysis with the TimeQuest Analyzer
Table 6–1 describes TimeQuest analyzer terminology.
Table 6–1. TimeQuest Analyzer Terminology
Term
Definition
nodes
Most basic timing netlist unit. Used to represent ports, pins, and registers.
keepers
Ports or registers. (1)
cells
Look-up tables (LUT), registers, digital signal processing (DSP) blocks,
memory blocks, input/output elements, and so on. (2)
pins
Inputs or outputs of cells.
nets
Connections between pins.
ports
Top-level module inputs or outputs; for example, device pins.
clocks
Abstract objects outside of the design.
Notes to Table 6–1:
(1) Pins can indirectly refer to keepers. For example, a pin refers to a keeper when the value in the -from field of a
constraint is a clock pin to a dedicated memory block. In this case, the clock pin refers to a collection of registers.
(2) For Stratix® devices, the LUTs and registers are contained in logic elements (LE) and modeled as cells.
Timing Netlists and Timing Paths
The TimeQuest analyzer requires a timing netlist to perform timing analysis on any
design. After you generate a timing netlist, the TimeQuest analyzer uses the data to
help determine the different design elements in your design and how to analyze
timing.
The Timing Netlist
Figure 6–1 shows a sample design for which the TimeQuest analyzer generates a
timing netlist equivalent.
Figure 6–1. Sample Design
data1
reg1
and_inst
reg3
data2
reg2
clk
Quartus II Handbook Version 11.0 Volume 3: Verification
May 2011 Altera Corporation
Chapter 6: The Quartus II TimeQuest Timing Analyzer
Understanding Timing Analysis with the TimeQuest Analyzer
6–3
Figure 6–2 shows the timing netlist for the sample design in Figure 6–1, including
how different design elements are divided into cells, pins, nets, and ports.
Figure 6–2. The TimeQuest Analyzer Timing Netlist
Cells
Cell
data1
combout
datain
reg1
Cell
regout
clk
and_inst
datac
combout
reg3
data_out
Pin
data2
datain
datad
reg2
regout
Port
Pin
clk
clk~clkctrl
inclk0
outclk
Timing Paths
Timing paths connect two design nodes, such as the output of a register to the input of
another register. Timing paths play a significant role in timing analysis.
Understanding the types of timing paths is important to timing closure and
optimization. The TimeQuest analyzer uses the following commonly analyzed paths:
■
Edge paths—connections from ports-to-pins, from pins-to-pins, and from
pins-to-ports.
■
Clock paths—connections from device ports or internally generated clock pins to
the clock pin of a register.
■
Data paths—connections from a port or the data output pin of a sequential
element to a port or the data input pin of another sequential element.
■
Asynchronous paths—connections from a port or sequential element to the
asynchronous reset or asynchronous clear pin of another sequential element.
Figure 6–3 shows path types commonly analyzed by the TimeQuest analyzer.
Figure 6–3. Path Types
D
Q
Clock Path
clk
D
Q
Data Path
CLRN
CLRN
Asynchronous Clear Path
rst
May 2011
Altera Corporation
Quartus II Handbook Version 11.0 Volume 3: Verification
6–4
Chapter 6: The Quartus II TimeQuest Timing Analyzer
Understanding Timing Analysis with the TimeQuest Analyzer
In addition to identifying various paths in a design, the TimeQuest analyzer analyzes
clock characteristics to compute the worst-case requirement between any two
registers in a single register-to-register path. You should constrain all clocks in your
design before analyzing clock characteristics.
In addition to analyzing paths, the TimeQuest analyzer determines clock relationships
for all register-to-register transfers in your design. Figure 6–4 shows a single-cycle
system that uses consecutive clock edges to transfer and capture data for a
register-to-register path, and the corresponding timing diagram showing the launch
and latch edges. The launch edge is an active clock edge that sends data out of a
sequential element, acting as a source for the data transfer. A latch edge is the active
clock edge that captures data at the data port of a sequential element, acting as a
destination for the data transfer. In this example, the launch edge sends the data out of
register reg1 at 0 ns, and the register reg2 latch edge captures the data at 5 ns.
1
The TimeQuest analyzer validates clock setup and hold requirements relative to the
launch and latch edges.
Figure 6–4. Launch Edge and Latch Edge
D
Q
D
reg1
Q
reg2
clk
0 ns
5 ns
Launch Edge at
Source Register reg1
10 ns
15 ns
Latch Edge at
Destination Register reg2
Data and Clock Arrival Times
After the TimeQuest analyzer identifies the path type, it can report data and clock
arrival times at register pins. The TimeQuest analyzer calculates data arrival time by
adding the delay from the clock source to the clock pin of the source register, the
micro clock-to-output delay (tCO) of the source register, and the delay from the
source register’s Q pin to the destination register’s D pin, where the tCO is the
intrinsic clock-to-out time for an internal register in the FPGA.
Quartus II Handbook Version 11.0 Volume 3: Verification
May 2011 Altera Corporation
Chapter 6: The Quartus II TimeQuest Timing Analyzer
Understanding Timing Analysis with the TimeQuest Analyzer
6–5
The TimeQuest analyzer calculates clock arrival time by adding the sum of all delays
between the clock port and the clock pin of the destination register, including any
clock port buffer delays. Figure 6–5 shows a data arrival path and a clock arrival path.
The TimeQuest analyzer calculates the data required time by accounting for the clock
arrival time and micro setup time (tSU) of the destination register, where the tSU is
the intrinsic setup time of an internal register in the FPGA.
Figure 6–5. Data Arrival and Clock Arrival Paths
D
Q
D
Q
Data Arrival
Clock Arrival
Clock Setup Check
To perform a clock setup check, the TimeQuest analyzer determines a setup
relationship by analyzing each launch and latch edge for each register-to-register
path. For each latch edge at the destination register, the TimeQuest analyzer uses the
closest previous clock edge at the source register as the launch edge. Figure 6–6 shows
two setup relationships, setup A and setup B. For the latch edge at 10 ns, the closest
clock that acts as a launch edge is at 3 ns and is labeled setup A. For the latch edge at
20 ns, the closest clock that acts as a launch edge is 19 ns and is labeled setup B.
Figure 6–6. Setup Check
Source Clock
Setup A
Setup B
Destination Clock
0 ns
8 ns
16 ns
24 ns
32 ns
The TimeQuest analyzer reports the result of clock setup checks as slack values. Slack
is the margin by which a timing requirement is met or not met. Positive slack indicates
the margin by which a requirement is met; negative slack indicates the margin by
which a requirement is not met. Equation 6–1 shows the TimeQuest analyzer clock
setup slack time calculation for internal register-to-register paths.
Equation 6–1. Clock Setup Slack for Internal Register-to-Register paths
Clock Setup Slack = Data Required Time – Data Arrival Time
Data Arrival Time = Launch Edge + Clock Network Delay to Source Register +
t CO + Register-to-Register Delay
Data Required Time = Latch Edge + Clock Network Delay to Destination Register –
t SU – Setup Uncertainty
May 2011
Altera Corporation
Quartus II Handbook Version 11.0 Volume 3: Verification
6–6
Chapter 6: The Quartus II TimeQuest Timing Analyzer
Understanding Timing Analysis with the TimeQuest Analyzer
Equation 6–2 shows the TimeQuest analyzer clock setup slack time calculation if the
data path is from an input port to an internal register.
Equation 6–2. Clock Setup Slack from Input Port to Internal Register
Clock Setup Slack = Data Required Time – Data Arrival Time
Data Required Time = Latch Edge + Clock Network Delay to Destination Register – t SU
Data Arrival Time = Launch Edge + Clock Network Delay +
Input Maximum Delay + Pin-to-Register Delay
Equation 6–3 shows the TimeQuest analyzer clock setup slack time calculation if the
data path is an internal register to an output port.
Equation 6–3. Clock Setup Slack from Internal Register to Output Port
Clock Setup Slack = Data Required Time – Data Arrival Time
Data Required Time = Latch Edge + Clock Network Delay to Destination Register –
Output Maximum Delay
Data Arrival Time = Launch Edge + Clock Network Delay to Source Register +
t CO + Register-to-Pin Delay
Clock Hold Check
To perform a clock hold check, the TimeQuest analyzer determines a hold relationship
for each possible setup relationship that exists for all source and destination register
pairs. The TimeQuest analyzer checks all adjacent clock edges from all setup
relationships to determine the hold relationships. The TimeQuest analyzer performs
two hold checks for each setup relationship. 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. From the possible hold relationships, the
TimeQuest analyzer selects the hold relationship that is the most restrictive. The most
restrictive hold relationship is the hold relationship with the smallest difference
between the latch and launch edges and determines the minimum allowable delay for
the register-to-register path. Figure 6–7 shows two setup relationships, setup A and
setup B, and their respective hold checks. In this example, the TimeQuest analyzer
selects hold check A2 as the most restrictive hold relationship.
Figure 6–7. Hold Checks
Source Clock
Hold
Check A1
Setup A
Hold Setup B
Hold
Check B1
Check A2
Hold
Check B2
Destination Clock
0 ns
Quartus II Handbook Version 11.0 Volume 3: Verification
8 ns
16 ns
24 ns
32 ns
May 2011 Altera Corporation
Chapter 6: The Quartus II TimeQuest Timing Analyzer
Understanding Timing Analysis with the TimeQuest Analyzer
6–7
Equation 6–4 shows the TimeQuest analyzer clock hold slack time calculation.
Equation 6–4. Clock Hold Slack for Internal Register-to-Register Paths
Clock Hold Slack = Data Arrival Time – Data Required Time
Data Arrival Time = Launch Edge + Clock Network Delay to Source Register + t CO +
Register-to-Register Delay
Data Required Time = Latch Edge + Clock Network Delay to Destination Register +
t H + Hold Uncertainty
Equation 6–5 shows the TimeQuest analyzer hold slack time calculation if the data
path is from an input port to an internal register.
Equation 6–5. Clock Hold Slack from Input Port to Internal Register
Clock Hold Slack = Data Arrival Time – Data Required Time
Data Arrival Time = Launch Edge + Clock Network Delay +
Input Minimum Delay of Pin + Pin-to-Register Delay
Data Required Time = Latch Edge + Clock Network Delay to Destination Register + t H
Equation 6–6 shows the TimeQuest analyzer hold slack time calculation if the data
path is from an internal register to an output port.
Equation 6–6. Clock Hold Slack from Internal Register to Output Port
Clock Hold Slack = Data Arrival Time – Data Required Time
Data Arrival Time = Latch Edge + Clock Network Delay to Source Register + t CO +
Register-to-Pin Delay
Data Required Time = Latch Edge + Clock Network Delay – Output Minimum Delay of Pin
Recovery and Removal Time
Recovery time is the minimum length of time for the deassertion of an asynchronous
control signal; for example, signals such as clear and preset must be stable before the
next active clock edge. The recovery slack calculation is similar to the clock setup
slack calculation, but it applies to asynchronous control signals. Equation 6–7 shows
the TimeQuest analyzer recovery slack time calculation if the asynchronous control
signal is registered.
Equation 6–7. Recovery Slack if Asynchronous Control Signal Registered
Recovery Slack Time = Data Required Time – Data Arrival Time
Data Arrival Time = Launch Edge + Clock Network Delay to Source Register +
t CO + Register-to-Register Delay
Data Required Time = Latch Edge + Clock Network Delay to Destination Register – t SU
May 2011
Altera Corporation
Quartus II Handbook Version 11.0 Volume 3: Verification
6–8
Chapter 6: The Quartus II TimeQuest Timing Analyzer
Understanding Timing Analysis with the TimeQuest Analyzer
Equation 6–8 shows the TimeQuest analyzer recovery slack time calculation if the
asynchronous control signal is not registered.
Equation 6–8. Recovery Slack if Asynchronous Control Signal not Registered
Recovery Slack Time = Data Required Time – Data Arrival Time
Data Arrival Time = Launch Edge + Clock Network Delay + Input Maximum Delay +
Port-to-Register Delay
Data Required Time = Latch Edge + Clock Network Delay to Destination Register Delay – t SU
1
If the asynchronous reset signal is from a device I/O port, you must assign the Input
Maximum Delay timing assignment to the asynchronous reset port for the TimeQuest
analyzer to perform recovery analysis on the path.
Removal time is the minimum length of time the deassertion of an asynchronous
control signal must be stable after the active clock edge. The TimeQuest analyzer
removal slack calculation is similar to the clock hold slack calculation, but it applies
asynchronous control signals. Equation 6–9 shows the TimeQuest analyzer removal
slack time calculation if the asynchronous control signal is registered.
Equation 6–9. Removal Slack if Asynchronous Control Signal Registered
Removal Slack Time = Data Arrival Time – Data Required Time
Data Arrival Time = Launch Edge + Clock Network Delay to Source Register +
t CO of Source Register + Register-to-Register Delay
Data Required Time = Latch Edge + Clock Network Delay to Destination Register + t H
Equation 6–10 shows the TimeQuest analyzer removal slack time calculation if the
asynchronous control signal is not registered.
Equation 6–10. Removal Slack if Asynchronous Control Signal not Registered
Removal Slack Time = Data Arrival Time – Data Required Time
Data Arrival Time = Launch Edge + Clock Network Delay + Input Minimum Delay of Pin +
Minimum Pin-to-Register Delay
Data Required Time = Latch Edge + Clock Network Delay to Destination Register + t H
1
If the asynchronous reset signal is from a device pin, you must assign the Input
Minimum Delay timing assignment to the asynchronous reset pin for the TimeQuest
analyzer to perform removal analysis on the path.
Quartus II Handbook Version 11.0 Volume 3: Verification
May 2011 Altera Corporation
Chapter 6: The Quartus II TimeQuest Timing Analyzer
Understanding Timing Analysis with the TimeQuest Analyzer
6–9
Multicycle Paths
Multicycle paths are data paths that require more than one clock cycle to latch data at
the destination register. For example, a register may be required to capture data on
every second or third rising clock edge. Figure 6–8 shows an example of a multicycle
path between the input registers of a multiplier and an output register where the
destination latches data on every other clock edge.
Figure 6–8. Multicycle Path
D
Q
ENA
D
D
Q
ENA
Q
ENA
2 Cycles
Figure 6–9 shows a register-to-register path used for the default setup and hold
relationship, the respective timing diagrams for the source and destination clocks, and
the default setup and hold relationships, when the source clock, src_clk, has a period
of 10 ns and the destination clock, dst_clk, has a period of 5 ns. The default setup
relationship is 5 ns; the default hold relationship is 0 ns.
Figure 6–9. Register-to-Register Path and Default Setup and Hold Timing Diagram
reg
data_in
D
reg
Q
D
Q
data_out
src_clk
dst_clk
setup
hold
0
10
20
30
To accommodate the system requirements you can modify the default setup and hold
relationships with the set_multicycle_path command.
May 2011
Altera Corporation
Quartus II Handbook Version 11.0 Volume 3: Verification
6–10
Chapter 6: The Quartus II TimeQuest Timing Analyzer
Understanding Timing Analysis with the TimeQuest Analyzer
Figure 6–10 shows the actual setup relationship after the set_multicycle_path
command. The exception has a multicycle setup assignment of two to use the second
occurring latch edge; in this example, to 10 ns from the default value of 5 ns.
Figure 6–10. Modified Setup Diagram
new setup
default setup
0
10
20
30
For more information about creating exceptions with multicycle paths, refer to
“Creating Timing Exceptions” on page 6–38.
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.
Metastability
Metastability problems can occur when a signal is transferred between circuitry in
unrelated or asynchronous clock domains because the designer cannot guarantee that
the signal will meet setup and hold time requirements. To minimize the failures due to
metastability, circuit designers typically use a sequence of registers, also known as a
synchronization register chain, or synchronizer, in the destination clock domain to
resynchronize the data signals to the new clock domain.
The mean time between failures (MTBF) is an estimate of the average time between
instances of failure due to metastability.
The TimeQuest analyzer analyzes the potential for metastability in your design and
can calculate the MTBF for synchronization register chains. The MTBF of the entire
design is then estimated based on the synchronization chains it contains.
In addition to reporting synchronization register chains found in the design, the
Quartus II software also protects these registers from optimizations that might
negatively impact MTBF, such as register duplication and logic retiming. The
Quartus II software can also optimize the MTBF of your design if the MTBF is too low.
f For more information about metastability, its effects in FPGAs, and how MTBF is
calculated, refer to the Understanding Metastability in FPGAs white paper. For more
information about metastability analysis, reporting, and optimization features in the
Quartus II software, refer to the Managing Metastability with the Quartus II Software
chapter in volume 1 of the Quartus II Handbook.
Quartus II Handbook Version 11.0 Volume 3: Verification
May 2011 Altera Corporation
Chapter 6: The Quartus II TimeQuest Timing Analyzer
Understanding Timing Analysis with the TimeQuest Analyzer
6–11
Common Clock Path Pessimism Removal
Common clock path pessimism removal accounts for the minimum and maximum
delay variation associated with common clock paths during static timing analysis by
adding the difference between the maximum and minimum delay value of the
common clock path to the appropriate slack equation.
Minimum and maximum delay variation can occur when two different delay values
are used for the same clock path. For example, in a simple setup analysis, the
maximum clock path delay to the source register is used to determine the data arrival
time. The minimum clock path delay to the destination register is used to determine
the data required time. However, if the clock path to the source register and to the
destination register share a common clock path, both the maximum delay and the
minimum delay are used to model the common clock path during timing analysis.
The use of both the minimum delay and maximum delay results in an overly
pessimistic analysis since two different delay values, the maximum and minimum
delays, cannot be used to model the same clock path.
Figure 6–11 shows a typical register-to-register path with the maximum and
minimum delay values shown.
Figure 6–11. Common Clock Path
B
D
2.2 ns
2.0 ns
Q
reg1
A
clk
3.2 ns
3.0 ns
5.5 ns
5.0 ns
C
2.2 ns
2.0 ns
D
Q
reg2
Segment A is the common clock path between reg1 and reg2. The minimum delay is
5.0 ns; the maximum delay is 5.5 ns. The difference between the maximum and
minimum delay value equals the common clock path pessimism removal value; in
this case, the common clock path pessimism is 0.5 ns. The TimeQuest analyzer adds
the common clock path pessimism removal value to the appropriate slack equation to
determine overall slack. Therefore, if the setup slack for the register-to-register path in
Figure 6–11 equals 0.7 ns without common clock path pessimism removal, the slack
would be 1.2 ns with common clock path pessimism removal.
You can also use common clock path pessimism removal to determine the minimum
pulse width of a register. A clock signal must meet a register’s minimum pulse width
requirement to be recognized by the register. A minimum high time defines the
minimum pulse width for a positive-edge triggered register. A minimum low time
defines the minimum pulse width for a negative-edge triggered register.
May 2011
Altera Corporation
Quartus II Handbook Version 11.0 Volume 3: Verification
6–12
Chapter 6: The Quartus II TimeQuest Timing Analyzer
Understanding Timing Analysis with the TimeQuest Analyzer
Clock pulses that violate the minimum pulse width of a register prevent data from
being latched at the data pin of the register. To calculate the slack of the minimum
pulse width, the TimeQuest analyzer subtracts the required minimum pulse width
time from the actual minimum pulse width time. The TimeQuest analyzer determines
the actual minimum pulse width time by the clock requirement you specified for the
clock that feeds the clock port of the register. The TimeQuest analyzer determines the
required minimum pulse width time by the maximum rise, minimum rise, maximum
fall, and minimum fall times. Figure 6–12 shows a diagram of the required minimum
pulse width time for both the high pulse and low pulse.
Figure 6–12. Required Minimum Pulse Width
Minimum and
Maximum Rise
Rise Arrival Times
Minimum and
Maximum
Fall Arrival Times
High Pulse
Width
0.8
Low Pulse
Width
0.5
0.9
0.7
0.8
0.5
With common clock path pessimism, the minimum pulse width slack can be increased
by the smallest value of either the maximum rise time minus the minimum rise time,
or the maximum fall time minus the minimum fall time. For Figure 6–12, the slack
value can be increased by 0.2 ns, which is the smallest value between 0.3 ns (0.8
ns – 0.5 ns) and 0.2 ns (0.9 ns – 0.7 ns).
h For more information, refer to TimeQuest Timing Analyzer Page in Quartus II Help.
Clock-As-Data Analysis
The majority of FPGA designs contain simple connections between any two nodes
known as either a data path or a clock path. A data path is a connection between the
output of a synchronous element to the input of another synchronous element. A
clock is a connection to the clock pin of a synchronous element. However, for more
complex FPGA designs, such as designs that use source-synchronous interfaces, this
simplified view is no longer sufficient.
Quartus II Handbook Version 11.0 Volume 3: Verification
May 2011 Altera Corporation
Chapter 6: The Quartus II TimeQuest Timing Analyzer
Understanding Timing Analysis with the TimeQuest Analyzer
6–13
The connection between the input clock port and output clock port can be treated
either as a clock path or a data path. Figure 6–13 shows a design where the path from
port clk_in to port clk_out is both a clock and a data path. The clock path is from the
port clk_in to the register reg_data clock pin. The data path is from port clk_in to
the port clk_out.
Figure 6–13. Simplified Source Synchronous Output
D
Q
reg_data
clk_in
clk_out
With clock-as-data analysis, the TimeQuest analyzer provides a more accurate
analysis of the path based on user constraints. For the clock path analysis, any phase
shift associated with the phase-locked loop (PLL) is taken into consideration. For the
data path analysis, any phase shift associated with the PLL is taken into consideration
rather than ignored.
The clock-as-data analysis also applies to internally generated clock dividers.
Figure 6–14 shows an internally generated clock divider. In this figure, the inverter
feedback path is analyzed during timing analysis. The output of the divider register is
used to determine the launch time and the clock port of the register is used to
determine the latch time. A source-synchronous interface contains a clock signal that
travels in parallel with data signals. The clock and data pair originates or terminates
at the same device.
Figure 6–14. Clock Divider
D
D
Q
Q
Launch Clock (1/2 T)
Data Arrival Time
Latch Clock (T)
May 2011
Altera Corporation
Quartus II Handbook Version 11.0 Volume 3: Verification
6–14
Chapter 6: The Quartus II TimeQuest Timing Analyzer
Understanding Timing Analysis with the TimeQuest Analyzer
Multicorner Analysis
The TimeQuest analyzer performs multicorner timing analysis to verify your design
under a variety of operating conditions—such as voltage, process, and temperature—
while performing static timing analysis.
To change the operating conditions or speed grade of the device used for timing
analysis, use the set_operating_conditions command.
Table 6–2 describes the options for the set_operating_conditions command.
Table 6–2. set_operating_conditions Command Options
Option
Description
-model <fast|slow>
Specifies the timing model.
-speed <speed grade>
Specifies the device speed grade.
-temperature <value in ºC>
Specifies the operating temperature.
-voltage <value in mV>
Specifies the operating voltage.
-force_dat
Forces a re-annotation of the timing delays for the design.
-grade <i|c>
Allows the specification of industrial (i) or commercial (c) speed grades.
For timing sign-off, the value of the -grade option should match the
speed grade of the targeted device.
<operating condition Tcl object>
Specifies the operating condition Tcl object that specifies the operating
conditions.
If you specify an operating condition Tcl object, the -model, speed, -temperature, and
-voltage options are optional. If you do not specify an operating condition Tcl object,
the -model option is required; the -speed, -temperature, and -voltage options are
optional.
Table 6–3 shows examples of the available operating conditions that can be set for
each device family.
Table 6–3. Example Device Family Operating Conditions
Available Conditions
Device Family
Stratix III
Speed
Grade
4
Cyclone III
®
7
Stratix II
Cyclone II
4
6
Model
Voltage
(mV)
Temp
(ºC)
Slow
1100
85
4_slow_1100mv_85c
Slow
1100
0
4_slow_1100mv_0c
Fast
1100
0
MIN_fast_1100mv_0c
Slow
1200
85
7_slow_1200mv_85c
Slow
1200
0
7_slow_1200mv_0c
Fast
1200
0
MIN_fast_1200mv_0c
—
—
—
—
Slow
Fast
Slow
Fast
Quartus II Handbook Version 11.0 Volume 3: Verification
Operating Condition Tcl Objects
4_slow
MIN_fast
6_slow
MIN_fast
May 2011 Altera Corporation
Chapter 6: The Quartus II TimeQuest Timing Analyzer
Understanding Timing Analysis with the TimeQuest Analyzer
1
6–15
To obtain a list of available operating conditions for the target device, use the
get_available_operating_conditions -all command.
h For more information about the set_operating_conditions and
get_available_operating_conditions commands—including full syntax
information, options, and example usage—refer to set_operating_conditions and
get_available_operating_conditions in Quartus II Help.
To ensure that no violations occur under various conditions during the device
operation, perform static timing analysis under all available operating conditions.
Table 6–4 shows the operating conditions for the slow and fast timing models for
device families that support only slow and fast operating conditions.
Table 6–4. Operating Conditions for Slow and Fast Models
Model
Speed Grade
Voltage
Temperature
Slow
Slowest speed grade in device density
Vcc minimum supply (1)
Maximum TJ (1)
Fast
Fastest speed grade in device density
Vcc maximum supply (1)
Minimum TJ (1)
Note toTable 6–4:
(1) Refer to the DC & Switching Characteristics chapter of the applicable device Handbook for Vcc and TJ. values
Example 6–1 shows how to set the operating conditions for a Stratix III design to the
slow timing model, with a voltage of 1100 mV, and temperature of 85° C.
Example 6–1. Setting Operating Conditions with Individual Values
set_operating_conditions -model slow -temperature 85 -voltage 1100
Example 6–2 shows how to set the operating conditions in Example 6–1 with a Tcl
object.
Example 6–2. Setting Operating Conditions with a Tcl Object
set_operating_conditions 4_slow_1100mv_85c
May 2011
Altera Corporation
Quartus II Handbook Version 11.0 Volume 3: Verification
6–16
Chapter 6: The Quartus II TimeQuest Timing Analyzer
Getting Started with the TimeQuest Analyzer
Example 6–3 shows how to use the set_operating_conditions command to generate
different reports for various operating conditions.
Example 6–3. Script Excerpt for Analysis of Various Operating Conditions
#Specify initial operating conditions
set_operating_conditions -model slow -speed 3 -grade c -temperature 85
-voltage 1100
#Update the timing netlist with the initial conditions
update_timing_netlist
#Perform reporting
#Change initial operating conditions. Use a temperature of 0C
set_operating_conditions -model slow -speed 3 -grade c -temperature 0
-voltage 1100
#Update the timing netlist with the new operating condition
update_timing_netlist
#Perform reporting
#Change initial operating conditions. Use a temperature of 0C and a
model of fast
set_operating_conditions -model fast -speed 3 -grade c -temperature 0
-voltage 1100
#Update the timing netlist with the new operating condition
update_timing_netlist
#Perform reporting
Getting Started with the TimeQuest Analyzer
This section provides a brief overview of the design steps necessary to set up your
project for timing and analysis and the steps to perform to constrain your design with
the TimeQuest analyzer.
Running the TimeQuest Analyzer
You can run the TimeQuest analyzer in the following ways:
■
Directly from the Quartus II software GUI
■
As a stand-alone GUI application
■
At a system command prompt
For more information about prerequisite steps to perform before opening the
TimeQuest analyzer, refer to “Recommended Flows” on page 6–19.
To run the TimeQuest analyzer from the Quartus II software, on the Tools menu, click
TimeQuest Timing Analyzer.
To run the TimeQuest analyzer as a stand-alone application, type the following
command at the command prompt:
quartus_staw r
Quartus II Handbook Version 11.0 Volume 3: Verification
May 2011 Altera Corporation
Chapter 6: The Quartus II TimeQuest Timing Analyzer
Getting Started with the TimeQuest Analyzer
6–17
h For more information about the TimeQuest analyzer GUI, refer to About TimeQuest
Timing Analysis in Quartus II Help.
To run the TimeQuest analyzer in command-line mode for easy integration with
scripted design flows, type the following command at a system command prompt:
quartus_sta r
For more information about using Tcl commands to constrain and analyze your
design, refer to “Constraining and Analyzing with Tcl Commands” on page 6–22.
Table 6–5 shows a summary of the command-line options available in command-line
mode.
Table 6–5. Summary of Command-Line Options (Part 1 of 2)
Command-Line Option
Description
-h | --help
Provides help information on quartus_sta.
-t <script file> |
--script=<script file>
Sources the <script file>.
-s | --shell
Enters shell mode.
--tcl_eval <tcl command>
Evaluates the Tcl command <tcl command>.
For all clocks in the design, run the following commands:
report_timing -npaths 1 -to_clock $clock
report_timing -setup -npaths 1 -to_clock $clock
--do_report_timing
report_timing -hold -npaths 1 -to_clock $clock
report_timing -recovery -npaths 1 -to_clock $clock
report_timing -removal -npaths 1 -to_clock $clock
--force_dat
Forces the delay annotator to annotate the new delays from the recently compiled
design to the compiler database.
--lower_priority
Lowers the computing priority of the quartus_sta process.
--post_map
Uses the post-map database results.
--qsf2sdc
Converts assignments from the Quartus II Settings File (.qsf) format to the .sdc
format.
--sdc=<SDC file>
Specifies the .sdc to read.
--report_script=<script>
Specifies a custom report script to call.
--speed=<value>
Specifies the device speed grade used for timing analysis.
--tq2hc
Generate temporary files to convert the TimeQuest analyzer .sdc file(s) to a
PrimeTime .sdc that can be used by the HardCopy® Design Center.
--tq2pt
Generates temporary files to convert the TimeQuest Timing Analyzer .sdc file(s) to a
PrimeTime .sdc.
-f <argument file>
Specifies a file containing additional command-line arguments.
-c <revision name> |
--rev=<revision_name>
Specifies which revision and its associated .qsf to use.
--multicorner
Specifies that all slack summary reports be generated for both slow- and
fast-corners.
--multicorner[=on|off]
Turns off the multicorner timing analysis.
--voltage=<value_in_mV>
Specifies the device voltage, in mV, used in timing analysis.
May 2011
Altera Corporation
Quartus II Handbook Version 11.0 Volume 3: Verification
6–18
Chapter 6: The Quartus II TimeQuest Timing Analyzer
Getting Started with the TimeQuest Analyzer
Table 6–5. Summary of Command-Line Options (Part 2 of 2)
Command-Line Option
Description
--temperature=
<value_in_C>
Specifies the device temperature in degrees Celsius, used in timing analysis.
--parallel
[=<num_processors>]
Specifies the number of computer processors to use on a multiprocessor system.
--64bit
Enables 64-bit version of the executable.
Locating Timing Paths in Other Tools
You can locate paths and elements from the TimeQuest analyzer to other tools in the
Quartus II software. Use the Locate Path command in the TimeQuest analyzer GUI or
the locate command-line command to locate paths.
h For more information about locating paths from the TimeQuest analyzer, refer to
Viewing Timing Analysis Results and locate in Quartus II Help.
Example 6–4 shows how to locate ten paths from TimeQuest analyzer to the Chip
Planner and locate all data ports in the Technology Map Viewer.
Example 6–4. Locating from the TimeQuest Analyzer
# Locate in the Chip Planner all of the nodes in the longest ten paths
locate [get_path -npaths 10] -chip
# locate all ports that begin with data to the Technology Map Viewer
locate [get_ports data*] -tmv
Quartus II Handbook Version 11.0 Volume 3: Verification
May 2011 Altera Corporation
Chapter 6: The Quartus II TimeQuest Timing Analyzer
Getting Started with the TimeQuest Analyzer
6–19
Recommended Flows
The Quartus II TimeQuest Timing Analyzer performs everything from constraint
validation to timing verification as part of the compilation flow. Figure 6–15 shows
the recommended design flow steps to maximize and leverage the benefits of the
TimeQuest Analyzer. Details about each step are provided after the figure.
Figure 6–15. Design Flow with the TimeQuest Timing Analyzer
Create Quartus II Project
and Specify Design Files
Perform Initial Compilation
Specify Timing Requirements
Perform Compilation
Verify Timing
Creating and Setting Up your Design
You must first create your project in the Quartus II software. Make sure to include all
the necessary design files, including any existing Synopsys Design Constraints (.sdc)
files that contain timing constraints for your design.
1
If you previously created and specified an .sdc for your project, you should perform a
full compilation to create a post-fit database.
h For more information, refer to Managing Files in a Project in Quartus II Help.
Performing an Initial Compilation
After your project is set up, you must compile your design to create an initial design
database before you specify timing constraints. You can either perform Analysis and
Synthesis to create a post-map database, or perform a full compilation to create a
post-fit database. Creating a post-map database reduces processing time and is
sufficient for creating initial timing constraints. The type of database you create
determines the type of timing netlist generated by the TimeQuest analyzer, a
post-map netlist if you perform Analysis and Synthesis or a post-fit netlist if you
perform a full compilation.
1
May 2011
If you want to create a post-map database and your design uses incremental
compilation, you must merge your design partitions before performing Analysis and
Synthesis.
Altera Corporation
Quartus II Handbook Version 11.0 Volume 3: Verification
6–20
Chapter 6: The Quartus II TimeQuest Timing Analyzer
Getting Started with the TimeQuest Analyzer
h For more information, refer to Setting up and Running Analysis and Synthesis and
Setting up and Running a Compilation in Quartus II Help.
Specifying Timing Requirements
Before running timing analysis with the TimeQuest analyzer, you must first create a
timing netlist, and then you can specify initial timing constraints that describe the
clock characteristics, timing exceptions, and signal transition arrival and required
times. You can use the TimeQuest Timing Analyzer Wizard to enter basic, initial
constraints for your design, or you can specify timing constraints with the dialog
boxes in the TimeQuest analyzer or with a Tcl script. The timing constraints you create
with the TimeQuest analyzer are saved in the .sdc format.
h For more information, refer to Specifying Timing Constraints and Exceptions in
Quartus II Help.
1
When you create timing constraints with the TimeQuest analyzer GUI, the .sdc is not
automatically updated. To write your constraints to an .sdc, use the write_sdc
command in command-line mode, or the Write SDC File command in the TimeQuest
analyzer GUI. Writing constraints to an existing .sdc overwrites the existing file. After
editing timing constraints in your design, if you want to save the constraints to an
.sdc, you should create a new file rather than overwriting the existing file.
You can also use an existing .sdc rather than creating new timing constraints. To use
timing constraints from an existing .sdc and any SDC timing constraints embedded in
your HDL files, use the read_sdc command in command-line mode, or the Read
SDC File in the TimeQuest analyzer GUI.
The .sdc should contain only SDC commands; Tcl commands to manipulate the
timing netlist or control the compilation flow should be run as part of a separate Tcl
script. After you create timing constraints, you must update the timing netlist. The
TimeQuest analyzer applies all constraints to the netlist for verification and removes
any invalid or false paths in the design from verification.
1
The constraints in the .sdc are read in sequence. You must first make a constraint
before making any references to it. For example, if a generated clock references a base
clock, the base clock constraint must be made before the generated clock constraint.
Fitting and Timing Analysis with .sdc Files
You can specify the same or different .sdc files for the Quartus II Fitter to use during
the place-and-route process, and the TimeQuest analyzer for static timing analysis.
Using different .sdc files allows you to have one set of constraints for the
place-and-route process and another set of constraints for final timing sign-off in the
TimeQuest analyzer.
To specify an .sdc for the Fitter, you must add the .sdc to your project. The Fitter
optimizes your design based on the requirements in the .sdc.
Quartus II Handbook Version 11.0 Volume 3: Verification
May 2011 Altera Corporation
Chapter 6: The Quartus II TimeQuest Timing Analyzer
Getting Started with the TimeQuest Analyzer
6–21
Performing a Full Compilation
After creating initial timing constraints, you must fully compile your design. During
full compilation the Fitter optimizes the placement of logic to meet your constraints.
When compilation is complete, you can open the TimeQuest analyzer to verify timing
results and to generate summary, clock setup and clock hold, recovery, and removal
reports for all defined clocks in the design.
Verifying Timing
During timing analysis, the TimeQuest analyzer analyzes the timing paths in the
design, calculates the propagation delay along each path, checks for timing constraint
violations, and reports timing results as positive slack or negative slack. Negative
slack indicates a timing violation. If the TimeQuest analyzer reports any timing
violations, you can constrain those paths to correct the violations. As you verify
timing, you might encounter failures along critical paths. If you encounter failures
along critical paths, use the timing reports to analyze your design and determine how
best to optimize your design. If you modify, remove, or add constraints, you should
perform a full compilation again. This iterative process allows you to resolve your
timing violations in the design.
h For more information, refer to Viewing Timing Analysis Results in Quartus II Help.
Figure 6–16 shows the recommended flow for constraining and analyzing your
design within the TimeQuest analyzer. Included are the corresponding Tcl commands
for each step.
Figure 6–16. The TimeQuest Timing Analyzer Flow
Open Project
project_open
Create Timing Netlist
create_timing_netlist
Constrain the Design
create_clock
create_generated_clock
set_clock_uncertainty
derive_pll_clocks
set_clock_latency
set_input_delay
set_output_delay
...
Update Timing Netlist
update_timing_netlist
Verify Static Timing Analysis
Results
report_sdc
report_clocks_transfers
report_timing
report_min_pulse_width
report_clocks
report_net_timing
report_min_pulse_width
report_ucp
May 2011
Altera Corporation
Quartus II Handbook Version 11.0 Volume 3: Verification
6–22
Chapter 6: The Quartus II TimeQuest Timing Analyzer
Constraining and Analyzing with Tcl Commands
SDC File Precedence
The Fitter and the TimeQuest analyzer read the .sdc files from the files list in the .qsf
in the order they are listed, from top to bottom.
Figure 6–17 shows the order in which the Quartus II software searches for an .sdc.
Figure 6–17. .sdc File Order of Precedence
Is an .sdc specified in the
.qsf?
Yes
No
Does an .sdc named
<current revision>.sdc
exist in the project
directory?
Yes
No
Manually create an .sdc file <current revision>.sdc
based on the current .qsf (1)
Analyze the design
1
If you type the read_sdc command at the command line without any arguments, the
TimeQuest analyzer follows precedence order shown in Figure 6–17.
Constraining and Analyzing with Tcl Commands
You can use Tcl commands from the Quartus II software Tcl Application
Programming Interface (API) to constrain and analyze your design, and to collect
information about your design. This section focuses on executing timing analysis
tasks with Tcl commands, however; you can perform many of the same functions in
the TimeQuest analyzer GUI. You can use standard SDC Tcl commands and SDC
extension commands in addition to TimeQuest analyzer Tcl commands. SDC
commands and SDC constraints are a specialized form of Tcl command.
The following Tcl packages are available in the Quartus II software:
■
::quartus::sta
■
::quartus::sdc
■
::quartus::sdc_ext
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.
Quartus II Handbook Version 11.0 Volume 3: Verification
May 2011 Altera Corporation
Chapter 6: The Quartus II TimeQuest Timing Analyzer
Constraining and Analyzing with Tcl Commands
6–23
Wildcard Characters
To apply constraints to many nodes in a design, use the “*” and “?” wildcard
characters. The “*” wildcard character matches any string; the “?” wildcard character
matches any single character.
If you make an assignment to node reg*, the TimeQuest analyzer searches for and
applies the assignment to all design nodes that match the prefix reg with any number
of following characters, such as reg, reg1, reg[2], regbank, and reg12bank.
If you make an assignment to a node specified as reg?, the TimeQuest analyzer
searches and applies the assignment to all design nodes that match the prefix reg and
any single character following; for example, reg1, rega, and reg4.
Collection Commands
The commands in the Tcl API for the TimeQuest analyzer often return port, pin, cell,
or node names in a data set called a collection. In your Tcl scripts you can iterate over
the values in collections to analyze or modify constraints in your design.
The TimeQuest analyzer supports collection APIs that provide easy access to ports,
pins, cells, or nodes in the design. Use collection APIs with any valid constraints or Tcl
commands specified in the TimeQuest analyzer.
Table 6–6 describes the collection commands supported by the TimeQuest timing
analyzer.
Table 6–6. SDC Collection Commands
Command
Description
all_clocks
Returns a collection of all clocks in the design.
all_inputs
Returns a collection of all input ports in the design.
all_outputs
Returns a collection of all output ports in the design.
all_registers
Returns a collection of all registers in the design.
get_cells
Returns a collection of cells in the design. All cell names in the collection match the specified
pattern. Wildcards can be used to select multiple cells at the same time.
get_clocks
Returns a collection of clocks in the design. When used as an argument to another command, such
as the -from or -to of set_multicycle_path, each node in the clock represents all nodes
clocked by the clocks in the collection. The default uses the specific node (even if it is a clock) as
the target of a command.
get_nets
Returns a collection of nets in the design. All net names in the collection match the specified
pattern. You can use wildcards to select multiple nets at the same time.
get_pins
Returns a collection of pins in the design. All pin names in the collection match the specified
pattern. You can use wildcards to select multiple pins at the same time.
get_ports
Returns a collection of ports (design inputs and outputs) in the design.
Adding and Removing Collection Items
Filters used with collection commands limit collection items identified by the
command. For example, if a design contains registers named src0, src1, src2, and
dst0, the collection command [get_registers src*] identifies registers src0, src1,
and src2, but not register dst0. To identify register dst0, you must use an additional
command, [get_registers dst*].
May 2011
Altera Corporation
Quartus II Handbook Version 11.0 Volume 3: Verification
6–24
Chapter 6: The Quartus II TimeQuest Timing Analyzer
Constraining and Analyzing with Tcl Commands
To overcome this limitation when using filters, use the add_to_collection and
remove_from_collection commands. The add_to_collection command allows you
to add additional items to an existing collection. Example 6–5 shows the
add_to_collection command and arguments.
Example 6–5. add_to_collection Command
add_to_collection <first collection> <second collection>
1
The add_to_collection command adds the contents of the second collection to the
first collection, modifying the first collection, but not the second.
The remove_from_collection command allows you to remove items from an existing
collection. Example 6–6 shows the remove_from_collection command and
arguments.
Example 6–6. remove_from_collection Command
remove_from_collection <first collection> <second collection>
Example 6–7 shows examples of how to add elements to collections.
Example 6–7. Adding Items to a Collection
#Setting up initial collection of registers
set regs1 [get_registers a*]
#Setting up initial collection of keepers
set kprs1 [get_keepers b*]
#Creating a new set of registers of $regs1 and $kprs1
set regs_union [add_to_collection $kprs1 $regs1]
#OR
# Creating a new set of registers of $regs1 and b*
# Note that the new collection appends only registers with name b*
# not all keepers
set regs_union [add_to_collection $regs1 b*]
h For more information about the add_to_collection and remove_from_collection
commands—including full syntax information, options, and example usage—refer to
add_to_collection and remove_from_collection in Quartus II Help.
Refining Collections with Wildcards
The collection commands get_cells and get_pins have options that allow you to
refine searches that include wildcard characters.
Quartus II Handbook Version 11.0 Volume 3: Verification
May 2011 Altera Corporation
Chapter 6: The Quartus II TimeQuest Timing Analyzer
Constraining and Analyzing with Tcl Commands
6–25
Table 6–7 shows examples of search strings that use options to refine the search and
wildcards. The examples in Table 6–7 filter the following cells and pin names to
illustrate function:
■
foo
■
foo|bar
■
foo|dataa
■
foo|datab
■
foo|bar|datac
■
foo|bar|datad
Table 6–7. Sample Search Strings and Search Results
Search String
Search Result
get_pins *|dataa
foo|dataa
get_pins *|datac
<empty>
get_pins *|*|datac
foo|bar|datac
get_pins foo*|*
foo|dataa, foo|datab
get_pins -hierarchical *|*|datac
<empty> (1)
get_pins -hierarchical foo|*
foo|dataa, foo|datab
get_pins -hierarchical *|datac
foo|bar|datac
get_pins -hierarchical foo|*|datac
<empty> (1)
get_pins -compatibility *|datac
foo|bar|datac
get_pins -compatibility *|*|datac
foo|bar|datac
Note to Table 6–7:
(1) The search result is <empty> because of the additional *|*| in the search string.
Removing Constraints and Exceptions
When you use the TimeQuest analyzer interactively, it is sometimes necessary to
remove a constraint or exception. Use the following commands to remove constraints
and exceptions:
May 2011
■
remove_clock
■
remove_clock_groups
■
remove_clock_latency
■
remove_clock_uncertainty
■
remove_input_delay
■
remove_output_delay
■
remove_annotated_delay
■
reset_design
■
reset_timing_derate
Altera Corporation
Quartus II Handbook Version 11.0 Volume 3: Verification
6–26
Chapter 6: The Quartus II TimeQuest Timing Analyzer
Creating Clocks and Clock Constraints
h For more information—including a complete list of commands and full syntax
information, options, and example usage—refer to ::quartus::sdc and ::quartus::sdc_ext
in Quartus II Help.
Creating Clocks and Clock Constraints
To ensure accurate static timing analysis results, you must specify all clocks and any
associated clock characteristics in your design. The TimeQuest analyzer supports SDC
commands that accommodate various clocking schemes and clock characteristics.
Creating Clocks
To create a clock at any register, port, or pin, use the create_clock command. You can
create each clock with unique characteristics. Clocks defined with the create_clock
command have a default source latency value of zero. The TimeQuest analyzer
automatically computes the clock’s network latency for non-virtual clocks.
h For more information about the create_clock command—including full syntax
information, options, and example usage—refer to create_clock in Quartus II Help.
Example 6–8 shows how to create a 10 ns clock with a 50% duty cycle that is phase
shifted by 90 degrees applied to port clk_sys.
Example 6–8. 100MHz Shifted by 90 Degrees Clock Creation
create_clock -period 10 -waveform { 2.5 7.5 } [get_ports clk_sys]
Creating Virtual Clocks
To create virtual clocks, use the create_clock command with no value specified for
the <targets> option. A virtual clock is a clock that does not have a real source in the
design or that does not interact directly with the design. For example, if a clock feeds
only an external device’s clock port and not a clock port in the design, and the
external device then feeds, or is fed by, a port in the design, it is considered a virtual
clock.
1
Use virtual clocks for set_input_delay and set_output_delay constraints.
Quartus II Handbook Version 11.0 Volume 3: Verification
May 2011 Altera Corporation
Chapter 6: The Quartus II TimeQuest Timing Analyzer
Creating Clocks and Clock Constraints
6–27
Figure 6–18 shows a design where a virtual clock is required for the TimeQuest
analyzer to properly analyze the relationship between the external register and the
registers in the design. Because the oscillator, virt_clk, does not interact with the
Altera device, but acts as the clock source for the external register, you must declare
the clock as a virtual clock. After you create the virtual clock, you can perform a
register-to-register analysis between the register in the Altera device and the register
in the external device.
Figure 6–18. Virtual Clock Board Topology
Altera FPGA
External Device
datain
reg_a
reg_b
dataout
system_clk
virt_clk
Example 6–9 shows how to create a 10 ns virtual clock named virt_clk with a 50%
duty cycle where the first rising edge occurs at 0 ns. The virtual clock is then used as
the clock source for an output delay constraint.
Example 6–9. Virtual Clock Example
#create base clock for the design
create_clock -period 5 [get_ports system_clk]
#create the virtual clock for the external register
create_clock -period 10 -name virt_clk -waveform { 0 5 }
#set the output delay referencing the virtual clock
set_output_delay -clock virt_clk -max 1.5 [get_ports dataout]
Creating Multifrequency Clocks
You should create a multifrequency clock if your design has more than one clock
source feeding a single clock node in the design. The additional clock may act as a
low-power clock, with a lower frequency than the primary clock.
To create multifrequency clocks, use the create_clock command with the -add option
to add more than one clock to a clock node. Example 6–10 shows how to create a 10 ns
clock applied to clock port clk, and then add an additional 15 ns clock to the same
clock port. The TimeQuest analyzer uses both clocks when it performs timing
analysis.
Example 6–10. Multifrequency Clock Example
create_clock –period 10 –name clock_primary –waveform { 0 5 } \
[get_ports clk]
create_clock –period 15 –name clock_secondary –waveform { 0 7.5 } \
[get_ports clk] -add
May 2011
Altera Corporation
Quartus II Handbook Version 11.0 Volume 3: Verification
6–28
Chapter 6: The Quartus II TimeQuest Timing Analyzer
Creating Clocks and Clock Constraints
Creating Generated Clocks
To create generated clocks, use the create_generated_clock command. The
TimeQuest analyzer considers clock dividers, ripple clocks, or circuits that modify or
change the characteristics of the incoming or master clock as generated clocks. You
should define as generated clocks the output of circuits that modify or change the
characteristics of the incoming or master clock. Defining the output of the circuits as
generated clocks allows the TimeQuest analyzer to analyze these clocks and account
for any associated network latency. Source latencies are based on clock network
delays from the master clock, but not necessarily the master pin. You can use the
set_clock_latency -source command to override source latency.
h For more information about the create_generated_clock command—including full
syntax information, options, and example usage—refer to create_generated_clock in
Quartus II Help.
Figure 6–19 shows how to generate an inverted clock based on a 10 ns clock.
Figure 6–19. Generating an Inverted Clock
create_clock -period 10 [get_ports clk]
create_generated_clock -divide_by 1 -invert -source [get_ports clk] \
[get_registers gen|clkreg]
Edges 1
2
3
4
5
6
7
8
clk
gen|clkreg
Time
Quartus II Handbook Version 11.0 Volume 3: Verification
0
10
20
30
May 2011 Altera Corporation
Chapter 6: The Quartus II TimeQuest Timing Analyzer
Creating Clocks and Clock Constraints
6–29
Figure 6–20 shows how to modify the generated clock by defining and shifting the
edges.
Figure 6–20. Edge Shifting a Generated Clock
create_clock -period 10 -waveform { 0 5 } [get_ports clk]
# Creates a divide-by-two clock
create_generated_clock -source [get_ports clk] -edges { 1 3 5 } [get_registers \
clkdivA|clkreg]
# Creates a divide-by-two clock independent of the master clocks’ duty cycle (now 50%)
create_generated_clock -source [get_ports clk] -edges { 1 1 5 } -edge_shift { 0 2.5 0 }
\ [get_registers clkdivB|clkreg]
Edges 1
2
3
4
5
6
7
8
clk
clkdivA|clkreg
clkdivB|clkreg
Time
0
10
20
30
Figure 6–21 shows the effect of the applying a multiplication factor to the generated
clock.
Figure 6–21. Multiplying a Generated Clock
create_clock -period 10 -waveform { 0 5 } [get_ports clk]
# Creates a multiply-by-two clock
create_generated_clock -source [get_ports clk] -multiply_by 2 [get_registers \
clkmult|clkreg]
clk
clkmult|clkreg
Time
0
10
20
30
Automatically Detecting Clocks and Creating Default Clock Constraints
To automatically create clocks for all clock nodes in your design, use the
derive_clocks command. The derive_clocks command is equivalent to using the
create_clock command for each register or port feeding the clock pin of a register.
The derive_clocks command creates clocks on ports or registers to ensure every
register in the design has a clock, and it applies one period to all base clocks in your
design.
May 2011
Altera Corporation
Quartus II Handbook Version 11.0 Volume 3: Verification
6–30
Chapter 6: The Quartus II TimeQuest Timing Analyzer
Creating Clocks and Clock Constraints
To provide a complete clock analysis, if there are no clock constraints in your design,
the TimeQuest analyzer automatically creates default clock constraints for all detected
unconstrained clock nodes. The TimeQuest analyzer automatically creates clocks only
when all synchronous elements have no associated clocks. For example, the
TimeQuest analyzer does not create a default clock constraint if your design contains
two clocks and you assigned constraints to one of the clocks. However, if you did not
assign constraints to either clock, then the TimeQuest analyzer creates a default clock
constraint.
Example 6–11 shows how the TimeQuest analyzer creates a base clock with a 1 GHz
requirement for unconstrained clock nodes.
Example 6–11. Create Base Clock for Unconstrained Clock Nodes
derive_clocks -period 1
1
To achieve a thorough and realistic analysis of your design’s timing requirements, you
should make individual clock constraints for all clocks in your design. Do not use the
derive_clocks command for final timing sign-off; instead, you should create clocks
for all clock sources with the create_clock and create_generated_clock commands.
h For more information about the derive_clocks command—including full syntax
information, options, and example usage—refer to derive_clocks in Quartus II Help.
Deriving PLL Clocks
Because you should create clocks for all clock nodes, you must create generated clocks
for all PLL outputs in your design. Use the derive_pll_clocks command to direct the
TimeQuest analyzer to automatically create the appropriate generated clocks, or use
the create_generated_clock command to manually create the generated clocks.
h For more information about the derive_pll_clocks command—including full syntax
information, options, and example usage—refer to derive_pll_clocks in Quartus II Help.
Use the derive_pll_clocks command to direct the TimeQuest analyzer to
automatically search the timing netlist for all unconstrained PLL output clocks. The
derive_pll_clocks command calls the create_generated_clock command to create
generated clocks on the outputs of the PLL. The source for the
create_generated_clock command is the input clock pin of the PLL.
You must create manually a base clock for the input clock port of the PLL. If you do
not define a clock for the input clock node of the PLL, no clocks are reported for the
PLL outputs and the TimeQuest analyzer issues a warning message when the timing
netlist is updated.
1
You can use the -create_base_clocks option to create the input clocks for the PLL
inputs automatically.
You can include the derive_pll_clocks command in your .sdc, which allows the
derive_pll_clocks command to automatically detect any changes to the PLL. Each
time the TimeQuest analyzer reads your .sdc, it generates the appropriate
create_generated_clocks command for the PLL output clock pin. If you use the
write_sdc -expand command after the derive_pll_clocks command, the new .sdc
Quartus II Handbook Version 11.0 Volume 3: Verification
May 2011 Altera Corporation
Chapter 6: The Quartus II TimeQuest Timing Analyzer
Creating Clocks and Clock Constraints
6–31
contains the individual create_generated_clock commands for the PLL output clock
pins and not the derive_pll_clocks command. Any changes to the properties of the
PLL are not automatically reflected in the new .sdc. You must manually update the
create_generated_clock commands in the new .sdc written by the
derive_pll_clocks command to reflect the changes to the PLL.
1
Writing constraints to an existing .sdc overwrites the existing file. After editing timing
constraints in your design, if you want to save the constraints to an .sdc, you should
create a new file rather than overwriting the existing file.
1
The derive_pll_clocks command also constrains any LVDS transmitters or LVDS
receivers in the design by adding the appropriate multicycle constraints to account for
any deserialization factors.
Figure 6–22 shows a simple PLL design with a register-to-register path.
Figure 6–22. Simple PLL Design
dataout
reg_1
pll_inclk
reg_2
pll_inst
Example 6–12 shows the messages generated by the TimeQuest analyzer when you
use the derive_pll_clocks command to automatically constrain the PLL for the
design shown in Figure 6–22.
Example 6–12. derive_pll_clocks Command Messages
Info:
Info: Deriving PLL Clocks:
Info: create_generated_clock -source
pll_inst|altpll_component|pll|inclk[0] -divide_by 2 -name
pll_inst|altpll_component|pll|clk[0]
pll_inst|altpll_component|pll|clk[0]
Info:
The input clock pin of the PLL is the node
pll_inst|altpll_component|pll|inclk[0] used for the -source option. The name of
the output clock of the PLL is the PLL output clock node,
pll_inst|altpll_component|pll|clk[0].
If the PLL is in clock switchover mode, multiple clocks are created for the output clock
of the PLL; one for the primary input clock (for example, inclk[0]), and one for the
secondary input clock (for example, inclk[1]). You should create exclusive clock
groups for the primary and secondary output clocks.
For more information about creating exclusive clock groups, refer to “Creating Clock
Groups” on page 6–32.
May 2011
Altera Corporation
Quartus II Handbook Version 11.0 Volume 3: Verification
6–32
Chapter 6: The Quartus II TimeQuest Timing Analyzer
Creating Clocks and Clock Constraints
Before you can generate any reports for this design, you must create a base clock for
the PLL input clock port. You do not have to generate the base clock on the input clock
pin of the PLL, pll_inst|altpll_component|pll|inclk[0]. The clock created on the
PLL input clock port propagates to all fan-outs of the clock port, including the PLL
input clock pin. Example 6–13 shows how to create a base clock for the PLL input
clock port.
Example 6–13. Create Base Clock for PLL input Clock Port
create_clock -period 5 [get_ports pll_inclk]
Creating Clock Groups
To specify clocks in your design that are exclusive or asynchronous, use the
set_clock_groups command.
h For more information about the set_clock_groups command—including full syntax
information, options, and example usage—refer to set_clock_groups in Quartus II Help.
Exclusive Clock Groups
Use the -exclusive option to declare that two clocks are mutually exclusive. You may
want to declare clocks as mutually exclusive when multiple clocks are created on the
same node or for multiplexed clocks. For example, a port can be clocked by either a
25-MHz or a 50-MHz clock. To constrain this port, you should create two clocks on the
port, and then create clock groups to declare that they cannot coexist in the design at
the same time. Declaring the clocks as mutually exclusive eliminates any clock
transfers that may be derived between the 25-MHz clock and the 50-MHz clock.
Example 6–14 shows how to create mutually exclusive clock groups.
Example 6–14. Create Mutually Exclusive Clock Groups
create_clock -period 40 -name clk_A [get_ports {port_A}]
create_clock -add -period 20 -name clk_B [get_ports {port_A}]
set_clock_groups -exclusive -group {clk_A} -group {clk_B}
A group is defined with the -group option. The TimeQuest analyzer excludes the
timing paths between clocks for each of the separate groups.
Asynchronous Clock Groups
Use the -asynchronous option to create asynchronous clock groups. Clocks contained
within an asynchronous clock group are considered asynchronous to clocks in other
clock groups; however, any clocks within a clock group are considered synchronous
to each other.
1
The TimeQuest analyzer assumes all clocks are related unless constrained otherwise.
Quartus II Handbook Version 11.0 Volume 3: Verification
May 2011 Altera Corporation
Chapter 6: The Quartus II TimeQuest Timing Analyzer
Creating Clocks and Clock Constraints
6–33
For example, if your design has three clocks, clk_A, clk_B, and clk_C, and you
establish that clk_A and clk_B are related to each other, but clock clk_C operates
completely asynchronously, you can set up clock groups to define the clock behavior.
Example 6–15 shows how to create a clock group containing clocks clk_A and clk_B
and a second unrelated clock group containing clk_C.
Example 6–15. Create Asynchronous Clock Groups
set_clock_groups -asynchronous -group {clk_A clk_B} -group {clk_C}
Alternatively, in this example, you can create a clock group containing only clk_C to
ensure that clk_A and clk_B are synchronous with each other and asynchronous with
clk_C. Because clk_C is the only clock in the constraint, it is asynchronous with every
other clock in the design.
Accounting for Clock Effect Characteristics
The clocks you create with the TimeQuest analyzer are ideal clocks that do not
account for any board effects. You can account for clock effect characteristics with
clock latency and clock uncertainty.
Clock Latency
There are two forms of clock latency, clock source latency and clock network latency.
Source latency is the propagation delay from the origin of the clock to the clock
definition point (for example, a clock port). Network latency is the propagation delay
from a clock definition point to a register’s clock pin. The total latency at a register’s
clock pin is the sum of the source and network latencies in the clock path.
To specify source latency to any clock ports in your design, use the
set_clock_latency command.
1
The TimeQuest analyzer automatically computes network latencies; therefore, you
only can create source latency with the set_clock_latency command. You must use
the -source option.
h For more information about the set_clock_latency command—including full syntax
information, options, and example usage—refer to set_clock_latency in Quartus II
Help.
Clock Uncertainty
To specify clock uncertainty, or skew, for clocks or clock-to-clock transfers, use the
set_clock_uncertainty command. You can specify the uncertainty separately for
setup and hold, and you can specify separate rising and falling clock transitions. The
TimeQuest analyzer subtracts setup uncertainty from the data required time for each
applicable path and adds the hold uncertainty to the data required time for each
applicable path.
To automatically apply interclock, intraclock, and I/O interface uncertainties, use the
derive_clock_uncertainty command. The TimeQuest analyzer automatically
applies clock uncertainties to clock-to-clock transfers in the design, and calculates
both setup and hold uncertainties for each clock-to-clock transfer.
May 2011
Altera Corporation
Quartus II Handbook Version 11.0 Volume 3: Verification
6–34
Chapter 6: The Quartus II TimeQuest Timing Analyzer
Creating Clocks and Clock Constraints
Any clock uncertainty constraints applied to source and destination clock pairs with
the set_clock_uncertainty command have a higher precedence than the clock
uncertainties derived with the derive_clock_uncertainty command for the same
source and destination clock pairs. For example, if you use the
set_clock_uncertainty command to set clock uncertainty between clka and clkb,
the TimeQuest analyzer ignores the values for the clock transfer calculated with the
derive_clock_uncertainty command. The TimeQuest analyzer reports the values
calculated with the derive_clock_uncertainty command even if they are not used.
1
Changes to the bandwidth settings of a PLL do not have an impact on the clock
uncertainty values derived by the TimeQuest analyzer when you use the
derive_clock_uncertainty command.
To automatically remove previous clock uncertainty assignments, use the -overwrite
option. To manually remove previous clock uncertainty assignments, use the
remove_clock_uncertainty command.
h For more information about the set_clock_uncertainty, derive_clock_uncertainty,
and remove_clock_uncertainty commands—including full syntax information,
options, and example usage—refer to set_clock_uncertainty, derive_clock_uncertainty,
and remove_clock_uncertainty in Quartus II Help.
I/O Interface Uncertainty
To specify I/O interface uncertainty, you must create a virtual clock and constrain the
input and output ports with the set_input_delay and set_output_delay commands
that reference the virtual clock. You must use a virtual clock to prevent the
derive_clock_uncertainty command from applying clock uncertainties for either
intraclock or interclock transfers to an I/O interface clock transfer when the
set_input_delay or set_output_delay commands reference a clock port or PLL
output. If you do not reference a virtual clock with the set_input_delay or
set_output_delay commands, the derive_clock_uncertainty command calculates
intraclock or interclock uncertainty values for the I/O interface.
f For information about source-synchronous constraints, which require generated
clocks rather than virtual clocks, refer to AN 433: Constraining and Analyzing SourceSynchronous Interfaces.
Quartus II Handbook Version 11.0 Volume 3: Verification
May 2011 Altera Corporation
Chapter 6: The Quartus II TimeQuest Timing Analyzer
Creating Clocks and Clock Constraints
6–35
Create the virtual clock with the same properties as the original clock that is driving
the I/O port. Figure 6–23 shows a typical input I/O interface with clock
specifications.
Figure 6–23. I/O Interface Clock Specifications
External Device
Altera FPGA
data_in
D
Q
D
reg1
Q
reg1
clk_in
100 MHz
Example 6–16 shows the SDC commands to constrain the I/O interface shown in
Figure 6–23.
Example 6–16. SDC Commands to Constrain the I/O Interface
# 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 <delay value>
# [get_ports data_in]
set_input_delay -clock virt_clk_in <delay value> [get_ports data_in]
Intraclock transfers occur when the register-to-register transfer takes place in the core
of the FPGA and the source and destination clocks come from the same PLL output
pin or clock port. Figure 6–24 shows an intraclock transfer.
Figure 6–24. Intraclock Transfer
Source Register
data_in
D
Q
Destination Register
D
Q
data_out
clk0
clk_in
May 2011
Altera Corporation
PLL
Quartus II Handbook Version 11.0 Volume 3: Verification
6–36
Chapter 6: The Quartus II TimeQuest Timing Analyzer
Creating I/O Constraints
Interclock transfers occur when a register-to-register transfer takes place in the core of
the FPGA and the source and destination clocks come from a different PLL output pin
or clock port. Figure 6–25 shows an interclock transfer.
Figure 6–25. Interclock Transfer
Source Register
data_in
D
Q
Destination Register
D
Q
data_out
clk0
clk_in
PLL
I/O interface clock transfers occur when data transfers from an I/O port to the core of
the FPGA or from the core of the FPGA to the I/O port. Figure 6–26 shows an I/O
interface clock transfer.
Figure 6–26. I/O Interface Clock Transfer
reg1
data_in
D
Q
data_out
clk_in
Creating I/O Constraints
To specify any external device or board timing parameters, use input and output
delay constraints. When you apply these constraints, the TimeQuest analyzer
performs static timing analysis on the entire system.
To specify input delay constraints to ports in the design and the data arrival time at a
port with respect to a given clock, use the set_input_delay command. To specify
output delay constraints to ports in the design and the data required time at a port
with respect to a given clock, use the set_output_delay command.
Figure 6–27 shows an input delay path.
Figure 6–27. Input Delay
External Device
Altera Device
Oscillator
Quartus II Handbook Version 11.0 Volume 3: Verification
May 2011 Altera Corporation
Chapter 6: The Quartus II TimeQuest Timing Analyzer
Creating Delay and Skew Constraints
6–37
Figure 6–28 shows an output delay path.
Figure 6–28. Output Delay
Altera Device
External Device
Oscillator
By default, a set of input or output delays, that is a -min and -max pair or a -rise and
-fall pair, is allowed for only one -clock, -clock_fall, and -reference_pin
combination. Specifying an input delay on the same port for a different -clock,
-clock_fall, or -reference_pin setting removes any previously set input delays,
unless you specify the -add_delay option. When you specify the -add_delay option,
the TimeQuest analyzer uses the worst-case values.
1
The -min and -max and -rise and -fall options are mutually exclusive.
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 Delay and Skew Constraints
The TimeQuest analyzer supports the Synopsys Design Constraint format for
constraining timing for the ports in your design. These constraints allow the
TimeQuest analyzer to perform a system static timing analysis that includes not only
the FPGA internal timing, but also any external device timing and board timing
parameters.
Net Delay
To perform minimum or maximum analysis across nets and report the net delays, use
the set_net_delay command in conjunction with the report_net_delay command.
You can use the set_net_delay and report_net_delay commands to verify
timing-critical delays for high-speed interfaces.
h For more information about the set_net_delay and report_net_delay commands—
including full syntax information, options, and example usage—refer to set_net_delay
and report_net_delay in Quartus II Help.
Advanced I/O Timing and Board Trace Model Delay
The TimeQuest analyzer can use advanced I/O timing and board trace model
assignments to model I/O buffer delays in your design.
May 2011
Altera Corporation
Quartus II Handbook Version 11.0 Volume 3: Verification
6–38
Chapter 6: The Quartus II TimeQuest Timing Analyzer
Creating Timing Exceptions
If you change any advanced I/O timing settings or board trace model assignments,
recompile your design before you analyze timing, or use the -force_dat option to
force delay annotation when you create a timing netlist. Example 6–17 shows how to
force delay annotation when creating a timing netlist.
Example 6–17. Forcing Delay Annotation
create_timing_netlist -force_dat r
h For more information about using advanced I/O timing, refer to Using Advanced I/O
Timing in Quartus II Help.
f For more information about advanced I/O timing, refer to the I/O Management
chapter in volume 2 of the Quartus II Handbook.
Maximum Skew
To specify the maximum path-based skew requirements for registers and ports in the
design and report the results of maximum skew analysis, use the set_max_skew
command in conjunction with the report_max_skew command.
By default, the set_max_skew command excludes any input or output delay
constraints.
h For more information about the set_max_skew and report_max_skew commands—
including full syntax information, options, and example usage—refer to set_max_skew
report_max_skew in Quartus II Help.
Creating Timing Exceptions
Timing exceptions modify the default analysis performed by the TimeQuest analyzer.
You can create several different timing exceptions with the TimeQuest analyzer to
adjust the timing of your design.
Precedence
If a conflict of node names occurs between timing exceptions, the following order of
precedence applies:
1. False path
2. Minimum delays and maximum delays
3. Multicycle path
The false path timing exception has the highest precedence. Within each category,
assignments to individual nodes have precedence over assignments to clocks. Finally,
the remaining precedence for additional conflicts is order-dependent, such that the
assignments most recently created overwrite, or partially overwrite, earlier
assignments.
Quartus II Handbook Version 11.0 Volume 3: Verification
May 2011 Altera Corporation
Chapter 6: The Quartus II TimeQuest Timing Analyzer
Creating Timing Exceptions
6–39
False Paths
To specify false paths in your design, use the set_false_path command. False paths
are paths that can be ignored during timing analysis.
If you specify a false path between two timing notes, the false path applies only to the
path between the two nodes. If you specify a false path to a clock, the false path
applies to all paths where the source node (-from) or destination node (-to) is clocked
by the clock.
h For more information about the set_false_path command—including full syntax
information, options, and example usage—refer to set_false_path in Quartus II Help.
Minimum and Maximum Delays
To specify an absolute minimum or maximum delay for a path, use the
set_min_delay command or the set_max_delay commands, respectively.
If the source or destination node is clocked, the TimeQuest analyzer takes into account
the clock paths, allowing more or less delay on the data path. If the source or
destination node has an input or output delay, that delay is also included in the
minimum or maximum delay check.
If you specify a minimum or maximum delay between timing nodes, the delay
applies only to the path between the two nodes. If you specify a minimum or
maximum delay for a clock, the delay applies to all paths where the source node
(-from) or destination node (-to) is clocked by the clock.
You can create a minimum or maximum delay exception for an output port that does
not have an output delay constraint. You cannot report timing for the paths associated
with the output port; however, the TimeQuest analyzer reports any slack for the path
in the setup summary and hold summary reports. Because there is no clock associated
with the output port, no clock is reported for timing paths associated with the output
port.
1
To report timing with clock filters for output paths with minimum and maximum
delay constraints, you can set the output delay for the output port with a value of
zero. You can use an existing clock from the design or a virtual clock as the clock
reference.
h For more information about the set_min_delay and set_max_delay commands—
including full syntax information, options, and example usage—refer to set_min_delay
and set_max_delay in Quartus II Help.
Multicycle Path
By default, the TimeQuest analyzer uses a single-cycle analysis. When analyzing a
path, the setup launch and latch edge times are determined by finding the closest two
active edges in the respective waveforms. For a hold analysis, the timing 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 completely unrelated to the setup launch and latch edges.
May 2011
Altera Corporation
Quartus II Handbook Version 11.0 Volume 3: Verification
6–40
Chapter 6: The Quartus II TimeQuest Timing Analyzer
Timing Reports
A multicycle constraint adjusts setup or hold relationships by the specified number of
clock cycles based on the source (-start) or destination (-end) clock. An end
multicycle constraint of 2 extends the worst-case setup latch edge by one destination
clock period.
Hold multicycle constraints are based on the default hold position (the default value
is 0). An end hold multicycle constraint of 1 effectively subtracts one destination clock
period from the default hold latch edge.
When the objects are timing nodes, the multicycle constraint only applies to the path
between the two nodes. When an object is a clock, the multicycle constraint applies to
all paths where the source node (-from) or destination node (-to) is clocked by the
clock.
Table 6–8 shows the commands you can use to modify either the launch or latch edge
times that the TimeQuest analyzer uses to determine a setup relationship or hold
relationship.
Table 6–8. Commands to Modify Edge Times
Command
Description of Modification
set_multicycle_path -setup -end
Latch edge time of the setup relationship
set_multicycle_path -setup -start
Launch edge time of the setup relationship
set_multicycle_path -hold -end
Latch edge time of the hold relationship
set_multicycle_path -hold -start
Launch edge time of the hold relationship
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.
Delay Annotation
To modify the default delay values used during timing analysis, use the
set_annotated_delay and set_timing_derate commands. You must update the
timing netlist to see the results of these commands
To specify different operating conditions in a single .sdc, rather than having multiple
.sdc files that specify different operating conditions, use the set_annotated_delay
command with the -operating_conditions option.
h For more information about the set_annotated_delay and set_timing_derate
commands—including full syntax information, options, and example usage—refer to
set_annotated_delay and set_timing_derate in Quartus II Help.
Timing Reports
The TimeQuest analyzer provides real-time static timing analysis result reports. The
TimeQuest analyzer does not automatically generate reports; you must create each
report individually in the TimeQuest analyzer GUI or with command-line commands.
You can customize in which report to display specific timing information, excluding
fields that are not required.
Quartus II Handbook Version 11.0 Volume 3: Verification
May 2011 Altera Corporation
Chapter 6: The Quartus II TimeQuest Timing Analyzer
Timing Reports
6–41
Table 6–9 shows some of the different command-line commands you can use to
generate reports in the TimeQuest analyzer and the equivalent reports shown in the
TimeQuest analyzer GUI.
Table 6–9. TimeQuest Analyzer Reports
Command-Line Command
Report
report_timing
Timing report
report_exceptions
Exceptions report
report_clock_transfers
Clock Transfers report
report_min_pulse_width
Minimum Pulse Width report
report_ucp
Unconstrained Paths report
h For more information—including a complete list of commands to generate timing
reports and full syntax information, options, and example usage—refer to
::quartus::sta in Quartus II Help.
During compilation, the Quartus II software generates timing reports on different
timing areas in the design. You can configure various options for the TimeQuest
analyzer reports generated during compilation.
h For more information about the options you can set to customize the reports, refer to
TimeQuest Timing Analyzer Page in Quartus II Help.
You can also use the TIMEQUEST_REPORT_WORST_CASE_TIMING_PATHS assignment to
generate a report of the worst-case timing paths for each clock domain. This report
contains worst-case timing data for setup, hold, recovery, removal, and minimum
pulse width checks.
Use the TIMEQUEST_REPORT_NUM_WORST_CASE_TIMING_PATHS assignment to specify the
number of paths to report for each clock domain.
Example 6–18 shows an example of how to use the
TIMEQUEST_REPORT_WORST_CASE_TIMING_PATHS and
TIMEQUEST_REPORT_NUM_WORST_CASE_TIMING_PATHS assignments in the .qsf to
generate reports.
Example 6–18. Generating Worst-Case Timing Reports
#Enable Worst-Case Timing Report
set_global_assignment -name TIMEQUEST_REPORT_WORST_CASE_TIMING_PATHS ON
#Report 10 paths per clock domain
set_global_assignment -name TIMEQUEST_REPORT_NUM_WORST_CASE_TIMING_PATHS 10
f For more information about timing closure recommendations, refer to the Area and
Timing Optimization chapter in volume 2 of the Quartus II Handbook.
May 2011
Altera Corporation
Quartus II Handbook Version 11.0 Volume 3: Verification
6–42
Chapter 6: The Quartus II TimeQuest Timing Analyzer
Document Revision History
Document Revision History
Table 6–10 shows the revision history for this chapter.
Table 6–10. Document Revision History
Date
Version
May 2011
11.0.0
December 2010
10.1.0
July 2010
10.0.0
Changes
■
Updated to improve flow. Minor editorial updates.
■
Changed to new document template.
■
Revised and reorganized entire chapter.
■
Linked to Quartus II Help.
Updated to link to content on SDC commands and the TimeQuest analyzer GUI in Quartus II
Help.
Updated for the Quartus II software version 9.1, including:
November 2009
9.1.0
■
Added information about commands for adding and removing items from collections
■
Added information about the set_timing_derate and report_skew commands
■
Added information about worst-case timing reporting
■
Minor editorial updates
Updated for the Quartus II software version 8.1, including:
■
November 2008
8.1.0
Added the following sections:
■
“set_net_delay” on page 7–42
■
“Annotated Delay” on page 7–49
■
“report_net_delay” on page 7–66
■
Updated the descriptions of the -append and -file <name> options in tables
throughout the chapter
■
Updated entire chapter using 8½” × 11” chapter template
■
Minor editorial updates
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.
Quartus II Handbook Version 11.0 Volume 3: Verification
May 2011 Altera Corporation
7. Best Practices for the Quartus II
TimeQuest Timing Analyzer
December 2010
QII53024-10.1.0
QII53024-10.1.0
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
© 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
Subscribe
7–2
Chapter 7: Best Practices for the Quartus II TimeQuest Timing Analyzer
Creating Clock Requirements
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
Creating Clock Requirements
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.
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]
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
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
7–4
Chapter 7: Best Practices for the Quartus II TimeQuest Timing Analyzer
Creating Clock Requirements
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
clk_in
100 MHz
Example 7–5. Commands to Create Clocks
# 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 <delay_value>
# [get_ports data_in]
set_input_delay –clock virt_clk_in <delay value> [get_ports data_in]
Quartus II Handbook Version 11.0 Volume 3: Verification
December 2010 Altera Corporation
Chapter 7: Best Practices for the Quartus II TimeQuest Timing Analyzer
Creating I/O Requirements
7–5
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
External Device
Dreg1Q
Altera FPGA
data_out
data_in
Dreg1Q
clk_in
Virtual Clock
Base Clock
50 MHz
100 MHz
Example 7–6. Commands to Create Clocks
#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]
Creating I/O Requirements
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
7–6
Chapter 7: Best Practices for the Quartus II TimeQuest Timing Analyzer
Creating I/O Requirements
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
Altera Device
External Device
dd
tco_ext
cd_ext
Oscillator
cd_altr
Equation 7–1 shows a typical input delay calculation.
Equation 7–1. Input Delay Calculation
input delay MAX =  cd_ext MIN – cd_altr MAX  + tco_ext MAX + dd MAX
input delay MIN =  cd_extMAX – cd_altr MIN  + tco_ext MIN + dd MIN
Output Constraints
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.
Figure 7–4. Output Delay
Altera Device
External Device
dd
tsu_ext/th_ext
cd_ext
Oscillator
cd_altr
Quartus II Handbook Version 11.0 Volume 3: Verification
December 2010 Altera Corporation
Chapter 7: Best Practices for the Quartus II TimeQuest Timing Analyzer
Creating Timing Exceptions
7–7
Equation 7–2 shows a typical output delay calculation.
Equation 7–2. output Delay Calculation
input delay MAX = dd MAX – tsu_ext +  cd_altr MIN – cd_ext MAX 
input delay MIN = ddMIN – th_ext +  cd_altr MAX – cd_ext MIN 
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
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.
December 2010
Altera Corporation
Quartus II Handbook Version 11.0 Volume 3: Verification
7–8
Chapter 7: Best Practices for the Quartus II TimeQuest Timing Analyzer
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.
Creating Multicycle Exceptions
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.
Quartus II Handbook Version 11.0 Volume 3: Verification
December 2010 Altera Corporation
Chapter 7: Best Practices for the Quartus II TimeQuest Timing Analyzer
Creating Multicycle Exceptions
7–9
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
REG1
D
SET
Tclk1
Q
REG2
Combinational
Logic
D
SET
Q
Tdata
CLR
TCO
CLR
Tclk2
TSU / TH
CLK
December 2010
Altera Corporation
Quartus II Handbook Version 11.0 Volume 3: Verification
7–10
Chapter 7: Best Practices for the Quartus II TimeQuest Timing Analyzer
Creating Multicycle Exceptions
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.
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.
Table 7–1. Common Multicycle Assignments
Type
Clock
Timing Check
SDC Command
End Multicycle Setup
Destination
Setup
set_multicycle_path
–end –setup
End Multicycle Hold
Destination
Hold
set_multicycle_path
–end –hold
Start Multicycle Setup
Source
Setup
set_multicycle_path
–start –setup
Start Multicycle Hold
Source
Hold
set_multicycle_path
–start -hold
Multicycle Clock Setup
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.
Quartus II Handbook Version 11.0 Volume 3: Verification
December 2010 Altera Corporation
Chapter 7: Best Practices for the Quartus II TimeQuest Timing Analyzer
Creating Multicycle Exceptions
7–11
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 + t clk2 – t SU  –  launch edge + t clk1 + t CO + t data 
=
 latch edge – launch edge  +  t clk2 – t clk1  –  t CO + t data + t SU 
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.
Figure 7–6. End Multicycle Setup Values
-10
0
10
20
REG1.CLK
EMS = 1
(default)
EMS = 3
EMS = 2
REG2.CLK
December 2010
Altera Corporation
Quartus II Handbook Version 11.0 Volume 3: Verification
7–12
Chapter 7: Best Practices for the Quartus II TimeQuest Timing Analyzer
Creating Multicycle Exceptions
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.
Figure 7–7. Start Multicycle Setup Values
-20
-10
0
10
20
Source Clock
SMS = 2
SMS = 1
(default)
SMS = 3
Destination Clock
Figure 7–8 shows the setup relationship reported by the TimeQuest analyzer for the
negative setup relationship shown in Figure 7–7.
Figure 7–8. Start Multicycle Setup Values Reported by the TimeQuest Analyzer
-10
0
10
20
Source Clock
SMS = 1
(default)
SMS = 2
SMS = 3
Destination Clock
Multicycle Clock Hold
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
hold check 1 = current launch edge – previous latch edge
hold check 2 = next launch edge – current latch edge
Quartus II Handbook Version 11.0 Volume 3: Verification
December 2010 Altera Corporation
Chapter 7: Best Practices for the Quartus II TimeQuest Timing Analyzer
Creating Multicycle Exceptions
1
7–13
If a hold check overlaps a setup check, the hold check is ignored.
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 + t clk1 + t CO + t data  –  latch edge + t clk2 – t H 
=  launch edge – latch edge  –  t clk2 – t clk1  +  t CO + t data – t H 
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.
Figure 7–9. Start Multicycle Hold Values
-10
0
10
20
Source Clock
SMH = 0
(default)
SMH = 1
SMH = 1
Destination Clock
December 2010
Altera Corporation
Quartus II Handbook Version 11.0 Volume 3: Verification
7–14
Chapter 7: Best Practices for the Quartus II TimeQuest Timing Analyzer
Creating Multicycle Exceptions
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.
Figure 7–10. End Multicycle Hold Values
-20
-10
0
10
20
EMH = 2
Source Clock
EMH= 0
(default)
EMH = 1
Destination Clock
Figure 7–11 shows the hold relationship reported by the TimeQuest analyzer for the
negative hold relationship shown in Figure 7–10.
Figure 7–11. End Multicycle Hold Values Reported by the TimeQuest Analyzer
-10
0
10
20
Source Clock
EMH = 0
default)
EMH = 2
EMH = 1
Destination Clock
Examples of Basic Multicycle Exceptions
This section describes the following examples of combinations of multicycle
exceptions:
■
“Default Settings” on page 7–15
■
“End Multicycle Setup = 2 and End Multicycle Hold = 0” on page 7–17
■
“End Multicycle Setup = 1 and End Multicycle Hold = 1” on page 7–20
■
“End Multicycle Setup = 2 and End Multicycle Hold = 1” on page 7–23
■
“Start Multicycle Setup = 2 and Start Multicycle Hold = 0” on page 7–26
■
“Start Multicycle Setup = 1 and Start Multicycle Hold = 1” on page 7–29
■
“Start Multicycle Setup = 2 and Start Multicycle Hold = 1” on page 7–32
Quartus II Handbook Version 11.0 Volume 3: Verification
December 2010 Altera Corporation
Chapter 7: Best Practices for the Quartus II TimeQuest Timing Analyzer
Creating Multicycle Exceptions
7–15
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
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.
Figure 7–12. Default Timing Diagram
-10
0
10
20
Current Launch
REG1.CLK
HC1
REG2.CLK
0
SC
HC2
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.
December 2010
Altera Corporation
Quartus II Handbook Version 11.0 Volume 3: Verification
7–16
Chapter 7: Best Practices for the Quartus II TimeQuest Timing Analyzer
Creating Multicycle Exceptions
Figure 7–13 shows the setup report for the default setup in the TimeQuest analyzer
with the launch and latch edges highlighted.
Figure 7–13. Setup Report
Equation 7–7 shows the calculation that the TimeQuest analyzer performs to
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.
Quartus II Handbook Version 11.0 Volume 3: Verification
December 2010 Altera Corporation
Chapter 7: Best Practices for the Quartus II TimeQuest Timing Analyzer
Creating Multicycle Exceptions
7–17
Figure 7–14 shows the hold report for the default setup in the TimeQuest analyzer
with the launch and latch edges highlighted.
Figure 7–14. Hold Report
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.
December 2010
Altera Corporation
Quartus II Handbook Version 11.0 Volume 3: Verification
7–18
Chapter 7: Best Practices for the Quartus II TimeQuest Timing Analyzer
Creating Multicycle Exceptions
Figure 7–15 shows the setup timing diagram. The latch edge is a clock cycle later than
in the default single-cycle analysis.
Figure 7–15. Setup Timing Diagram
-10
0
10
20
Current Launch
REG1.CLK
SC
REG2.CLK
Current Latch
Equation 7–8 shows the calculation that the TimeQuest analyzer performs to
determine the setup check.
Equation 7–8. Setup Check
setup check =
current latch edge – closest previous launch edge
= 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.
Figure 7–16. Setup Report
Quartus II Handbook Version 11.0 Volume 3: Verification
December 2010 Altera Corporation
Chapter 7: Best Practices for the Quartus II TimeQuest Timing Analyzer
Creating Multicycle Exceptions
7–19
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.
Figure 7–17. Hold Timing DIagram
-10
0
10
20
Current Launch
REG1.CLK
Data
HC1
SC
HC2
REG2.CLK
Current Latch
Equation 7–9 shows the calculation that the TimeQuest analyzer performs to
determine the hold check. Both hold checks are equivalent.
Equation 7–9. Hold Check
hold check 1 =
current launch edge – previous latch edge
= 0 ns – 10 ns
= – 10 ns
hold check 2 =
next launch edge – current latch edge
= 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.
December 2010
Altera Corporation
Quartus II Handbook Version 11.0 Volume 3: Verification
7–20
Chapter 7: Best Practices for the Quartus II TimeQuest Timing Analyzer
Creating Multicycle Exceptions
Figure 7–18 shows the hold report for this example in the TimeQuest analyzer with
the launch and latch edges highlighted.
Figure 7–18. Hold Report
End Multicycle Setup = 1 and End Multicycle Hold = 1
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
exceptions applied to the register-to-register design for this example.
Example 7–10. Multicycle Exceptions
set_multicycle_path -from [get_clocks clk_src] -to [get_clocks clk_\
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.
Quartus II Handbook Version 11.0 Volume 3: Verification
December 2010 Altera Corporation
Chapter 7: Best Practices for the Quartus II TimeQuest Timing Analyzer
Creating Multicycle Exceptions
7–21
Figure 7–19 shows the setup timing diagram. The latch edge is the same as the default
single-cycle analysis.
Figure 7–19. Setup Timing Diagram
-10
0
Current
Launch
10
20
SRC.CLK
HC1
SC HC2
DST.CLK
Current
Latch
Equation 7–10 shows the calculation that the TimeQuest analyzer performs to
determine the setup check.
Equation 7–10. Setup Check
setup check =
current latch edge – closest previous launch edge
= 10 ns – 0 ns
= 10 ns
The most restrictive setup relationship with an end multicycle setup assignment of
one is 10 ns.
December 2010
Altera Corporation
Quartus II Handbook Version 11.0 Volume 3: Verification
7–22
Chapter 7: Best Practices for the Quartus II TimeQuest Timing Analyzer
Creating Multicycle Exceptions
Figure 7–20 shows the setup report in the TimeQuest analyzer with the launch and
latch edges highlighted.
Figure 7–20. Setup Report
Figure 7–21 shows the timing diagram for the hold checks for this example. The hold
checks are relative to the setup check.
Figure 7–21. Hold Timing Diagram
-10
0
Current
Launch
10
20
SRC.CLK
HC1
SC HC2
DST.CLK
Current
Latch
Quartus II Handbook Version 11.0 Volume 3: Verification
December 2010 Altera Corporation
Chapter 7: Best Practices for the Quartus II TimeQuest Timing Analyzer
Creating Multicycle Exceptions
7–23
Equation 7–11 shows the calculation that the TimeQuest analyzer performs to
determine the hold check. Both hold checks are equivalent.
Equation 7–11. Hold Check
hold check 1 =
current launch edge – previous latch edge
= 0 ns –  – 10 ns 
= 10 ns
hold check 2 =
next launch edge – current latch edge
= 10 ns – 0 ns
= 10 ns
The most restrictive hold relationship with an end multicycle setup assignment value
of one and an end multicycle hold assignment value of one is 10 ns.
Figure 7–22 shows the hold report for this example in the TimeQuest analyzer with
the launch and latch edges highlighted.
Figure 7–22. Hold Report
End Multicycle Setup = 2 and End Multicycle Hold = 1
In this example, the end multicycle setup assignment value is two, and the end
multicycle hold assignment value is one. Example 7–11 shows the multicycle
exceptions applied to the register-to-register design for this example.
Example 7–11. Multicycle Exceptions
set_multicycle_path -from [get_clocks clk_src] -to [get_clocks clk_dst]
-setup -end 2
set_multicycle_path -from [get_clocks clk_src] -to [get_clocks clk_dst]
-hold -end 1
December 2010
Altera Corporation
Quartus II Handbook Version 11.0 Volume 3: Verification
7–24
Chapter 7: Best Practices for the Quartus II TimeQuest Timing Analyzer
Creating Multicycle Exceptions
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.
Figure 7–23. Setup Timing Diagram
-10
0
Current
Launch
10
20
SRC.CLK
SC
0
DST.CLK
1
2
Current
Latch
Equation 7–12 shows the calculation that the TimeQuest analyzer performs to
determine the setup check.
Equation 7–12. Setup Check
setup check =
current latch edge – closest previous launch edge
= 20 ns – 0 ns
= 20 ns
The most restrictive hold relationship with an end multicycle setup assignment value
of two is 20 ns.
Quartus II Handbook Version 11.0 Volume 3: Verification
December 2010 Altera Corporation
Chapter 7: Best Practices for the Quartus II TimeQuest Timing Analyzer
Creating Multicycle Exceptions
7–25
Figure 7–24 shows the setup report for this example in the TimeQuest analyzer with
the launch and latch edges highlighted.
Figure 7–24. Setup Report
Figure 7–25 shows the timing diagram for the hold checks for this example. The hold
checks are relative to the setup check.
Figure 7–25. Hold Timing Diagram
-10
0
Current
Launch
10
20
SRC.CLK
SC
HC1
HC2
DST.CLK
Current
Latch
December 2010
Altera Corporation
Quartus II Handbook Version 11.0 Volume 3: Verification
7–26
Chapter 7: Best Practices for the Quartus II TimeQuest Timing Analyzer
Creating Multicycle Exceptions
Equation 7–13 shows the calculation that the TimeQuest analyzer performs to
determine the hold check. Both hold checks are equivalent.
Equation 7–13. Hold Check
hold check 1 =
current launch edge – previous latch edge
= 0 ns – 0 ns
= 0 ns
hold check 2 =
next launch edge – current latch edge
= 10 ns – 10 ns
= 0 ns
The most restrictive hold relationship with an end multicycle setup assignment value
of two and an end multicycle hold assignment value of one is 0 ns.
Figure 7–26 shows the hold report for this example in the TimeQuest analyzer with
the launch and latch edges highlighted.
Figure 7–26. Hold Report
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
exceptions applied to the register-to-register design for this example.
Example 7–12. Multicycle Exceptions
set_multicycle_path -from [get_clocks clk_src] -to [get_clocks clk_\
dst] -setup -start 2
1
A start multicycle hold value is not required because the default start multicycle hold
value is zero.
Quartus II Handbook Version 11.0 Volume 3: Verification
December 2010 Altera Corporation
Chapter 7: Best Practices for the Quartus II TimeQuest Timing Analyzer
Creating Multicycle Exceptions
7–27
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.
Figure 7–27 shows the setup timing diagram.
Figure 7–27. Setup TIming Diagram
-10
Current
Launch
0
2
REG1.CLK
10
1
20
0
SC
REG2.CLK
Current
Latch
Equation 7–14 shows the calculation that the TimeQuest analyzer performs to
determine the setup check.
Equation 7–14. Setup Check
setup check =
current latch edge – closest previous launch edge
= 10 ns –  – 10 ns 
= 20 ns
The most restrictive hold relationship with a start multicycle setup assignment value
of two is 20 ns.
December 2010
Altera Corporation
Quartus II Handbook Version 11.0 Volume 3: Verification
7–28
Chapter 7: Best Practices for the Quartus II TimeQuest Timing Analyzer
Creating Multicycle Exceptions
Figure 7–28 shows the setup report for this example in the TimeQuest analyzer with
the launch and latch edges highlighted.
Figure 7–28. Setup Report
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.
Figure 7–29. Hold TIming Diagram
-10
Current
Launch
0
10
20
REG1.CLK
HC1
SC
HC2
REG2.CLK
Current
Latch
Quartus II Handbook Version 11.0 Volume 3: Verification
December 2010 Altera Corporation
Chapter 7: Best Practices for the Quartus II TimeQuest Timing Analyzer
Creating Multicycle Exceptions
7–29
Equation 7–15 shows the calculation that the TimeQuest analyzer performs to
determine the hold check. Both hold checks are equivalent.
Equation 7–15. Hold Check
hold check 1 =
current launch edge – previous latch edge
= 0 ns – 10 ns
= – 10 ns
hold check 2 =
next launch edge – current latch edge
= 10 ns – 0 ns
= 10 ns
The most restrictive hold relationship with a start multicycle setup assignment value
of two and a start multicycle hold assignment value of zero is 10 ns.
Figure 7–30 shows the hold report for this example in the TimeQuest analyzer with
the launch and latch edges highlighted.
Figure 7–30. Hold Report
Start Multicycle Setup = 1 and Start Multicycle Hold = 1
In this example, the start multicycle setup assignment value is one, and the start
multicycle hold assignment value is one. Example 7–13 shows the multicycle
exceptions applied to the register-to-register design for this example.
Example 7–13. Multicycle Exceptions
set_multicycle_path -from [get_clocks clk_src] -to [get_clocks clk_\
dst] -hold -start 1
1
December 2010
A start multicycle setup value is not required, because the default start multicycle
hold value is one.
Altera Corporation
Quartus II Handbook Version 11.0 Volume 3: Verification
7–30
Chapter 7: Best Practices for the Quartus II TimeQuest Timing Analyzer
Creating Multicycle Exceptions
In this example, the hold relationship is relaxed by one clock period by moving the
launch edge to the left.
Figure 7–31 shows the setup timing diagram.
Figure 7–31. Setup Timing Diagram
-10
REG1.CLK
0
Current
Launch
2
10
1
20
0
SC
REG2.CLK
Current
Latch
Equation 7–16 shows the calculation that the TimeQuest analyzer performs to
determine the setup check.
Equation 7–16. Setup Check
setup check =
current latch edge – closest previous launch edge
= 10 ns – 0 ns
= 10 ns
The most restrictive setup relationship with a start multicycle setup assignment of one
is 10 ns.
Figure 7–32 shows the setup report in the TimeQuest analyzer with the launch and
latch edges highlighted.
Figure 7–32. Setup Report
Quartus II Handbook Version 11.0 Volume 3: Verification
December 2010 Altera Corporation
Chapter 7: Best Practices for the Quartus II TimeQuest Timing Analyzer
Creating Multicycle Exceptions
7–31
Figure 7–33 shows the timing diagram for the hold checks for this example. The hold
checks are relative to the setup check.
Figure 7–33. Hold Timing Diagram
-10
Current
Launch
0
10
20
REG1.CLK
HC1
SC
HC2
REG2.CLK
Current
Latch
Equation 7–17 shows the calculation that the TimeQuest analyzer performs to
determine the hold check. Both hold checks are equivalent.
Equation 7–17. Hold Check
hold check 1 =
current launch edge – previous latch edge
= 10 ns – 0 ns
= 10 ns
hold check 2 =
next launch edge – current latch edge
= 20 ns – 10 ns
= 10 ns
The most restrictive hold relationship with a start multicycle setup assignment value
of one and a start multicycle hold assignment value of one is 10 ns.
December 2010
Altera Corporation
Quartus II Handbook Version 11.0 Volume 3: Verification
7–32
Chapter 7: Best Practices for the Quartus II TimeQuest Timing Analyzer
Creating Multicycle Exceptions
Figure 7–34 shows the hold report for this example in the TimeQuest analyzer with
the launch and latch edges highlighted.
Figure 7–34. Hold Report
Start Multicycle Setup = 2 and Start Multicycle Hold = 1
In this example, the start multicycle setup assignment value is two, and the start
multicycle hold assignment value is one. Example 7–14 shows the multicycle
exceptions applied to the register-to-register design for this example.
Example 7–14. Multicycle Exceptions
set_multicycle_path -from [get_clocks clk_src] -to [get_clocks clk_dst]
-setup -start 2
set_multicycle_path -from [get_clocks clk_src] -to [get_clocks clk_dst]
-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.
Figure 7–35 shows the setup timing diagram.
Figure 7–35. Setup Timing Diagram
-10
SRC.CLK
0
2
Data
10
1
SC
(
(default)
20
0
SC
DST.CLK
Quartus II Handbook Version 11.0 Volume 3: Verification
December 2010 Altera Corporation
Chapter 7: Best Practices for the Quartus II TimeQuest Timing Analyzer
Creating Multicycle Exceptions
7–33
Equation 7–18 shows the calculation that the TimeQuest analyzer performs to
determine the setup check.
Equation 7–18. Setup Check
setup check =
current latch edge – closest previous launch edge
= 10 ns –  – 10 ns 
= 20 ns
The most restrictive hold relationship with a start multicycle setup assignment value
of two is 20 ns.
Figure 7–36 shows the setup report for this example in the TimeQuest analyzer with
the launch and latch edges highlighted.
Figure 7–36. Setup Report
Figure 7–37 shows the timing diagram for the hold checks for this example. The hold
checks are relative to the setup check.
Figure 7–37. Hold Timing Diagram
-10
0
Current
Launch
10
20
SRC.CLK
HC1
SC
HC2
DST.CLK
Current
Latch
December 2010
Altera Corporation
Quartus II Handbook Version 11.0 Volume 3: Verification
7–34
Chapter 7: Best Practices for the Quartus II TimeQuest Timing Analyzer
Creating Multicycle Exceptions
Equation 7–19 shows the calculation that the TimeQuest analyzer performs to
determine the hold check. Both hold checks are equivalent.
Equation 7–19. Hold Check
hold check 1 =
current launch edge – previous latch edge
= 0 ns – 0 ns
= 0 ns
hold check 2 =
next launch edge – current latch edge
= 10 ns – 10 ns
= 0 ns
The most restrictive hold relationship with a start multicycle setup assignment value
of two and a start multicycle hold assignment value of one is 0 ns.
Figure 7–38 shows the hold report for this example in the TimeQuest analyzer with
the launch and latch edges highlighted.
Figure 7–38. Hold Report
Quartus II Handbook Version 11.0 Volume 3: Verification
December 2010 Altera Corporation
Chapter 7: Best Practices for the Quartus II TimeQuest Timing Analyzer
Creating Multicycle Exceptions
7–35
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
REG1
In
D
clk0
SET
REG2
Combinational
Logic
Q
D
CLR
SET
Out
Q
CLR
clk1
Figure 7–40 shows the timing diagram for default setup check analysis performed by
the TimeQuest analyzer.
Figure 7–40. Setup Timing Diagram
-10
0
Launch
10
20
REG1.CLK
SC
REG2.CLK
1
2
Latch
December 2010
Altera Corporation
Quartus II Handbook Version 11.0 Volume 3: Verification
7–36
Chapter 7: Best Practices for the Quartus II TimeQuest Timing Analyzer
Creating Multicycle Exceptions
Equation 7–20 shows the calculation that the TimeQuest analyzer performs to
determine the setup check.
Equation 7–20. Setup Check
setup check =
current latch edge – closest previous launch edge
= 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.
Example 7–15. Multicycle Exceptions
set_multicycle_path -from [get_clocks clk_src] -to [get_clocks clk_dst]
-setup -end 2
Figure 7–41 shows the timing diagram for the preferred setup relationship for this
example.
.
Figure 7–41. Preferred Setup Relationship
-10
0
Launch
10
20
REG1.CLK
SC
1
REG2.CLK
2
Latch
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
-10
0
Current
Launch
10
20
REG1.CLK
HC1
SC
HC2
REG2.CLK
Current
Latch
Quartus II Handbook Version 11.0 Volume 3: Verification
December 2010 Altera Corporation
Chapter 7: Best Practices for the Quartus II TimeQuest Timing Analyzer
Creating Multicycle Exceptions
7–37
Equation 7–21 shows the calculation that the TimeQuest analyzer performs to
determine the hold check.
Equation 7–21. Hold Check
hold check 1 =
current launch edge – previous latch edge
= 0 ns – 2 ns
= – 2 ns
hold check 2 =
next launch edge – current latch edge
= 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
-10
0
Current
Launch
10
20
REG1.CLK
HC1
SC
HC2
REG2.CLK
Current
Latch
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
REG1
In
D
SET
Q
REG2
Combinational
Logic
D
SET
Q
Out
clk0
CLR
clk
CLR
clk1
December 2010
Altera Corporation
Quartus II Handbook Version 11.0 Volume 3: Verification
7–38
Chapter 7: Best Practices for the Quartus II TimeQuest Timing Analyzer
Creating Multicycle Exceptions
Figure 7–45 shows the timing diagram for default setup check analysis performed by
the TimeQuest analyzer.
Figure 7–45. Setup Timing Diagram
-10
0
10
20
Launch
REG1.CLK
SC
1
REG2.CLK
2
Latch
Equation 7–22 shows the calculation that the TimeQuest analyzer performs to
determine the setup check.
Equation 7–22. Setup Check
setup check =
current latch edge – closest previous launch edge
= 5 ns – 0 ns
= 5 ns
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.
Example 7–16. Multicycle Exceptions
set_multicycle_path -from [get_clocks clk_src] -to [get_clocks clk_dst]
-setup -end 2
Quartus II Handbook Version 11.0 Volume 3: Verification
December 2010 Altera Corporation
Chapter 7: Best Practices for the Quartus II TimeQuest Timing Analyzer
Creating Multicycle Exceptions
7–39
Figure 7–46 shows the timing diagram for the preferred setup relationship for this
example.
Figure 7–46. Preferred Setup Analysis
-10
0
10
20
Launch
REG1.CLK
SC
1
REG2.CLK
2
Latch
Figure 7–47 shows the timing diagram for default hold check analysis performed by
the TimeQuest analyzer with an end multicycle setup value of two.
Figure 7–47. Default Hold Check
-10
0
Current
Launch
10
20
REG1.CLK
SC
HC1
HC2
REG2.CLK
Current
Latch
Equation 7–23 shows the calculation that the TimeQuest analyzer performs to
determine the hold check.
Equation 7–23. Hold Check
hold check 1 =
current launch edge – previous latch edge
= 0 ns – 5 ns
= – 5 ns
hold check 2 =
next launch edge – current latch edge
= 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 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.
December 2010
Altera Corporation
Quartus II Handbook Version 11.0 Volume 3: Verification
7–40
Chapter 7: Best Practices for the Quartus II TimeQuest Timing Analyzer
Creating Multicycle Exceptions
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
REG1
In
D
SET
REG2
Combinational
Logic
Q
D
SET
Out
Q
clk0
CLR
clk
CLR
clk1
Figure 7–49 shows the timing diagram for default setup check analysis performed by
the TimeQuest analyzer.
Figure 7–49. Setup Timing Diagram
-10
0
10
20
Launch
REG1.CLK
SC
1
REG2.CLK
2
3
Latch
Equation 7–24 shows the calculation that the TimeQuest analyzer performs to
determine the setup check.
.
Equation 7–24. Setup Check
setup check =
current latch edge – closest previous launch edge
= 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.
Quartus II Handbook Version 11.0 Volume 3: Verification
December 2010 Altera Corporation
Chapter 7: Best Practices for the Quartus II TimeQuest Timing Analyzer
Creating Multicycle Exceptions
7–41
Example 7–17 shows the multicycle exception used to correct the default analysis in
this example.
Example 7–17. Multicycle Exceptions
set_multicycle_path -from [get_clocks clk_src] -to [get_clocks clk_dst]
-setup -end 3
Figure 7–50 shows the timing diagram for the preferred setup relationship for this
example.
Figure 7–50. Preferred Setup Analysis
-10
0
10
20
Launch
REG1.CLK
SC
1
REG2.CLK
2
3
Latch
Figure 7–51 shows the timing diagram for default hold check analysis performed by
the TimeQuest analyzer with an end multicycle setup value of three.
Figure 7–51. Default Hold Check
-10
0
Current
Launch
10
20
REG1.CLK
SC
HC2
HC1
REG2.CLK
Current
Latch
December 2010
Altera Corporation
Quartus II Handbook Version 11.0 Volume 3: Verification
7–42
Chapter 7: Best Practices for the Quartus II TimeQuest Timing Analyzer
Creating Multicycle Exceptions
Equation 7–25 shows the calculation that the TimeQuest analyzer performs to
determine the hold check.
Equation 7–25. Hold Check
hold check 1 =
current launch edge – previous latch edge
= 0 ns – 5 ns
= – 5 ns
hold check 2 =
next launch edge – current latch edge
= 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
REG1
In
D
SET
Q
REG2
Combinational
Logic
D
SET
Q
Out
clk0
CLR
clk
CLR
clk1
Quartus II Handbook Version 11.0 Volume 3: Verification
December 2010 Altera Corporation
Chapter 7: Best Practices for the Quartus II TimeQuest Timing Analyzer
Creating Multicycle Exceptions
7–43
Figure 7–53 shows the timing diagram for default setup check analysis performed by
the TimeQuest analyzer.
Figure 7–53. Default Setup Check Analysis
-10
0
10
20
Launch
REG1.CLK
2
1
SC
REG2.CLK
Latch
Equation 7–26 shows the calculation that the TimeQuest analyzer performs to
determine the setup check.
Equation 7–26. Setup Check
setup check =
current latch edge – closest previous launch edge
= 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.
Example 7–18 shows the multicycle exception used to correct the default analysis in
this example.
Example 7–18. Multicycle Exceptions
set_multicycle_path -from [get_clocks clk_src] -to [get_clocks clk_dst]
-setup -start 2
December 2010
Altera Corporation
Quartus II Handbook Version 11.0 Volume 3: Verification
7–44
Chapter 7: Best Practices for the Quartus II TimeQuest Timing Analyzer
Creating Multicycle Exceptions
Figure 7–54 shows the timing diagram for the preferred setup relationship for this
example.
Figure 7–54. Preferred Setup Check Analysis
-10
0
10
20
Launch
2
REG1.CLK
1
SC
REG2.CLK
Latch
Figure 7–55 shows the timing diagram for default hold check analysis performed by
the TimeQuest analyzer with a start multicycle setup value of two.
Figure 7–55. Default Hold Check
-10
0
Current
Launch
10
20
REG1.CLK
HC1
SC
HC2
REG2.CLK
Current
Latch
Equation 7–27 shows the calculation that the TimeQuest analyzer performs to
determine the hold check.
.
Equation 7–27. Hold Check
hold check 1 =
current launch edge – previous latch edge
= 0 ns – 0 ns
= 0 ns
hold check 2 =
next launch edge – current latch edge
= 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.
Quartus II Handbook Version 11.0 Volume 3: Verification
December 2010 Altera Corporation
Chapter 7: Best Practices for the Quartus II TimeQuest Timing Analyzer
Creating Multicycle Exceptions
7–45
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
REG1
In
D
SET
REG2
Combinational
Logic
Q
D
SET
Q
Out
clk0
CLR
clk
CLR
clk1
Figure 7–57 shows the timing diagram for default setup check analysis performed by
the TimeQuest analyzer.
Figure 7–57. Setup Timing Diagram
-10
0
10
20
Launch
REG1.CLK
3
2
1
C
REG2.CLK
Latch
Equation 7–28 shows the calculation that the TimeQuest analyzer performs to
determine the setup check.
.
Equation 7–28. setup Check
setup check =
current latch edge – closest previous launch edge
= 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.
December 2010
Altera Corporation
Quartus II Handbook Version 11.0 Volume 3: Verification
7–46
Chapter 7: Best Practices for the Quartus II TimeQuest Timing Analyzer
Creating Multicycle Exceptions
Example 7–19 shows the multicycle exception used to correct the default analysis in
this example.
Example 7–19. Multicycle Exceptions
set_multicycle_path -from [get_clocks clk_src] -to [get_clocks clk_dst]
-setup -start 3
Figure 7–58 shows the timing diagram for the preferred setup relationship for this
example.
Figure 7–58. Preferred Setup Check Analysis
-10
0
10
20
Launch
3
REG1.CLK
2
1
SC
REG2.CLK
Latch
Figure 7–59 shows the timing diagram for default hold check analysis performed by
the TimeQuest analyzer with a start multicycle setup value of three.
Figure 7–59. Default Hold Check Analysis
-10
0
Current
Launch
10
20
REG1.CLK
HC2
HC1
SC
REG2.CLK
Current
Latch
Quartus II Handbook Version 11.0 Volume 3: Verification
December 2010 Altera Corporation
Chapter 7: Best Practices for the Quartus II TimeQuest Timing Analyzer
Document Revision History
7–47
Equation 7–29 shows the calculation that the TimeQuest analyzer performs to
determine the hold check.
Equation 7–29. Hold Check
hold check 1 =
current launch edge – previous latch edge
= 0 ns – 2 ns
= – 2 ns
hold check 2 =
next launch edge – current latch edge
= 5 ns – 12 ns
= – 7 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.
Document Revision History
Table 7–2 shows the revision history for this chapter.
Table 7–2. Document Revision History
Date
Version
December 2010
10.1.0
July 2010
10.0.0
November 2009
9.1.0
March 2009
9.0.0
Changes
■
Changed to new document template.
■
Edited document and linked to other resources.
■
Added information that previously appeared in Application Note 481: Applying Multicycle
Exceptions in the TimeQuest Timing Analyzer.
Minor editorial changes to document. No updates to technical content.
■
Added example to “Derived Clocks” on page 7–3.
■
Updated “Base Clocks” on page 7–2.
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.
December 2010
Altera Corporation
Quartus II Handbook Version 11.0 Volume 3: Verification
7–48
Quartus II Handbook Version 11.0 Volume 3: Verification
Chapter 7: Best Practices for the Quartus II TimeQuest Timing Analyzer
Document Revision History
December 2010 Altera Corporation
8. Switching to the Quartus II TimeQuest
Timing Analyzer
December 2010
QII53019-10.1.0
QII53019-10.1.0
This chapter describes the benefits of switching to the Quartus® II TimeQuest Timing
Analyzer, the differences between the TimeQuest analyzer and the Classic Timing
Analyzer, and the process you should follow to switch a design from using the Classic
Timing Analyzer to the TimeQuest analyzer.
Benefits of Switching to the TimeQuest Analyzer
Increasing design complexity requires a timing analysis tool with greater capabilities
and flexibility. The TimeQuest analyzer offers the following benefits:
■
Industry-standard Synopsys Design Constraint (SDC) support increases
productivity.
■
Simple, flexible reporting uses industry-standard terminology and makes timing
sign-off faster.
These features ease constraint and analysis of modern, complex designs. SDC
constraints support complex clocking schemes and high-speed interfaces. An example
includes designs that have multiplexed clocks, regardless of whether they are
switched on or off chip. Designs with source-synchronous interfaces, such as double
data rate (DDR) memory interfaces, are much simpler to constrain and analyze with
the TimeQuest analyzer.
There are three main differences between the Classic Timing Analyzer and the
TimeQuest analyzer. Unlike the Classic Timing Analyzer, the TimeQuest analyzer has
the following benefits:
■
All clocks are related by default.
■
The default hold multicycle value is zero.
■
You must constrain all ports and ripple clocks.
This chapter contains the following sections:
■
“Switching Your Design” on page 8–2
■
“Differences Between the Quartus II Timing Analyzers” on page 8–3
■
“Timing Assignment Conversion” on page 8–24
■
“Conversion Utility” on page 8–43
■
“Notes” on page 8–53
© 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
Subscribe
8–2
Chapter 8: Switching to the Quartus II TimeQuest Timing Analyzer
Switching Your Design
Switching Your Design
To switch a design from the Classic Timing Analyzer to the TimeQuest analyzer,
perform the steps:
1. Open your compiled design in the Quartus II software.
2. Create a Synopsys Design Constraints File (.sdc) that contains timing constraints.
3. Perform timing analysis with the TimeQuest analyzer and examine the reports.
Open Your Compiled Design
To begin, open a design you previously compiled with the Quartus II software.
Create an SDC Constraints
Create SDC Constraints Manually
If you are familiar with SDC commands and syntax, you can create an .sdc with any
text editor and skip to “Start the TimeQuest Analyzer” on page 8–3. Name the .sdc
<revision>.sdc,where <revision> is the current revision of your project, and save it in
your project directory.
f For more information about TimeQuest analyzer SDC constraints, refer to the
Quartus II TimeQuest Timing Analyzer chapter in volume 3 of the Quartus II Handbook.
Create SDC Constraints from Existing Timing Assignments
You can use the TimeQuest analyzer conversion utility to help you convert the timing
assignments in an existing Quartus II Settings File (.qsf) to corresponding SDC
constraints.To run the TimeQuest analyzer conversion utility, on the Constraints
menu, click Generate SDC File from QSF. You can also run the conversion utility by
typing the following command at a system command prompt:
quartus_sta --qsf2sdc <project name> r
The .sdc created by the conversion utility is named <revision>.sdc.
After conversion, review the .sdc to ensure it is correct and complete, and make
changes if necessary. Refer to “Constraint File Priority” on page 8–7 for
recommendations.
The conversion utility cannot convert some types of Classic Timing Analyzer
assignments if no corresponding SDC constraint exist, or if there is more than one
potentially equivalent SDC constraint. If the conversion utility cannot convert your
assignment, manually convert any ambiguous assignments. Correct conversion
requires knowledge of the intended function of your design. To convert your
assignments, use the guidelines in “Timing Assignment Conversion” on page 8–24.
Quartus II Handbook Version 11.0 Volume 3: Verification
December 2010 Altera Corporation
Chapter 8: Switching to the Quartus II TimeQuest Timing Analyzer
Differences Between the Quartus II Timing Analyzers
8–3
Start the TimeQuest Analyzer
To open the TimeQuest analyzer GUI, on the Tools menu, click TimeQuest Timing
Analyzer. The TimeQuest GUI automatically opens the project open in the Quartus II
software GUI.
To open the TimeQuest analyzer GUI from a system command prompt, type the
following command:
quartus_staw r
To start the TimeQuest analyzer Tcl shell type the following command:
quartus_sta -s r
Differences Between the Quartus II Timing Analyzers
The differences between the TimeQuest analyzer and the Classic Timing Analyzer are
described in the following sections:
■
“Terminology” on page 8–3
■
“Constraints” on page 8–5
■
“Clocks” on page 8–10
■
“Hold Multicycle” on page 8–18
■
“Fitter Performance and Behavior” on page 8–19
■
“Reporting” on page 8–20
■
“Timing Assignment Conversion” on page 8–24
Terminology
This section introduces the industry-standard SDC terminology used by the
TimeQuest analyzer.
Netlists
The TimeQuest analyzer uses SDC naming conventions for netlists. Netlists consist of
cells, pins, nets, ports, and clocks.
1
December 2010
■
Cells are instances of fundamental hardware elements in Altera® FPGAs, such as
logic elements, look-up tables (LUTs), and registers.
■
Pins are inputs and outputs of cells.
■
Nets are connections between output pins and input pins.
■
Ports are top-level module inputs and outputs (device inputs and outputs).
■
Clocks are abstract objects outside the netlist.
The terminology of pins and ports is opposite to that of the Classic Timing Analyzer.
In the Classic Timing Analyzer, ports are inputs and outputs of cells, and pins are
top-level module inputs and outputs (device inputs and outputs).
Altera Corporation
Quartus II Handbook Version 11.0 Volume 3: Verification
8–4
Chapter 8: Switching to the Quartus II TimeQuest Timing Analyzer
Differences Between the Quartus II Timing Analyzers
Figure 8–1 shows a sample design, and Figure 8–2 shows the TimeQuest analyzer
netlist representation of the design. Netlist elements in Figure 8–2 are labeled to
illustrate the SDC terminology.
Figure 8–1. Sample Design
ina
inrega
outreg
ab
inb
out
inregb
clk
Figure 8–2. TimeQuest Analyzer Netlist
cell=atom/wysiwyg
pin = iterm
ina
pin = oterm
combout
datain
inrega
combout
regout
clk
ab
port = I/O
outreg
out
inb
inregb
datain
inclk[0]
clk
clk~clkctrl
Sample Pin Names:
ina|combout
inrega|datain
inrega|clk
inrega|regout
ab|combout
ab|datac
Sample Net Names:
ina~combout
ab
clk~clkctrl
inrega
Collections
In addition to standard SDC collections, the TimeQuest analyzer supports the
following Altera-specific collection types:
■
Keepers—Noncombinational nodes in a netlist
■
Nodes—Nodes can be combinational, registers, latches, or ports (device inputs
and outputs)
■
Registers—Registers or latches in the netlist
You can use the get_keepers, get_nodes, or get_registers commands to access these
collections.
f For more information about TimeQuest analyzer terminology, refer to the Quartus II
TimeQuest Timing Analyzer chapter in volume 3 of the Quartus II Handbook.
Quartus II Handbook Version 11.0 Volume 3: Verification
December 2010 Altera Corporation
Chapter 8: Switching to the Quartus II TimeQuest Timing Analyzer
Differences Between the Quartus II Timing Analyzers
8–5
Constraints
The Classic Timing Analyzer and TimeQuest analyzer store constraints in different
files, support different methods for constraint entry, and prioritize constraints
differently. The following sections explain these differences.
Constraint Files
The TimeQuest analyzer stores all SDC timing constraints in .sdc files. The Classic
Timing Analyzer stores all timing assignments in the .qsf for your project.
When you use the TimeQuest analyzer, your .qsf contains all assignments and
settings except for SDC constraints. The TimeQuest analyzer ignores the timing
assignments in your .qsf except when the conversion utility converts Classic Timing
Analyzer timing assignments to TimeQuest analyzer SDC constraints. There is no
automatic process that keeps timing constraints synchronized between your .qsf and
.sdc files. You must manually keep the constraints synchronized, if so desired.
Constraint Entry
With the Classic Timing Analyzer, you enter timing assignments with the Settings
dialog box, the Assignment Editor, or with commands in Tcl scripts. With the
TimeQuest analyzer, you cannot use the Assignment Editor to enter SDC constraints.
You must use one of the following methods to enter TimeQuest analyzer constraints:
■
Enter constraints at the Tcl prompt in the TimeQuest analyzer
■
Enter constraints in an .sdc with a text editor or SDC editor
■
Use the constraint entry commands on the Constraints menu in the TimeQuest
analyzer GUI
You can enter timing assignments for the Classic Timing Analyzer even if no timing
netlist exists for your design. The TimeQuest analyzer requires that a netlist exist for
interactive constraint entry. Each TimeQuest analyzer constraint is a Tcl command
evaluated in real-time, if entered directly in the Tcl console. As part of this evaluation,
the TimeQuest analyzer validates all names. To do this, SDC commands can only be
evaluated after a netlist is created. An .sdc can be created at any time using the
TimeQuest analyzer or any other text editor, but a netlist is required before an .sdc can
be sourced. You must create a timing netlist in the TimeQuest analyzer before you can
enter constraints with either of the following interactive methods:
■
At the Tcl console of the TimeQuest analyzer
■
With commands on the Constraints menu in the TimeQuest analyzer GUI
If you enter constraints with a text editor separate from the TimeQuest analyzer, no
timing netlist is required.
To create a timing netlist in the TimeQuest analyzer, use the create_timing_netlist
command, or double-click Create Timing Netlist in the Tasks pane of the TimeQuest
analyzer GUI.
December 2010
Altera Corporation
Quartus II Handbook Version 11.0 Volume 3: Verification
8–6
Chapter 8: Switching to the Quartus II TimeQuest Timing Analyzer
Differences Between the Quartus II Timing Analyzers
Time Units
Enter time values in default time units of nanoseconds (ns) with up to three decimal
places. Note that the TimeQuest analyzer does not display the default time unit when
it displays time values.
You can specify a different default time unit with the set_time_format -unit <default
time unit> command, or specify another unit when you enter a time value, for
example, 300ps.
1
Specifying time units after a value is not part of the standard SDC format. Unit
specification is a TimeQuest analyzer extension.
You can specify clock constraints with period or frequency in the TimeQuest analyzer.
For example, you can use any of the following constraints:
■
create_clock -period 10.000
(assuming default units and decimal places)
■
create_clock -period "100 MHz"
■
create_clock -period "10 ns"
MegaCore Functions
If you change any MegaCore function settings and regenerate the core after you
convert your timing assignments to SDC constraints, you must manually update the
SDC constraints or reconvert your assignments. You must update or reconvert,
because changes to MegaCore function settings can affect timing assignments
embedded in the hardware description language files of the function. The timing
assignments are not converted automatically when the core settings change.
1
You should make a backup copy of your .sdc before reconverting assignments. If you
make changes to the .sdc, you can manually copy the updated MegaCore timing
constraints to your .sdc.
Bus Name Format
In the Classic Timing Analyzer, you can make a timing assignment to all bits in a bus
with the bus name (or the bus name followed by an asterisk enclosed in square
brackets) as the target. For example, to make an assignment to all bits of a bus called
address, use address or address[*] as the target of the assignment.
In the TimeQuest analyzer, you must use the bus name followed by square brackets
enclosing an asterisk, as follows: address[*] to make all timing assignments to all bits
within a bus.
Quartus II Handbook Version 11.0 Volume 3: Verification
December 2010 Altera Corporation
Chapter 8: Switching to the Quartus II TimeQuest Timing Analyzer
Differences Between the Quartus II Timing Analyzers
8–7
Constraint File Priority
Figure 8–3 shows the priority order in which the TimeQuest analyzer searches for .sdc
files.
Figure 8–3. .sdc Search Order
Are any
SDC files specified in
the Add Files project
dialog box?
Yes
No
Does the SDC file
<revision>.sdc
exist?
Yes
No
The TimeQuest Timing
Analyzer
does not create nor
convert any constraints
Continue with the chosen
SDC file(s)
If you specify constraints in multiple .sdc files, or if you use a single .sdc with a name
other than <revision>.sdc, you must add the files to your project so the TimeQuest
analyzer can find them.
h For more information, refer to Managing Files in a Project in Quartus II Help.
You can also add .sdc files to your project with the following Tcl command in your
.qsf, repeated once for each .sdc:
set_global_assignment -name SDC_FILE <.sdc file name>
The TimeQuest analyzer reads constraint files from the files list in the order they are
listed.
If you use an .sdc created by the conversion utility, you should place it first in the list
of files. When conflicting constraints apply to the same node, the last constraint has
the highest priority. Therefore, .sdc files with your additions or changes should be
listed after the .sdc created by the conversion utility, so your constraints have higher
priority.
December 2010
Altera Corporation
Quartus II Handbook Version 11.0 Volume 3: Verification
8–8
Chapter 8: Switching to the Quartus II TimeQuest Timing Analyzer
Differences Between the Quartus II Timing Analyzers
When you process your design, and the TimeQuest analyzer cannot find an .sdc it
attempts to meet a default 1 GHz constraint on all clocks in your design. The
Quartus II software may prompt you to run the conversion utility if your design does
not reference any .sdc files.
You must review the .sdc as you would when manually running the conversion
utility. Refer to “Reviewing Conversion Results” on page 8–50 for information about
reviewing the converted constraints.
Constraint Priority
The Classic Timing Analyzer prioritizes assignments based on the specificity of the
nodes to which they are assigned. The more specific an assignment is, the higher its
priority. The TimeQuest analyzer simplifies these precedence rules. When overlaps
occur in the nodes to which the constraints apply, constraints at the bottom of the file
take priority over constraints at the top of the file.
As an example, in the Classic Timing Analyzer, point-to-point multicycle assignments
have higher priority than single-point multicycle assignments. The two assignments
in Example 8–1 result in a multicycle assignment of two between A_reg and all nodes
beginning with B, including B_reg. The single-point assignment does not apply to
paths from A_reg to B_reg, because the specific point-to-point assignment takes
priority over the general single-point assignment.
Example 8–1. Classic Timing Analyzer Multicycle Assignments
set_instance_assignment -name MULTICYCLE -from A_reg -to B* 2
set_instance_assignment -name MULTICYCLE -to B_reg 3
Example 8–2 shows SDC versions of the preceding Classic Timing Analyzer timing
assignments. However, the TimeQuest analyzer evaluates the constraints from top to
bottom, regardless of whether the assignments are point-to-point assignments or
single-point assignments, so the path from A_reg to B_reg receives a multicycle
exception of three because it is ordered second.
Example 8–2. TimeQuest Analyzer Multicycle Exceptions
set_multicycle_path -from [get_keepers A_reg] -to [get_keepers B*] 2
set_multicycle_path -to [get_keepers B_reg] 3
Quartus II Handbook Version 11.0 Volume 3: Verification
December 2010 Altera Corporation
Chapter 8: Switching to the Quartus II TimeQuest Timing Analyzer
Differences Between the Quartus II Timing Analyzers
8–9
Ambiguous Constraints
Because of capabilities in the TimeQuest analyzer, some Classic Timing Analyzer
assignments can be ambiguous after conversion by the conversion utility. These
assignments require manual updating based on your knowledge of your design.
Figure 8–4 shows a ripple clock circuit. The explanation that follows shows an
ambiguous constraint for that circuit, and how to edit the constraint to remove the
ambiguity in the TimeQuest analyzer.
Figure 8–4. Ripple Clock Circuit
reg_c
clk_a
reg_d
clk_b
In the Classic Timing Analyzer, the following QSF multicycle assignment from clk_a
to clk_b with a value of two applies to paths transferring data from the clk_a domain
to the clk_b domain:
set_instance_assignment -name MULTICYCLE -from clk_a -to clk_b 2
In Figure 8–4, this assignment applies to the path from reg_c to reg_d. In the
TimeQuest analyzer, the use of the clock node names in the following equivalent
multicycle exception is ambiguous:
set_multicycle_path -setup -from clk_a -to clk_b 2
The exception could apply to the path between clk_a and clk_b, or it could apply to
paths from one ripple clock domain to the other ripple clock domain (reg_c to reg_d).
The TimeQuest analyzer exceptions shown in Example 8–3 are not ambiguous
because they use collections to explicitly specify the targets of the exception.
Example 8–3. Unambiguous TimeQuest Analyzer Exceptions
# Applies to path from reg_c to reg_d
set_multicycle_path -setup -from [get_clocks clk_a] \
-to [get_clocks clk_b] 2
# Applies to path from clk_a to clk_b
set_multicycle_path -setup -from [get_registers clk_a] \
-to [get_registers clk_b] 2
December 2010
Altera Corporation
Quartus II Handbook Version 11.0 Volume 3: Verification
8–10
Chapter 8: Switching to the Quartus II TimeQuest Timing Analyzer
Differences Between the Quartus II Timing Analyzers
Clocks
The Classic Timing Analyzer and TimeQuest analyzer detect, analyze, and report
clocks differently. The following sections describe these differences.
Related and Unrelated Clocks
In the TimeQuest analyzer, all clocks are related by default, and you must add
assignments to indicate unrelated clocks. However, in the Classic Timing Analyzer, all
base clocks are unrelated by default. All derived clocks of a base clock are related to
each other, but are unrelated to other base clocks and their derived clocks.
Figure 8–5 shows a circuit with a path between two clock domains. The TimeQuest
analyzer analyzes the path from reg_a to reg_b because all clocks are related by
default. The Classic Timing Analyzer does not analyze the path from reg_a to reg_b
by default.
Figure 8–5. Cross Clock Domain Path
data_a
reg_a
clock_a
data_out
reg_b
clock_b
To make clocks unrelated in the TimeQuest analyzer, use the set_clock_groups
command with the -exclusive option. The TimeQuest analyzer does not analyze
paths between the two clock domains. For example, the following command renders
clock_a and clock_b unrelated:
set_clock_groups -exclusive -group {clock_a} -group {clock_b}
Clock Offset
In the TimeQuest analyzer, clocks can have nonzero values for the rising edge of the
waveform, a feature that the Classic Timing Analyzer does not support. To specify an
offset for your clock, use the create_clock command with the -waveform option to
specify the rising and falling edge times, as shown in this example:
-waveform {<rising edge time> <falling edge time>}
Quartus II Handbook Version 11.0 Volume 3: Verification
December 2010 Altera Corporation
Chapter 8: Switching to the Quartus II TimeQuest Timing Analyzer
Differences Between the Quartus II Timing Analyzers
8–11
Figure 8–6 shows a clock constraint with an offset in the TimeQuest analyzer GUI.
Figure 8–6. Create Clock Dialog Box
Clock offset affects setup and hold relationships. Launch and latch edges are
evaluated after offsets are applied. Depending on the offset, the setup relationship can
be the offset value, or the difference between the period and offset. You should use the
clock latency constraint, instead of clock offset to emulate latency. Refer to “Offset and
Latency Example” on page 8–11 for an example that illustrates the different effects of
offset and latency.
Clock Latency
The TimeQuest analyzer does not ignore early clock latency and late clock latency
differences when the clock source is the same, as the Classic Timing Analyzer does.
When you specify latencies, you should take common clock path pessimism into
account and use uncertainty to control pessimism differences for clock-to-clock data
transfers. Unlike clock offset, clock latency affects skew, and launch and latch edges
are evaluated before latencies are applied, so the setup relationship is always equal to
the period.
Offset and Latency Example
Figure 8–7 shows a simple register-to-register circuit used to illustrate the different
effects of offset and latency. The examples show why you should not use clock offset
to emulate clock latency.
Figure 8–7. Offset and Latency Example Circuit
in
clk
reg_a
3 ns
reg_b
out
PLL
The period for clk is 10 ns, and the period for the phase-locked loop (PLL) output is
10 ns. The PLL compensation value is –2 ns. The network delay from the PLL to reg_a
equals the network delay from clk to reg_b. Finally, the delay from reg_a to reg_b is
3 ns.
December 2010
Altera Corporation
Quartus II Handbook Version 11.0 Volume 3: Verification
8–12
Chapter 8: Switching to the Quartus II TimeQuest Timing Analyzer
Differences Between the Quartus II Timing Analyzers
Clock Offset Scenario
Treat the PLL compensation value of –2 ns as a clock offset of –2 ns with a clock skew
of 0 ns. Launch and latch edges are evaluated after offsets are applied, so the setup
relationship is 2 ns (Figure 8–8).
Figure 8–8. Setup Relationship Using Offset
Setup Relationship Using Offset
PLL
clk
0 2
10 12
20 22
Equation 8–1 shows how to calculate the slack value for the path from reg_a to reg_b.
Equation 8–1.
slack = clock arrival – data arrival
slack = setup relationship + clock skew – reg_to_reg delay
slack = 2ns + 0ns – 3ns
slack = – 1ns
The negative slack requires a multicycle assignment with a value of two and a hold
multicycle assignment with a value of one to correct. With these assignments from
reg_a to reg_b, the setup relationship is then 12 ns, resulting in a slack of 9 ns.
Clock Latency Scenario
Treat the PLL compensation value of –2 ns as latency with a clock skew of 2 ns.
Because launch and latch edges are evaluated before latencies are applied, the setup
relationship is 10 ns (the period of clk and the PLL) (Figure 8–9).
Figure 8–9. Setup Relationship Using Latency
Setup Relationship Using Latency
PLL
clk
0 2
Quartus II Handbook Version 11.0 Volume 3: Verification
10 12
20 22
December 2010 Altera Corporation
Chapter 8: Switching to the Quartus II TimeQuest Timing Analyzer
Differences Between the Quartus II Timing Analyzers
8–13
Equation 8–2 shows how to calculate the slack value for the path from reg_a to reg_b.
Equation 8–2.
slack = clock arrival – data arrival
slack = setup relationship + clock skew – reg_to_reg delay
slack = 10ns + 2ns – 3ns
slack = 9ns
The slack of 9 ns is identical to the slack computed in the previous example, but
because this example uses latency instead of offset, no multicycle assignment is
required.
Clock Uncertainty
The Classic Timing Analyzer ignores Clock Setup Uncertainty and Clock Hold
Uncertainty assignments when you specify a setup or hold relationship between two
clocks. However, the TimeQuest analyzer does not ignore clock uncertainty when you
specify a setup or hold relationship between two clocks. Figure 8–10 and Figure 8–11
illustrate the different behavior between the TimeQuest analyzer and the Classic
Timing Analyzer.
In both figures, the constraints are identical. There is a 20-ns period for clk_a and
clk_b. There is a setup relationship (a set_max_delay exception in the TimeQuest
analyzer) of 7 ns from clk_a to clk_b, and a clock setup uncertainty constraint of 1 ns
from clk_a to clk_b. The actual setup relationship in the TimeQuest analyzer is 1 ns
less than in the Classic Timing Analyzer because of the way they analyze clock
uncertainty.
Figure 8–10. Classic Timing Analyzer Behavior
0 ns
7 ns
10 ns
Setup Relationship with and without Uncertainty
Figure 8–11. TimeQuest Analyzer Behavior
0
6 7
10
Clock Setup Uncertainty
Setup Relationship with Uncertainty
Setup Relationship without Uncertainty
December 2010
Altera Corporation
Quartus II Handbook Version 11.0 Volume 3: Verification
8–14
Chapter 8: Switching to the Quartus II TimeQuest Timing Analyzer
Differences Between the Quartus II Timing Analyzers
Derived and Generated Clocks
Generated clocks in the TimeQuest analyzer are different than derived clocks in the
Classic Timing Analyzer. In the Classic Timing Analyzer, the source of a derived clock
must be a base clock. However, in the TimeQuest analyzer, the source of a generated
clock can be any other clock in the design (including virtual clocks), or any node to
which a clock propagates through the clock network. Because generated clocks are
related through the clock network, you can specify generated clocks for isolated
modules, such as IP, without knowing the details of the clocks outside of the module.
In the TimeQuest analyzer, you can specify generated clocks relative to specific edges
and edge shifts of a master clock, a feature that the Classic Timing Analyzer does not
support.
Figure 8–12 shows a simple ripple clock that you should constrain with generated
clocks in the TimeQuest analyzer.
Figure 8–12. Generated Clocks Circuit
reg_a
reg_b
clk
The TimeQuest analyzer constraints shown in Example 8–4 constrain the clocks in the
circuit above. Note that the source of each generated clock can be the input pin of the
register itself, not the name of another clock.
Example 8–4. Generated Clock Constraints
create_clock –period 10 –name clk clk
create_generated_clock –divide_by 2 –source reg_a|CLK -name reg_a reg_a
create_generated_clock –divide_by 2 –source reg_b|CLK -name reg_b reg_b
Automatic Clock Detection
The Classic Timing Analyzer and TimeQuest analyzer identify clock sources of
registers that do not have a defined clock source. The Classic Timing Analyzer traces
back along the clock network, through registers and logic, until it reaches a top-level
port in your design. The TimeQuest analyzer also traces back along the clock network,
but it stops at registers.
You can use two SDC commands in the TimeQuest analyzer to automatically detect
and create clocks for unconstrained clock sources:
■
derive_clocks—creates clocks on sources of clock pins that do not already have at
least one clock sourcing the clock pin
■
derive_pll_clocks—identifies PLLs and creates generated clocks on the clock
output pins
Quartus II Handbook Version 11.0 Volume 3: Verification
December 2010 Altera Corporation
Chapter 8: Switching to the Quartus II TimeQuest Timing Analyzer
Differences Between the Quartus II Timing Analyzers
8–15
derive_clocks Command
Figure 8–13 shows a circuit with a divide-by-two register and indicates the clock
network delays as A, B, and C. The following explanation describes how the Classic
Timing Analyzer and TimeQuest analyzer detect the clocks in Figure 8–13.
Figure 8–13. Example Circuit for derive_clocks
reg_b
reg_c
B
reg_a
clk
A
C
The Classic Timing Analyzer detects that clk is the clock source for registers reg_a,
reg_b, and reg_c. It detects that clk is the clock source for reg_c because it traces back
along the clock network for reg_c through reg_a, until it finds the clk port. The
Classic Timing Analyzer computes the clock arrival time for reg_c as A + C.
The derive_clocks command in the TimeQuest analyzer creates two base clocks, one
on the clk port and one on reg_a, because the command does not trace through
registers on the clock network. The clock arrival time for reg_c is C because the clock
starts at reg_a.
To make the TimeQuest analyzer compute the same clock arrival time (A + C) as the
Classic Timing Analyzer for reg_c, make the following modifications to the clock
constraints created by the derive_clocks command:
1. Change the base clock named reg_a to a generated clock
2. Make the source the clock pin of reg_a (reg_a|clk) or the port clk
3. Add a -divide_by 2 option
These modifications cause the clock arrival times to reg_c to match between the
Classic Timing Analyzer and the TimeQuest analyzer. However, the clock for reg_c is
shown as reg_a instead of clk, and the launch and latch edges may change for some
paths due to the -divide_by option.
You can use the derive_clocks command at the beginning of your design cycle when
you do not know all of the clock constraints for your design, but you should not use it
during timing sign-off. Instead, you should constrain each clock in your design with
the create_clock or create_generated_clocks commands.
December 2010
Altera Corporation
Quartus II Handbook Version 11.0 Volume 3: Verification
8–16
Chapter 8: Switching to the Quartus II TimeQuest Timing Analyzer
Differences Between the Quartus II Timing Analyzers
The derive_clocks command detects clocks in your design using the following rules:
1. An input clock port is detected as a clock only if there are no other clocks feeding
the destination registers.
a. Input clock ports are not detected automatically if they feed only other base
clocks.
b. If other clocks feed the port’s register destinations, the port is assumed to be an
enable or data port for a gated clock.
c. When no clocks are defined, and multiple clocks feed a destination register, the
auto-detected clock is selected arbitrarily.
2. All ripple clocks (registers in a clock path) are detected as clocks automatically
using the same rules for input clock ports. If both an input port and a register feed
register clock pins, the input port is selected as the clock.
The following examples show how the derive_clocks command detects clocks in the
circuit shown in Figure 8–14.
Figure 8–14. Detectable Clock
a_in
b
■
If you do not make any clock settings, and then you use the derive_clocks
command, it detects a_in as a clock according to rule 1, because there are no other
clocks feeding the register.
■
If you create a clock with b as its target, and then you run the derive_clocks
command, it does not detect a_in as a clock according to rule 1a, because a_in
feeds only another clock.
The following examples show how the derive_clocks command detects clocks in the
circuit shown in Figure 8–15.
Figure 8–15. Two Detectable Clocks
a_in
b_in
■
If you do not make any clock settings and then you use the derive_clocks
command, it selects a clock arbitrarily, according to rule 1c.
■
If you create a clock with a_in as its target and then you use the derive_clocks
command, it does not detect b_in as a clock according to rule 1b, because another
clock (a_in) feeds the register.
Quartus II Handbook Version 11.0 Volume 3: Verification
December 2010 Altera Corporation
Chapter 8: Switching to the Quartus II TimeQuest Timing Analyzer
Differences Between the Quartus II Timing Analyzers
8–17
derive_pll_clocks Command
The derive_pll_clocks command names the generated clocks according to the
names of the PLL output pins by default, and you cannot change these generated
clock names. If you want to use your own clock names, you must use the
create_generated_clock command for each PLL output clock and specify the names
with the -name option.
If you use the PLL clock-switchover feature, the derive_pll_clocks command creates
additional generated clocks on each output clock pin of the PLL based on the
secondary clock input to the PLL. This may require the set_clock_groups or
set_false_path commands to cut the primary and secondary clock outputs. For
information about how to make clocks unrelated, refer to “Related and Unrelated
Clocks” on page 8–10.
Hold Relationship
The TimeQuest analyzer and Classic Timing Analyzer choose the worst-case hold
relationship differently. Refer to Figure 8–16 for sample waveforms to illustrate the
different effects.
Figure 8–16. Worst-Case Hold
Source Clock
Hold
Check A1
Setup A
Setup B
Hold
Check A2
Hold
Check B1
Hold
Check B2
Destination Clock
0 ns
8 ns
16 ns
24 ns
30 ns
The Classic Timing Analyzer first identifies the worst-case setup relationship. The
worst-case setup relationship is Setup B. Then the Classic Timing Analyzer chooses
the worst-case hold relationship (Hold Check B1 or Hold Check B2) for that specific
setup relationship, Setup B. The Classic Timing Analyzer chooses Hold Check B2 for
the worst-case hold relationship.
However, the TimeQuest analyzer calculates worst-case hold relationships for all
possible setup relationships and chooses the absolute worst-case hold relationship.
The TimeQuest analyzer checks two hold relationships for every setup relationship:
■
Data launched by the current launch edge not captured by the previous latch edge
(Hold Check A1 and Hold Check B1)
■
Data launched by the next launch edge not captured by the current latch edge
(Hold Check A2 and Hold Check B2)
The TimeQuest analyzer chooses Hold Check A2 as the absolute worst-case hold
relationship.
December 2010
Altera Corporation
Quartus II Handbook Version 11.0 Volume 3: Verification
8–18
Chapter 8: Switching to the Quartus II TimeQuest Timing Analyzer
Differences Between the Quartus II Timing Analyzers
Clock Objects
The Classic Timing Analyzer treats nodes with clock settings assigned to them as
special objects in the timing netlist. Any node in the timing netlist with a clock setting
is treated as a clock object, regardless of its actual type, such as a register. When a
register has a clock setting assigned to it, the Classic Timing Analyzer does not
analyze register-to-register paths beginning or ending at that register. Figure 8–17
shows a circuit that illustrates this situation.
Figure 8–17. Clock Objects
reg_c
reg_a
reg_d
reg_b
clk
With no clock assignments on any of the registers, the Classic Timing Analyzer
analyzes timing on the path from reg_a to reg_b, and from reg_c to reg_d. If you
make a clock setting assignment to reg_b, reg_b is no longer considered a register
node in the netlist, and the path from reg_a to reg_b is no longer analyzed.
In the TimeQuest analyzer, clocks are abstract objects that are associated with nodes in
the timing netlist. The TimeQuest analyzer analyzes the path from reg_a to reg_b
even if there is a clock assigned to reg_b.
Hold Multicycle
The hold multicycle value numbering scheme is different in the Classic Timing
Analyzer and TimeQuest analyzer. Also, you can choose between two values for the
default hold multicycle value in the Classic Timing Analyzer but you cannot change
the default value in the TimeQuest analyzer. The hold multicycle value specifies
which clock edge is used for hold analysis when you change the latch edge with a
multicycle assignment.
In the Classic Timing Analyzer, the hold multicycle value is based on one, and is the
number of clock cycles away from the setup edge. In the TimeQuest analyzer, the hold
multicycle value is based on zero, and is the number of clock cycles away from the
default hold edge. In the TimeQuest analyzer, the default hold edge is one edge before
or after the setup edges. Subtract one from any hold multicycle value in the Classic
Timing Analyzer to compute the equivalent value for the TimeQuest analyzer.
Quartus II Handbook Version 11.0 Volume 3: Verification
December 2010 Altera Corporation
Chapter 8: Switching to the Quartus II TimeQuest Timing Analyzer
Differences Between the Quartus II Timing Analyzers
8–19
Figure 8–18 shows simple waveforms for a cross-clock domain transfer with the
indicated setup and hold edges.
Figure 8–18. First Relationship Example
Hold Edge
Setup Edge
In the TimeQuest analyzer, only a multicycle exception of two is required to constrain
the design for the indicated setup and hold relationships.
Figure 8–19 shows simple waveforms for a different cross-clock domain transfer with
indicated setup and hold edges. The following explanation shows what exceptions to
apply to achieve the desired setup and hold relationships.
Figure 8–19. Second Relationship Example
Hold Edge
Setup Edge
In the TimeQuest analyzer, you must use the following two exceptions:
■
A multicycle exception of two
■
A hold multicycle exception of one, because the hold edge is one edge behind the
default hold edge, which is one edge after the setup edge.
You should always add a hold multicycle assignment for every multicycle assignment
to ensure the correct exceptions are applied regardless of the timing analyzer you use.
Fitter Performance and Behavior
When you analyze a design with the TimeQuest analyzer, the Fitter memory use and
compilation time may increase as compared to the Classic Timing Analyzer, however
the timing analysis time may decrease.
The behavior for one value of the Optimize hold time Fitter assignment differs
between the TimeQuest analyzer and the Classic Timing Analyzer. In the TimeQuest
analyzer, the I/O Paths and Minimum TPD Paths setting and the All Paths setting
are equivalent, whereas in the Classic Timing Analyzer the settings directed the Fitter
to optimize hold times differently.
December 2010
Altera Corporation
Quartus II Handbook Version 11.0 Volume 3: Verification
8–20
Chapter 8: Switching to the Quartus II TimeQuest Timing Analyzer
Differences Between the Quartus II Timing Analyzers
Reporting
The TimeQuest analyzer provides a more flexible and powerful interface for reporting
timing analysis results than the Classic Timing Analyzer. Although the interface and
constraints are more flexible and powerful, both analyzers use the same device timing
models, except for device families that support rise/fall analysis. The Classic Timing
Analyzer does not support rise/fall analysis, but the TimeQuest analyzer does.
Therefore, you may see slightly different delays on identical paths in device families
that support rise/fall analysis if you analyze timing in both analyzers.
Both analyzers report identical delays along identically constrained paths in your
design. The TimeQuest analyzer allows you to constrain some paths that you could
not constrain with the Classic Timing Analyzer. Differently constrained paths result in
different reported values, but for identical paths in your design that are constrained
identically, the delays are exactly the same. Both timing analyzers use the same timing
models.
Paths and Pairs
In reporting, the most significant difference between the two analyzers is that the
TimeQuest analyzer reports paths, while the Classic Timing Analyzer reports pairs.
Path reporting means that the analyzer separately reports every path between two
registers. Pair reporting means that the analyzer reports only the worst-case path
between two registers. One benefit of path reporting over pair reporting is that you
can more easily identify common points in failing paths that may be good targets for
optimization.
If your design does not meet timing constraints, this reporting difference can give the
impression that there are many more timing failures when you use the TimeQuest
analyzer. Figure 8–20 shows a sample circuit followed by a description of the
differences between path and pair reporting.
Figure 8–20. Failing Paths
node C
regA
10 ns
regB
node D
9 ns
node E
7 ns
clk
There is an 8-ns period constraint on the clk pin, resulting in two paths that fail
timing: regA  C  regB and regA  D  regB. The Classic Timing Analyzer
reports only worst-case path regA  C  regB. The TimeQuest analyzer reports
both failing paths regA  C  regB and regA  D  regB. It also reports path
regA  E  regB with positive slack.
Quartus II Handbook Version 11.0 Volume 3: Verification
December 2010 Altera Corporation
Chapter 8: Switching to the Quartus II TimeQuest Timing Analyzer
Differences Between the Quartus II Timing Analyzers
8–21
Default Reports
The TimeQuest analyzer generates only a small number of reports by default, as
compared to the Classic Timing Analyzer, which generates every available report by
default. With the TimeQuest analyzer, you generate reports on demand.
Netlist Names
The Classic Timing Analyzer uses register names in reporting, but the TimeQuest
analyzer uses register pin names (with the exception of port names of the top-level
module). Buried nodes or register names are used when necessary.
Example 8–5 shows how register names are used in Classic Timing Analyzer reports.
Example 8–5. Netlist Names in the Classic Timing Analyzer
Info: + Shortest register to register delay is 0.538 ns
Info: 1: + IC(0.000 ns) + CELL(0.000 ns) = 0.000 ns; Loc. =
LCFF_X1_Y5_N1;
Fanout = 1; REG Node = 'inst'
Info: 2: + IC(0.305 ns) + CELL(0.149 ns) = 0.454 ns; Loc. =
LCCOMB_X1_Y5_N20; Fanout = 1; COMB Node = 'inst3~feeder'
Info: 3: + IC(0.000 ns) + CELL(0.084 ns) = 0.538 ns; Loc. =
LCFF_X1_Y5_N21; Fanout = 1; REG Node = 'inst3'
Info: Total cell delay = 0.233 ns ( 43.31 % )
Info: Total interconnect delay = 0.305 ns ( 56.69 % )
Example 8–6 shows the same information as presented in a TimeQuest analyzer
report. In this example, register pin names are used in place of register names.
Example 8–6. Netlist Names in the TimeQuest Analyzer
Info:
Info:
Info:
Info:
Info:
Info:
3.788
3.788
4.093
4.242
4.242
4.326
0.250
0.000
0.305
0.149
0.000
0.084
RR
RR
RR
RR
RR
uTco
CELL
IC
CELL
IC
CELL
inst
inst|regout
inst3~feeder|datad
inst3~feeder|combout
inst3|datain
inst3
Non-Integer Clock Periods
In some cases when related clock periods are not integer multiples of each other, a
lack of precision in clock period definition in the TimeQuest analyzer can result in
reported setup or hold relationships of a few picoseconds. In addition, launch and
latch times for the relationships can be very large. If you experience this, use the
set_max_delay and set_min_delay commands to specify the correct relationships.
The Classic Timing Analyzer can maintain additional information about clock
frequency that mitigates the lack of precision in clock period definition.
December 2010
Altera Corporation
Quartus II Handbook Version 11.0 Volume 3: Verification
8–22
Chapter 8: Switching to the Quartus II TimeQuest Timing Analyzer
Differences Between the Quartus II Timing Analyzers
When the clock period cannot be expressed as an integer in terms of picoseconds, you
have the situation shown in Figure 8–21. This figure shows two clocks: clk_a has a
10 ns period, and clk_b has a 6.667 ns period.
Figure 8–21. Very Small Setup Relationship
clk_a
0
10
20
clk_b
0
6.667
13.334
20.001
There is a 1 ps setup relationship at 20 ns because you cannot specify the 6.667 ns
period beyond picosecond precision. You should apply the maximum and minimum
delay exceptions shown in Example 8–7 between the two clocks to specify the correct
relationships.
Example 8–7. Minimum and Maximum Delay Exceptions
set_max_delay -from [get_clocks clk_a] -to [get_clocks clk_b] 3.333
set_min_delay -from [get_clocks clk_a] -to [get_clocks clk_b] 0
Quartus II Handbook Version 11.0 Volume 3: Verification
December 2010 Altera Corporation
Chapter 8: Switching to the Quartus II TimeQuest Timing Analyzer
Differences Between the Quartus II Timing Analyzers
8–23
Other Features
The TimeQuest analyzer reports time values without units. By default, the units are
nanoseconds, and three decimal places are displayed. You can change the default time
unit and decimal places with the set_time_format command.
When you use the TimeQuest analyzer in a Tcl shell, output is ASCII-formatted, and
columns are aligned for easy reading on 80-column consoles. Example 8–8 shows
sample output from the TimeQuest analyzer report_timing command.
Example 8–8. ASCII-Formatted TimeQuest Analyzer Report
tcl> report_timing -from inst -to inst5
Info: Report Timing: Found 1 setup paths (0 violated). Worst case slack
is 3.634
Info: -from [get_keepers inst]
Info: -to [get_keepers inst5]
Info: Path #1: Slack is 3.634
Info:
===================================================================
Info: From Node
: inst
Info: To Node
: inst5
Info: Launch Clock : clk_a
Info: Latch Clock : clk_b
Info:
Info: Data Arrival Path:
Info:
Info: Total (ns) Incr (ns)
Type Node
Info: ========== ========= == ====
===================================
Info:
0.000
0.000
launch edge time
Info:
2.347
2.347 R
clock network delay
Info:
2.597
0.250
uTco inst
Info:
2.597
0.000 RR CELL inst|regout
Info:
3.088
0.491 RR
IC inst6|datac
Info:
3.359
0.271 RR CELL inst6|combout
Info:
3.359
0.000 RR
IC inst5|datain
Info:
3.443
0.084 RR CELL inst5
Info:
Info: Data Required Path:
Info:
Info: Total (ns) Incr (ns)
Type Node
Info: ========== ========= == ====
===================================
Info:
4.000
4.000
latch edge time
Info:
7.041
3.041 R
clock network delay
Info:
7.077
0.036
uTsu inst5
Info:
Info: Data Arrival Time :
3.443
Info: Data Required Time :
7.077
Info: Slack
:
3.634
Info:
===================================================================
Info:
1 3.634
December 2010
Altera Corporation
Quartus II Handbook Version 11.0 Volume 3: Verification
8–24
Chapter 8: Switching to the Quartus II TimeQuest Timing Analyzer
Timing Assignment Conversion
Timing Assignment Conversion
This section describes Classic Timing Analyzer QSF timing assignments and the
equivalent TimeQuest analyzer constraints. In some cases, there is more than one
potentially equivalent SDC constraint. In these cases, correct conversion requires
knowledge of the intended function of your design.
This section includes the following topics:
■
“Clock Enable Multicycle” on page 8–28
■
“Clock Latency” on page 8–25
■
“Clock Uncertainty” on page 8–25
■
“Cut Timing Path” on page 8–40
■
“Default Required fMAX Assignment” on page 8–26
■
“Hold Relationship” on page 8–25
■
“Input and Output Delay” on page 8–29
■
“Inverted Clock” on page 8–25
■
“Maximum Clock Arrival Skew” on page 8–41
■
“Maximum Data Arrival Skew” on page 8–41
■
“Maximum Delay” on page 8–40
■
“Minimum Delay” on page 8–41
■
“Minimum tCO Requirement” on page 8–36
■
“Minimum tPD Requirement” on page 8–40
■
“Multicycle” on page 8–27
■
“Not a Clock” on page 8–26
■
“Setup Relationship” on page 8–24
■
“tCO Requirement” on page 8–34
■
“tH Requirement” on page 8–32
■
“tPD Requirement” on page 8–38
■
“tSU Requirement” on page 8–30
■
“Virtual Clock Reference” on page 8–26
Setup Relationship
The Setup Relationship assignment overrides the setup relationship between two
clocks. By default, the Classic Timing Analyzer automatically calculates the setup
relationship based on your clock settings. The QSF variable for the Setup
Relationship assignment is SETUP_RELATIONSHIP. In the TimeQuest analyzer, use the
set_max_delay command to specify the maximum setup relationship for a path.
The setup relationship value is the time between latch and launch edges before the
TimeQuest analyzer accounts for clock latency, source tCO, or destination tSU.
Quartus II Handbook Version 11.0 Volume 3: Verification
December 2010 Altera Corporation
Chapter 8: Switching to the Quartus II TimeQuest Timing Analyzer
Timing Assignment Conversion
8–25
Hold Relationship
The Hold Relationship assignment overrides the hold relationship between two
clocks. By default, the Classic Timing Analyzer automatically calculates the hold
relationship based on your clock settings. The QSF variable for the Hold Relationship
assignment is HOLD_RELATIONSHIP. In the TimeQuest analyzer, use the set_min_delay
command to specify the minimum hold relationship for a path.
Clock Latency
Table 8–1 shows the equivalent SDC constraints for the Early Clock Latency and Late
Clock Latency Classic Timing Analyzer assignments.
Table 8–1. Classic Timing Analyzer Assignments and SDC Equivalent Constraints for Clock
Latency Assignments
Classic Timing Analyzer Assignment
SDC Constraint
Assignment Name
QSF Variable
Early Clock Latency
EARLY_CLOCK_LATENCY
set_clock_latency -source -late
Late Clock Latency
LATE_CLOCK_LATENCY
set_clock_latency -source -early
For more information about clock latency support in the TimeQuest analyzer, refer to
“Clock Latency” on page 8–11.
Clock Uncertainty
Table 8–2 shows the equivalent SDC constraints for the Clock Setup Uncertainty and
Clock Hold Uncertainty Classic Timing Analyzer assignments.
Table 8–2. Classic Timing Analyzer Assignments and SDC Equivalent Constraints for Clock
Uncertainty Assignments
Classic Timing Analyzer Timing Assignment
SDC Constraint
Assignment Name
QSF Variable
Clock Setup Uncertainty
CLOCK_SETUP_UNCERTAINTY
set_clock_uncertainty -setup
Clock Hold Uncertainty
CLOCK_HOLD_UNCERTAINTY
set_clock_uncertainty -hold
Inverted Clock
The Classic Timing Analyzer detects inverted clocks automatically when the clock
inversion occurs at the input of the LCELL that contains the register specified in the
assignment. You must make an Inverted Clock assignment in all other situations for
Classic Timing Analyzer analysis. The QSF variable for the Inverted Clock
assignment is INVERTED_CLOCK. The TimeQuest analyzer detects inverted clocks
automatically, regardless of the type of inversion circuit, in designs that target device
families that support unateness. For designs that target any other device family, you
must create a generated clock with the -invert option on the output of the cell that
inverts the clock.
December 2010
Altera Corporation
Quartus II Handbook Version 11.0 Volume 3: Verification
8–26
Chapter 8: Switching to the Quartus II TimeQuest Timing Analyzer
Timing Assignment Conversion
Not a Clock
The Not a Clock assignment directs the Classic Timing Analyzer to identify specified
node as not a clock source when it would normally be detected as a clock because of a
global fMAX requirement. The QSF variable for the Not a Clock assignment is
NOT_A_CLOCK. This assignment is not supported in the TimeQuest analyzer and there is
no equivalent constraint. Appropriate clock constraints are created in the TimeQuest
analyzer only.
Default Required fMAX Assignment
The Default Required fMAX assignment allows you to specify an fMAX requirement for
the Classic Timing Analyzer for all unconstrained clocks in your design. The QSF
variable for the Default Required fMAX assignment is FMAX_REQUIREMENT. You can use
the derive_clocks command to create clocks on sources of clock pins in your design
that do not already have clocks assigned to them. You should constrain each
individual clock in your design with the create_clock or created_generated_clock
command, instead of the derive_clocks command. Refer to “Automatic Clock
Detection” on page 8–14 to learn why you should constrain individual clocks in your
design.
Virtual Clock Reference
The Virtual Clock Reference assignment allows you to define timing characteristics
of a reference clock outside the FPGA. The QSF variable for the Virtual Clock
Reference assignment is VIRTUAL_CLOCK_REFERENCE. The TimeQuest analyzer
supports virtual clocks by default, while the Classic Timing Analyzer requires the
Virtual Clock Reference assignment to indicate that a clock setting is for a virtual
clock. To create a virtual clock in the TimeQuest analyzer, use the create_clock or
create_generated_clock commands with the -name option and no targets.
Figure 8–22 shows a circuit that requires a virtual clock, and the following example
shows how to constrain the circuit. The circuit shows data transfer between an Altera
FPGA and another device, and the clocks for the two devices are not related. You can
constrain the path with an output delay assignment, but that assignment requires a
virtual clock that defines the clock characteristics of the destination device.
Figure 8–22. Virtual Clock Circuit
Altera FPGA
Other Device
d_in
reg_a
reg_b
d_out
clk_a
Quartus II Handbook Version 11.0 Volume 3: Verification
clk_a
clk_b
clk_b
December 2010 Altera Corporation
Chapter 8: Switching to the Quartus II TimeQuest Timing Analyzer
Timing Assignment Conversion
8–27
Assume the circuit has the following assignments in the Classic Timing Analyzer:
■
Clock period of 10 ns on system_clk (clock for the Altera FPGA)
■
Clock period of 8 ns on virt_clk (clock for the other device)
■
The Virtual Clock Reference setting for virt_clk is On (indicates that virt_clk is
a virtual clock)
■
The Output Maximum Delay setting of 5 ns on dataout with respect to virt_clk
(constrains the path between the two devices)
The SDC commands shown in Example 8–9 constrain the circuit the same way.
Example 8–9. SDC Constraints
# Clock for the Altera FPGA
create_clock -period 10 -name system_clk [get_ports system_clk]
# Virtual clock for the other device, with no targets
create_clock -period 8 -name virt_clk
# Constrains the path between the two devices
set_output_delay -clock virt_clk 5 [get_ports dataout]
Clock Settings
The Classic Timing Analyzer includes a variety of assignments to describe clock
settings. These include duty cycle, fMAX, offset, and others. In the TimeQuest analyzer,
use the create_clock and create_generated_clock commands to constrain clocks.
Multicycle
Table 8–3 shows the equivalent SDC exceptions for each of these Classic Timing
Analyzer timing assignments.
Table 8–3. Classic Timing Analyzer Multicycle Assignments and SDC Equivalent Exceptions
Classic Timing Analyzer Multicycle Assignment
SDC Exception
Assignment Name
QSF Variable
Multicycle (1)
MULTICYCLE
set_multicycle_path -setup -end
Source Multicycle (2)
SRC_MULTICYCLE
set_multicycle_path -setup -start
Multicycle Hold (3)
HOLD_MULTICYCLE
set_multicycle_path -hold -end
Source Multicycle Hold
SRC_HOLD_MULTICYCLE set_multicycle_path -hold -start
Notes to Table 8–3:
(1) A multicycle assignment is also known as a “destination multicycle setup” assignment.
(2) A source multicycle assignment is also known as a “source multicycle setup” assignment.
(3) A multicycle hold is also known as a “destination multicycle hold “assignment.
December 2010
Altera Corporation
Quartus II Handbook Version 11.0 Volume 3: Verification
8–28
Chapter 8: Switching to the Quartus II TimeQuest Timing Analyzer
Timing Assignment Conversion
The default value and numbering scheme for the hold multicycle value is different in
the Classic Timing Analyzer and TimeQuest analyzer. Refer to “Hold Multicycle” on
page 8–18 for more information about the difference between the default value and
numbering scheme for the hold multicycle value in the Classic Timing Analyzer and
TimeQuest analyzer.
f For more information about how to convert the hold multicycle value, refer to the
Quartus II TimeQuest Timing Analyzer chapter in volume 3 of the Quartus II Handbook.
Clock Enable Multicycle
The Classic Timing Analyzer supports the following clock enable multicycle
assignments:
■
Clock Enable Multicycle
■
Clock Enable Source Multicycle
■
Clock Enable Multicycle Hold
■
Clock Enable Source Multicycle Hold
Corresponding types of multicycle assignments are applied to all registers enabled by
the targets of the specified clock. The TimeQuest analyzer supports clock-enabled
multicycle constraints with the get_fanouts command. Use the get_fanouts
command to create a collection of nodes that have a common source signal, such as a
clock enable.
I/O Constraints
FPGA I/O timing assignments have typically been made with FPGA-centric tSU and
tCO requirements for the Classic Timing Analyzer. However, the Classic Timing
Analyzer also supports input and output delay assignments to accommodate
industry-standard, system-centric timing constraints. Where possible, you should use
system-centric constraints to constrain your designs for the TimeQuest analyzer.
Table 8–4 includes Classic Timing Analyzer I/O assignments, the equivalent
FPGA-centric SDC constraints, and recommended system-centric SDC constraints.
Quartus II Handbook Version 11.0 Volume 3: Verification
December 2010 Altera Corporation
Chapter 8: Switching to the Quartus II TimeQuest Timing Analyzer
Timing Assignment Conversion
8–29
For setup checks (tSU and tCO), <latch – launch> equals the clock period for same-clock
transfers. For hold checks (tH and Minimum tCO), <latch – launch> equals 0 for
same-clock transfers. Conversions from Classic Timing Analyzer assignments to
set_input_delay and set_output_delay constraints work well only when the source
and destination registers’ clocks are the same (same clock and polarity). If the source
and destination registers’ clocks are different, the conversion may not be
straightforward and you should take extra care when converting to set_input_delay
and set_output_delay constraints.
Table 8–4. Classic Timing Analyzer and TimeQuest Analyzer Equivalent I/O Constraints
Classic Timing Analyzer
Assignment
FPGA-centric SDC
System-centric SDC
tSU Requirement
set_max_delay <tSU requirement>
set_input_delay -max
<latch - launch -- tSU
requirement>
tH Requirement
set_min_delay
set_input_delay -min
<latch -- launch + tH requirement>
tCO Requirement
set_max_delay <tCO requirement>
set_output_delay -max
<latch -- launch - tCO
requirement>
Minimum tCO Requirement
set_min_delay <minimum tCO
requirement>
set_output_delay -min
<latch -- launch - minimum tCO
requirement>
tPD Requirement
set_max_delay <tPD requirement>
(2)
Minimum tPD Requirement
set_min_delay <minimum tPD
requirement>
(2)
- <tH requirement> (1)
Notes to Table 8–4:
(1) Refer to “tH Requirement” on page 8–32 for an explanation about why this exception uses the negative tH requirement.
(2) The input and output delays can be used for tPD paths, such that they will be analyzed as a system fMAX path. This is a feature unique to the
TimeQuest analyzer.
Input and Output Delay
Table 8–5 shows the equivalent SDC exceptions for Classic Timing Analyzer timing
assignments.
Table 8–5. Classic Timing Analyzer Assignments and SDC Equivalent Exceptions
Classic Timing Analyzer Assignment
SDC Exception
Assignment Name
QSF Variable
Input Maximum Delay
INPUT_MAX_DELAY
set_input_delay -max
Input Minimum Delay
INPUT_MIN_DELAY
set_input_delay -min
Output Maximum Delay
OUTPUT_MAX_DELAY
set_output_delay -max
Output Minimum Delay
OUTPUT_MIN_DELAY
set_output_delay -min
In some circumstances, you may receive the following warning message when you
update the SDC netlist:
Warning: For set_input_delay/set_output_delay, port "<port>" does not
have delay for flag (<rise|fall>, <min|max>)
December 2010
Altera Corporation
Quartus II Handbook Version 11.0 Volume 3: Verification
8–30
Chapter 8: Switching to the Quartus II TimeQuest Timing Analyzer
Timing Assignment Conversion
This warning occurs whenever port constraints have maximum or minimum delay
assignments, but not both. In the Classic Timing Analyzer, device inputs can have
Input Maximum Delay assignments, Input Minimum Delay assignments, or both,
and device outputs can have Output Maximum Delay assignments, Output
Minimum Delay assignments, or both.
To avoid this warning, your .sdc must specify both the -max and -min options for each
port, or specify neither. If a device I/O in your design includes both the maximum
and minimum delay assignments in the Classic Timing Analyzer, the conversion
utility converts both, and no warning appears about that device I/O. If a device I/O
has only maximum or minimum delay assignments in the Classic Timing Analyzer,
you have the following options:
■
Add the missing minimum or maximum delay assignment to the device I/O
before performing the conversion.
■
Modify the SDC constraint after the conversion to add appropriate -max or -min
values.
■
Modify the SDC constraint to remove the -max or -min option so the value is used
for both by default.
tSU Requirement
The tSU Requirement assignment specifies the maximum acceptable clock setup time
for the input (data) pin. The QSF variable for the tSU Requirement assignment is
TSU_REQUIREMENT. You can convert the tSU Requirement assignment to the
set_max_delay command or the set_input_delay command with the -max option.
The delay value for the set_input_delay command is <latch – launch – tSU
requirement>. Refer to the labeled paths in Figure 8–23 to understand the names in
Equation 8–3 and Equation 8–4.
Figure 8–23. Path Names
src.out
srctodst
dst.in
dst.utsu
src.utco
src.clk
board.srcclk
dst.clk
board.dstclk
clk
Quartus II Handbook Version 11.0 Volume 3: Verification
December 2010 Altera Corporation
Chapter 8: Switching to the Quartus II TimeQuest Timing Analyzer
Timing Assignment Conversion
8–31
Equation 8–3 shows the derivation of this conversion.
Equation 8–3.
required – arrival  0
required = latch + board.dstclk + dst.clk – dst.utsu
arrival = launch + board.srcclk + src.clk + src.utco + src.out + srctodst + dst.in
input_delay = board.srcclk + src.clk + src.utcu + src.out + srctodst – board.dstclk
required = latch + dst.clk – dst.utsu
arrival = launch + input_delay + dst.in
 latch + dst.clk – dst.utsu  –  launch + input_delay + dst.in   0
t su requirement – actual t su  0
actual tsu = dst.in + dst.utsu – dst.clk
t su requirement –  dst.in + dst.utsu – dst.clk   0
t su requirement = latch – launch – input_delay
input_delay = latch – launch – t su requirement
The delay value is the difference between the period of the clock source of the register
and the tSU Requirement value, as shown in Figure 8–24.
Figure 8–24. tSU Requirement
Other Device
FPGA
t su
clk
Input Delay
The delay value for the set_max_delay command is the tSU Requirement value.
Equation 8–4 shows the derivation of this conversion.
Equation 8–4.
required – arrival  0
required = latch + board.dstclk + dst.clk – dst.utsu
arrival = launch + board.srcclk + src.clk + src.utco + src.out + srctodst + dst.in
max_delay = latch + board.dstclk + – launch – board.srcclk – src.clk – src.out – srctodst
required = max_delay + dst.clk – dst.utsu
arrival = dst.in
 max_delay + dst.clk – dst.utsu  –  dst.in   0
t su requirement – t su  0
actual tsu = dst.in + dst.utsu – dst.clk
t su requirement –  dst.in + dst.utsu – dst.clk   0
set_max_delay = t su requirement
December 2010
Altera Corporation
Quartus II Handbook Version 11.0 Volume 3: Verification
8–32
Chapter 8: Switching to the Quartus II TimeQuest Timing Analyzer
Timing Assignment Conversion
Table 8–6 shows the different ways you can make tSU assignments in the Classic
Timing Analyzer, and the corresponding options for the set_max_delay exception.
Table 8–6. tSU Requirement and set_max_delay Equivalence
tSU Requirement
Options
set_max_delay Options
-to <pin>
-from [get_ports <pin>] -to [get_registers *]
-to <clock>
-from [get_ports *] -to [get_clocks <clock>]
-to <register>
-from [get_ports *] -to [get_registers <register>]
-from <pin> -to
<register>
-from [get_ports <pin>] -to [get_registers <register>]
-from <clock> -to <pin> -from [get_ports <pin>] -to [get_clocks <clock>] (1)
Note to Table 8–6:
(1) If the pin in this assignment feeds registers clocked by the same clock, it is equivalent to the first option,
-to <pin>. If the pin feeds registers clocked by different clocks, use set_input_delay to constrain the paths
properly.
To convert a global tSU assignment to an equivalent SDC exception, use the command
shown in Example 8–10.
Example 8–10. Converting a Global tSU Assignment to an Equivalent SDC Exception
set_max_delay -from [all_inputs] -to [all_registers] <tSU value>
tH Requirement
The tH Requirement specifies the maximum acceptable clock hold time for the input
(data) pin. The QSF variable for the tH Requirement assignment is TH_REQUIREMENT.
You can convert the tH Requirement assignment to the set_min_delay command, or
the set_input_delay command with the -min option. The delay value for the
set_input_delay command is <latch – launch + tH requirement>. Refer to the labeled
paths in Figure 8–25 to understand the names in Equation 8–5 and Equation 8–6.
Figure 8–25. Path Names
src.out
srctodst
dst.in
dst.uth
src.utco
src.clk
board.srcclk
dst.clk
board.dstclk
clk
Quartus II Handbook Version 11.0 Volume 3: Verification
December 2010 Altera Corporation
Chapter 8: Switching to the Quartus II TimeQuest Timing Analyzer
Timing Assignment Conversion
8–33
Equation 8–5 shows the derivation of this calculation.
Equation 8–5.
arrival – required  0
arrival = launch + board.srcclk + src.clk + src.utco + src.out + srctodst + dst.in
required = latch + board.dstclk + dst.clk + dst.uth
input_delay = board.srcclk + src.clk + srcutcu + src.out + srctodst – board.dstclk
arrival = launch + input_delay + dst.in
required = latch + dst.clk + dst.uth
 launch + input_delay + dst.in  –  latch + dst.clk + dst.uth   0
t H requirement – actual t H  0
actual tH = dst.clk + dst.uth – dst.in
t H requirement –  dst.clk + dst.uth – dst.in   0
t H requirement = launch – latch + input_delay
input_delay = latch – launch + t H requirement
The delay value for the set_min_delay command is the tH Requirement value.
Equation 8–6 shows the derivation of this conversion.
Equation 8–6.
arrival – required  0
arrival = dst.in
required = min_delay + dst.clk + dst.uth
dst.in –  min_delay + dst.clk + dst.uth 
t H requirement – actual t H  0
actual tH = dst.clk + dst.uth – dst.in
t H requirement –  dst.clk + dst.uth – dst.in   0
set_min_delay = – t H requirement
December 2010
Altera Corporation
Quartus II Handbook Version 11.0 Volume 3: Verification
8–34
Chapter 8: Switching to the Quartus II TimeQuest Timing Analyzer
Timing Assignment Conversion
Table 8–7 shows the different ways you can make tH assignments in the Classic
Timing Analyzer, and the corresponding options for the set_min_delay command.
Table 8–7. tH Requirement and set_min_delay Equivalence
tH Requirement Options
set_min_delay Options
-to <pin>
-from [get_ports <pin>] -to [get_registers *]
-to <clock>
-from [get_ports *] -to [get_clocks <clock>]
-to <register>
-from [get_ports *] -to [get_registers <register>]
-from <pin> -to <register>
-from [get_ports <pin>] -to [get_registers <register>]
-from <clock> -to <pin>
-from [get_ports <pin>] -to [get_clocks <clock>] (1)
Note to Table 8–7:
(1) If the pin in this assignment feeds registers clocked by the same clock, it is equivalent to the first option, -to <pin>. If the pin feeds registers
clocked by different clocks, use set_input_delay to constrain the paths properly. Refer to“Input and Output Delay” on page 8–29 for
additional information.
To convert a global tH assignment to an equivalent SDC exception, use the command
shown in Example 8–11.
Example 8–11. Converting a Global tH Assignment to an Equivalent SDC Exception
set_min_delay -from [all_inputs] -to [all registers] <negative tH value>
tCO Requirement
The tCO Requirement assignment specifies the maximum acceptable clock to output
delay to the output pin. The QSF variable for the tCO Requirement assignment is
TCO_REQUIREMENT. You can convert the tCO Requirement assignment to the
set_max_delay command or the set_output_delay command with the -max option.
The delay value for the set_output_delay command is <latch – launch – tCO
requirement>. Refer to the labeled paths in Figure 8–26 to understand the names in
Equation 8–7 and Equation 8–8.
Figure 8–26. Path Names
src.out
srctodst
dst.in
dst.utsu
src.utco
src.clk
board.srcclk
dst.clk
board.dstclk
clk
Quartus II Handbook Version 11.0 Volume 3: Verification
December 2010 Altera Corporation
Chapter 8: Switching to the Quartus II TimeQuest Timing Analyzer
Timing Assignment Conversion
8–35
Equation 8–7 shows the derivation of this conversion.
Equation 8–7.
required – arrival  0
required = latch – output_delay
arrival = launch + src.clk + src.utco + src.out
output_delay = srctodst + dst.in + dst.utsu – dst.clk – board.dstc.k + board.srcclk
 latch – output_delay  –  launch + src.clk + src.utco + src.out   0
t co requirement – actual t co  0
actual tco = launch + src.clk + src.utco + src.out
t co requirement –  src.clk + src.utco + src.out   0
t co requirement = latch – launch – output_delay
output_delay = latch – launch – t co requirement
The delay value is the difference between the period of the clock source of the register
and the tCO Requirement value, as illustrated in Figure 8–27.
Figure 8–27. tCO Requirement
FPGA
Other Device
clk
t co
Output Delay
The delay value for the set_max_delay command is the tCO Requirement value.
Equation 8–8 shows the derivation of this conversion.
Equation 8–8.
required – arrival  0
required = set_max_delay
arrival = src.clk + src.utco + src.out
set_max_delay –  src.clk + src.utco + src.out   0
t co requirement – actual t co  0
actual tco = src.clk + src.utco + src.out
t co requirement –  src.clk + src.utco + src.out   0
set_max_delay = t co requirement
December 2010
Altera Corporation
Quartus II Handbook Version 11.0 Volume 3: Verification
8–36
Chapter 8: Switching to the Quartus II TimeQuest Timing Analyzer
Timing Assignment Conversion
Table 8–8 shows the different ways you can make tCO assignments in the Classic
Timing Analyzer, and the corresponding options for the set_max_delay exception.
Table 8–8. tCO Requirement and set_max_delay Equivalence
tCO Requirement Options
set_max_delay Options
-to <pin>
-from [get_registers *] -to [get_ports <pin>]
-to <clock>
-from [get_clocks <clock>] -to [get_ports *]
-to <register>
-from [get_registers <register>] -to [get_ports *]
-from <register> -to <pin>
-from [get_registers <register>] -to [get_ports <pin>]
-from <clock> -to <pin>
-from [get_clocks <clock>] -to [get_ports <pin>] (1)
Note to Table 8–8:
(1) If the pin in this assignment feeds registers clocked by the same clock, it is equivalent to the first option,
-to <pin>. If the pin feeds registers clocked by different clocks, you should use set_output_delay to
constrain the paths properly.
To convert a global tCO assignment to an equivalent SDC exception, use the command
in Example 8–12.
Example 8–12. Converting a Global tCO Assignment to an Equivalent SDC Exception
set_max_delay -from [all registers] -to [all_outputs] <tCO value>
Minimum tCO Requirement
The Minimum tCO Requirement assignment specifies the minimum acceptable clock
to output delay to the output pin. The QSF variable for the Minimum tCO
Requirement assignment is MIN_TCO_REQUIREMENT. You can convert the Minimum tCO
Requirement assignment to the set_min_delay command or the set_output_delay
command with the -min option. The delay value for the set_output_delay command
is <latch – launch – minimum tCO requirement>. Refer to the labeled paths in Figure 8–28
to understand the names in Equation 8–9 and Equation 8–10.
Figure 8–28. Path Names
src.out
srctodst
dst.in
dst.uth
src.utco
src.clk
board.srcclk
dst.clk
board.dstclk
clk
Quartus II Handbook Version 11.0 Volume 3: Verification
December 2010 Altera Corporation
Chapter 8: Switching to the Quartus II TimeQuest Timing Analyzer
Timing Assignment Conversion
8–37
Equation 8–9 shows the derivation of this conversion.
Equation 8–9.
arrival + required  0
arrival = launch + src.clk + src.utco + src.out
required = latch – output_delay
output_delay = srctodst + dst.in – dst.uth – dst.clk – board.dstclk + board.srcclk
 launch + src.clk + src.utco + src.out  –  latch – output_delay   0
minimum t co – minimum t co requirement  0
minimum t co = launch + src.clk + src.utco + src.out
 launch + src.clk + src.utco + src.out  – minimum t co requirement  0
minimum t co requirement = latch – launch – output_delay
output_delay = latch – launch – minimum t co requirement
The delay value for the set_min_delay command is the Minimum tCO Requirement.
Equation 8–10 shows the derivation of this conversion.
Equation 8–10.
arrival – required  0
arrival = src.clk + src.utco + src.out
required = min_delay
 src.clk + src.utco + src.out  –  set_min_delay   0
minimum t co – minimum t co requirement  0
minimum t co = src.clk + src.utco + src.out
 src.clk + src.utco + src.out  – minimum t co requirement  0
set_min_delay = minimum tco requirement
December 2010
Altera Corporation
Quartus II Handbook Version 11.0 Volume 3: Verification
8–38
Chapter 8: Switching to the Quartus II TimeQuest Timing Analyzer
Timing Assignment Conversion
Table 8–9 shows the different ways you can make minimum tCO assignments in the
Classic Timing Analyzer, and the corresponding options for the set_min_delay
exception.
Table 8–9. Minimum tCO Requirement and set_min_delay Equivalence
Minimum tCO Requirement Options
set_min_delay Options
-to <pin>
-from [get_registers *] -to [get_ports <pin>]
-to <clock>
-from [get_clocks <clock>] -to [get_ports *]
-to <register>
-from [get_registers <register>] -to [get_ports *]
-from <register> -to <pin>
-from [get_registers <register>] -to [get_ports <pin>]
-from <clock> -to <pin>
-from [get_clocks <clock>] -to [get_ports <pin>] (1)
Note to Table 8–9:
(1) If the pin in this assignment feeds registers clocked by the same clock, it is equivalent to the first option, -to <pin>. If the pin feeds registers
clocked by different clocks, use set_output_delay to constrain the paths properly.
To convert a global Minimum tCO Requirement to an equivalent SDC exception, use
the command shown in Example 8–13.
Example 8–13. Converting a Global Minimum tCO Requirement to an Equivalent SDC Exception
set_min_delay -from [all_registers] -to [all_outputs] <minimum tCO value>
tPD Requirement
The tPD Requirement assignment specifies the maximum acceptable input to
nonregistered output delay, that is, the time required for a signal from an input pin to
propagate through combinational logic and appear at an output pin. The QSF variable
for the tPD Requirement assignment is TPD_REQUIREMENT. You can use the
set_max_delay command in the TimeQuest analyzer as an equivalent constraint as
long as you account for input and output delays. The tPD Requirement assignment
does not take into account input and output delays, but the set_max_delay exception
does, so you must modify the set_max_delay value to take into account input and
output delays.
Combinational Path Delay Scenario
Figure 8–29 shows a circuit to illustrate the following example of converting a tPD
Requirement to a set_max_delay constraint.
Figure 8–29. tPD Example
comb_out
reg_out
a_in
b_in
clk
Quartus II Handbook Version 11.0 Volume 3: Verification
December 2010 Altera Corporation
Chapter 8: Switching to the Quartus II TimeQuest Timing Analyzer
Timing Assignment Conversion
8–39
Assume the circuit has the following assignments in the Classic Timing Analyzer:
■
Clock period of 10 ns
■
tPD Requirement from a_in to comb_out of 10 ns
■
Input Max Delay on a_in relative to clk of 2 ns
■
Output Max Delay on comb_out relative to clk of 2 ns
The path from a_in to comb_out is not affected by the input and output delays. The
slack is equal to the <tPD Requirement from a_in to comb_out> – <path delay from a_in to
comb_out>.
Assume the circuit has the SDC constraints shown in Example 8–14 in the TimeQuest
analyzer.
Example 8–14. SDC Constraints
create_clock -period 10 –name clk [get_ports clk]
set_max_delay -from a_in -to comb_out 10
set_input_delay -clk clk 2 [get_ports a_in]
set_output_delay –clk clk 2 [get_ports comb_out]
The path from a_in to comb_out is affected by the input and output delays. The slack
is equal to:
<set_max_delay value from a_in to comb_out> – <input delay> – <output delay> – <path
delay from a_in to comb_out>
To convert a global tPD Requirement assignment to an equivalent SDC exception, use
the command shown in Example 8–15. You should add the input and output delays to
the value of your converted tPD Requirement (set_max_delay exception value) to
achieve an equivalent SDC exception.
Example 8–15. Converting a Global tPD Requirement Assignment to an Equivalent SDC Exception
set_max_delay -from [all_inputs] -to [all_outputs] <value>
December 2010
Altera Corporation
Quartus II Handbook Version 11.0 Volume 3: Verification
8–40
Chapter 8: Switching to the Quartus II TimeQuest Timing Analyzer
Timing Assignment Conversion
Minimum tPD Requirement
The Minimum tPD Requirement assignment specifies the minimum acceptable input
to nonregistered output delay, that is, the minimum time required for a signal from an
input pin to propagate through combinational logic and appear at an output pin. The
QSF variable for the Minimum tPD Requirement assignment is MIN_TPD_REQUIREMENT.
You can use the set_min_delay command in the TimeQuest analyzer as an equivalent
constraint as long as you account for input and output delays. The Minimum tPD
Requirement assignment does not take into account input and output delays, but the
set_min_delay exception does.
Refer to “Combinational Path Delay Scenario” on page 8–38 to see how input and
output delays affect minimum and maximum delay exceptions.
To convert a global Minimum tPD Requirement assignment to an equivalent SDC
exception, use the command shown in Example 8–16.
Example 8–16. Converting a Global Minimum tPD Requirement Assignment to an Equivalent SDC
Exception
set_min_delay -from [all_inputs] -to [all_outputs] <value>
Cut Timing Path
The Cut Timing Path assignment in the Classic Timing Analyzer is equivalent to the
set_false_path command in the TimeQuest analyzer. The QSF variable for the Cut
Timing Path assignment is CUT.
Maximum Delay
The Maximum Delay assignment specifies the maximum required delay for the
following types of paths:
■
Pins to registers
■
Registers to registers
■
Registers to pins
The QSF variable for the Maximum Delay assignment is MAX_DELAY. This overwrites
the requirement computed from the clock setup relationship and clock skew. There is
no equivalent constraint in the TimeQuest analyzer.
1
The Maximum Delay assignment for the Classic Timing Analyzer is not related to the
set_max_delay exception in the TimeQuest analyzer.
Quartus II Handbook Version 11.0 Volume 3: Verification
December 2010 Altera Corporation
Chapter 8: Switching to the Quartus II TimeQuest Timing Analyzer
Timing Assignment Conversion
8–41
Minimum Delay
The Minimum Delay assignment specifies the minimum required delay for the
following types of paths:
■
Pins to registers
■
Registers to registers
■
Registers to pins
The QSF variable for the Minimum Delay assignment is MIN_DELAY. This overwrites
the requirement computed from the clock hold relationship and clock skew. There is
no equivalent constraint in the TimeQuest analyzer.
1
The Minimum Delay assignment for the Classic Timing Analyzer is not related to the
set_min_delay exception in the TimeQuest analyzer.
Maximum Clock Arrival Skew
The Maximum Clock Arrival Skew assignment specifies the maximum clock skew
between a set of registers. The QSF variable for the Maximum Clock Arrival Skew
assignment is MAX_CLOCK_ARRIVAL_SKEW. In the Classic Timing Analyzer, this
assignment is specified between a clock node name and a set of registers. Maximum
Clock Arrival Skew is not supported in the TimeQuest analyzer.
Maximum Data Arrival Skew
The Maximum Data Arrival Skew assignment specifies the maximum data arrival
skew between a set of registers, pins, or both. The QSF variable for the Maximum
Data Arrival Skew assignment is MAX_DATA_ARRIVAL_SKEW. In this case, the data
arrival delay represents the tCO from the clock to the given register, pin, or both. This
assignment is specified between a clock node and a set of registers, pins, or both.
The TimeQuest analyzer does not support a constraint to specify maximum data
arrival skew, but you can specify setup and hold times relative to a clock port to
constrain an interface like this. Figure 8–30 shows a simplified source-synchronous
interface used in the following example.
Figure 8–30. Source-Synchronous Interface Diagram
data_in
clk_in
Input Controller
PLL
Output Controller
data_out
clk_out
Constraining Skew on an Output Bus
This example constrains the interface so that all bits of the data_out bus go off-chip
between 2 ns and 3 ns after the clk_out signal. Assume that clk_in and clk_out have
a period of 8 ns.
December 2010
Altera Corporation
Quartus II Handbook Version 11.0 Volume 3: Verification
8–42
Chapter 8: Switching to the Quartus II TimeQuest Timing Analyzer
Timing Assignment Conversion
The following equations and example show how to create timing requirements that
satisfy the timing relationships shown in Figure 8–31.
Figure 8–31. Source-Synchronous Timing Diagram
clk_out
data_out
0
2
3
4
8
10
11
12
Equation 8–11 shows how to compute the value for the set_output_delay -min
command that creates the 2 ns hold requirement on the destination. For hold
requirement calculations in which source and destination clocks are the same,
<latch> – <launch> = 0.
Equation 8–11.
latch – launch = 0ns
output delay = latch – launch – 2ns
output delay = – 2ns
Equation 8–12 shows how to compute the value for the set_output_delay command
that creates the 3 ns setup requirement on the destination. For setup requirement
calculations in which source and destination clocks are the same, <latch> – <launch> =
clock period.
Equation 8–12.
latch – launch = 8ns
output delay = latch – launch – 3ns
output delay = 5ns
Refer to “I/O Constraints” on page 8–28 for an explanation of the above equations.
Example 8–17 shows the three constraints together.
Example 8–17. Constraining a DDR Interface
set period 8.000
create_clock -period $period \
-name clk_in \
[get_ports data_out*]
derive_pll_clocks
set_output_delay -add_delay \
-clock ddr_pll_1_inst|altpll_component|pll|CLK[0] \
-reference_pin [get_ports clk_out] \
-min -2.000 \
[get_ports data_out*]
set_output_delay -add_delay \
-clock ddr_pll_1_inst|altpll_component|pll|CLK[0] \
-reference_pin [get_ports clk_out] \
-max [expr $period - 3.000] \
[get_ports data_out*]
Quartus II Handbook Version 11.0 Volume 3: Verification
December 2010 Altera Corporation
Chapter 8: Switching to the Quartus II TimeQuest Timing Analyzer
Conversion Utility
8–43
Conversion Utility
The TimeQuest analyzer includes a conversion utility to help you convert Classic
Timing Analyzer assignments in a .qsf to SDC constraints in an .sdc The utility can
use information from your project report database (in the \db folder), if it exists, so
you should compile your design before the conversion.
1
The conversion utility ignores all disabled QSF assignments. Disabled assignments
show No in the Enabled column of the Assignment Editor, and include the -disable
option in the .qsf.
Refer to “Create SDC Constraints from Existing Timing Assignments” on page 8–2 to
learn how to run the conversion utility.
Unsupported Global Assignments
The conversion utility checks whether any of the global timing assignments in
Table 8–10 exist in your project. Any global assignments not supported by the
conversion utility are ignored during the conversion. Refer to the indicated page for
information about each assignment, and how to manually convert these global
assignments to SDC commands.
Table 8–10. Global Timing Assignments
Assignment Name
QSF Variable
More Information
tSU Requirement
TSU_REQUIREMENT
page 8–30
tH Requirement
TH_REQUIREMENT
page 8–32
tCO Requirement
TCO_REQUIREMENT
page 8–34
Minimum tCO Requirement
MIN_TCO_REQUIREMENT
page 8–36
tPD Requirement
TPD_REQUIREMENT
page 8–38
Minimum tPD Requirement
MIN_TPD_REQUIREMENT
page 8–40
Recommended Global Assignments
When any unsupported assignments have been identified, the conversion utility
checks the global assignments in Table 8–11 to ensure they match the specified values.
Table 8–11. Recommended Global Assignments
Classic Timing Analyzer Assignment Name
QSF Variable
Value
Cut off clear and preset signal paths
CUT_OFF_CLEAR_AND_PRESET_PATHS
ON
Cut off feedback from I/O pins
CUT_OFF_IO_PIN_FEEDBACK
ON
Cut off read during write signal paths
CUT_OFF_READ_DURING_WRITE_PATHS
ON
Analyze latches as synchronous elements
ANALYZE_LATCHES_AS_SYNCHRONOUS_ELEMENTS
ON
Enable Clock Latency
ENABLE_CLOCK_LATENCY
ON
Display Entity Name
PROJECT_SHOW_ENTITY_NAME
ON
December 2010
Altera Corporation
Quartus II Handbook Version 11.0 Volume 3: Verification
8–44
Chapter 8: Switching to the Quartus II TimeQuest Timing Analyzer
Conversion Utility
The following assignments are checked to ensure the functionality of the Classic
Timing Analyzer with the specified values corresponding to the behavior of the
TimeQuest analyzer.
■
Cut off clear and preset signal paths— The TimeQuest analyzer does not support
this functionality. You should use Recovery and Removal analysis instead to
analyze register control paths. The Classic Timing Analyzer does not support this
option.
■
Cut off feedback from I/O pins—The TimeQuest analyzer does not match the
functionality of the Classic Timing Analyzer when this assignment is set to OFF.
■
Cut off read during write signal paths—The TimeQuest analyzer does not match
the functionality of the Classic Timing Analyzer when this assignment is set to OFF.
■
Analyze latches as synchronous elements—The TimeQuest analyzer analyzes
latches as synchronous elements by default and does not match the functionality
of the Classic Timing Analyzer when this assignment is set to OFF. The Classic
Timing Analyzer analyzes latches as synchronous elements by default.
■
Enable Clock Latency—The TimeQuest analyzer includes clock latency in its
calculations. The TimeQuest analyzer does not match the functionality of the
Classic Timing Analyzer when this assignment is set to OFF. Latency on a clock can
be viewed as a simple delay on the clock path, and affects clock skew. This is in
contrast to an offset, which alters the setup and hold relationship between two
clocks. Refer to “Offset and Latency Example” on page 8–11 for an example of the
different effects of offset and latency. When you turn on Enable Clock Latency in
the Classic Timing Analyzer, it affects the following aspects of timing analysis:
■
■
Early Clock Latency and Late Clock Latency assignments are honored
■
The compensation delay of a PLL is analyzed as latency
■
For clock settings where you do not specify an offset, the automatically
computed offset is treated as latency
Display Entity Name—Any entity-specific assignments are ignored in the
TimeQuest analyzer because they do not include the entity name when this option
is set to ON.
If your design meets timing requirements in the Classic Timing Analyzer without all
of the settings recommended in Table 8–11 on page 8–43, you should perform one of
the following actions:
■
Change the settings and reconstrain and reverify as necessary.
or
■
Add or modify SDC constraints as appropriate because analysis in the TimeQuest
analyzer may be different after conversion.
Quartus II Handbook Version 11.0 Volume 3: Verification
December 2010 Altera Corporation
Chapter 8: Switching to the Quartus II TimeQuest Timing Analyzer
Conversion Utility
8–45
Clock Conversion
Next, the conversion utility adds the derive_pll_clocks command to the .sdc. This
command creates generated clocks on all PLL outputs in your design each time the
.sdc is read. The command does not add a clock on the FPGA port that drives the PLL
input.
The conversion utility includes the derive_pll_clocks -use_net_name command in
the .sdc it creates. The -use_net_name option overrides the default clock naming
behavior (the PLL pin name) so the clock name is the same as the net name in the
Classic Timing Analyzer.
Including the -use_net_name option ensures that the conversion utility converts
clock-to-clock exceptions properly. If you remove the -use_net_name option, you must
also edit references to the clock names in other SDC commands so they match the PLL
pin names.
If your design includes a global fMAX assignment, the assignment is converted to a
derive_clocks command. The behavior of a global fMAX assignment is different from
the behavior of clocks created with the derive_clocks command, and you should use
the report_clocks command when you review conversion results to evaluate the
clock settings. Refer to “Automatic Clock Detection” on page 8–14 for an explanation
of the differences. As soon as you know the appropriate clock settings, you should use
the create_clock or create_generated_clock command instead of the
derive_clocks command.
1
The conversion utility adds a post_message command before the derive_clocks
command to remind you that the clocks are derived automatically. The TimeQuest
analyzer displays the reminder the first time it reads the .sdc. Remove or comment
out the post_message command to prevent the message from displaying.
Next, the conversion utility identifies and converts clock settings in the .qsf. If a
project database exists, the utility also identifies and converts any additional clocks in
the report file that are not in the .qsf, such as PLL base clocks.
1
If you change the PLL input frequency, you must modify the SDC constraint
manually.
The conversion utility ignores clock offsets on generated clocks. Refer to “Clock
Offset” on page 8–10 for information about how to use offset values in the TimeQuest
analyzer.
December 2010
Altera Corporation
Quartus II Handbook Version 11.0 Volume 3: Verification
8–46
Chapter 8: Switching to the Quartus II TimeQuest Timing Analyzer
Conversion Utility
Instance Assignment Conversion
Next, the conversion utility converts the instance assignments shown in Table 8–12.
Refer to the indicated page for information about each assignment.
Table 8–12. Instance Timing Assignments
Assignment Name
QSF Variable
Late Clock Latency
LATE_CLOCK_LATENCY
Early Clock Latency
EARLY_CLOCK_LATENCY
Clock Setup Uncertainty
CLOCK_SETUP_UNCERTAINTY
Clock Hold Uncertainty
CLOCK_HOLD_UNCERTAINTY
Multicycle (1)
MULTICYCLE
Source Multicycle (2)
SRC_MULTICYCLE
Multicycle Hold (3)
HOLD_MULTICYCLE
Source Multicycle Hold
SRC_HOLD_MULTICYCLE
Clock Enable Multicycle
CLOCK_ENABLE_MULTICYCLE
Clock Enable Source Multicycle
CLOCK_ENABLE_SOURCE_MULTICYCLE
Clock Enable Multicycle Hold
CLOCK_ENABLE_MULTICYCLE_HOLD
Clock Enable Source Multicycle Hold
CLOCK_ENABLE_SOURCE_MULTICYCLE_HOLD
Cut Timing Path
CUT
Input Maximum Delay
INPUT_MAX_DELAY
Input Minimum Delay
INPUT_MIN_DELAY
Output Maximum Delay
OUTPUT_MAX_DELAY
Output Minimum Delay
OUTPUT_MIN_DELAY
More Information
page 8–25
page 8–25
page 8–27
page 8–28
page 8–40
page 8–29
Notes to Table 8–12:
(1) A multicycle assignment can also be known as a “destination multicycle setup” assignment.
(2) A source multicycle assignment can also be known as a “source multicycle setup” assignment.
(3) A multicycle hold can also be known as a “destination multicycle hold” assignment.
Depending on input and output delay assignments, you may receive a warning
message when the .sdc is read. The message warns that the set_input_delay
command, set_output_delay command, or both are missing the -max option, -min
option, or both. Refer to “Input and Output Delay” on page 8–29 for an explanation of
why the warning occurs and how to avoid it.
The conversion utility automatically adds multicycle hold exceptions for each
multicycle setup assignment. The value of each multicycle hold exception depends on
the Default hold multicycle assignment value in your project. If the value is One, the
conversion utility uses a value of 0 (zero) for each multicycle hold exception it adds. If
the value is Same as multicycle, the conversion utility uses a value one less than the
corresponding multicycle setup assignment value for each multicycle hold exception
it adds. Refer to “Hold Multicycle” on page 8–18 for more information on hold
multicycle differences between the Classic Timing Analyzer and the TimeQuest
analyzer.
Quartus II Handbook Version 11.0 Volume 3: Verification
December 2010 Altera Corporation
Chapter 8: Switching to the Quartus II TimeQuest Timing Analyzer
Conversion Utility
8–47
Next, the conversion utility converts the instance assignments shown in Table 8–13.
Refer to the indicated page for information about each assignment. If the tPD and
minimum tPD assignment targets also have input or output delays that apply to them,
the tPD and minimum tPD conversion values may be incorrect. This is described in
more detail on the indicated pages for the appropriate assignments.
Table 8–13. Instance Timing Assignments
Assignment Name
QSF Variable
More Information
tPD Requirement (1)
TPD_REQUIREMENT
page 8–38
Minimum tPD Requirement (1)
MIN_TPD_REQUIREMENT
page 8–40
Setup Relationship
SETUP_RELATIONSHIP
page 8–24
Hold Relationship
HOLD_RELATIONSHIP
page 8–25
Note to Table 8–13:
(1) Refer to “tPD and Minimum tPD Requirement Conversion” on page 8–55 for more information about how the
conversion utility converts single-point tPD and minimum tPD assignments.
The conversion utility converts Classic Timing Analyzer I/O timing assignments to
FPGA-centric SDC constraints. Table 8–14 includes Classic Timing Analyzer timing
assignments, the equivalent FPGA-centric SDC constraints, and recommended
system-centric SDC constraints.
Table 8–14. Classic Timing Analyzer and TimeQuest Analyzer Equivalent Constraints
Classic Timing Analyzer
Assignment
FPGA-Centric SDC
System-Centric SDC
More Information
tSU Requirement (1)
set_max_delay
set_input_delay -max
page 8–30
tH Requirement (1)
set_min_delay
set_input_delay -min
page 8–32
tCO Requirement (2)
set_max_delay
set_output_delay -max
page 8–34
Minimum tCO Requirement (2)
set_min_delay
set_output_delay -min
page 8–36
Notes to Table 8–14:
(1) Refer to “tPD and Minimum tPD Requirement Conversion” on page 8–55 for more information about how the conversion utility converts this type
of assignment.
(2) Refer to “tCO Requirement Conversion” on page 8–49 for more information about how the conversion utility converts this type of assignment.
The conversion utility can convert Classic Timing Analyzer I/O timing assignments
only to the FPGA-centric constraints without additional information about your
design. Making system-centric constraints requires information about the external
circuitry interfacing with the FPGA such as external clocks, clock latency, board delay,
and clocking exceptions. You cannot convert Classic Timing Analyzer timing
assignments to system-centric constraints without that information. If you use the
conversion utility, you can modify the SDC constraints to change the FPGA-centric
constraints to system-centric constraints as appropriate.
December 2010
Altera Corporation
Quartus II Handbook Version 11.0 Volume 3: Verification
8–48
Chapter 8: Switching to the Quartus II TimeQuest Timing Analyzer
Conversion Utility
PLL Phase Shift Conversion
The conversion utility does not account for PLL phase shifts when it converts values
of the following FPGA-centric I/O timing assignments:
■
tSU Requirement
■
tH Requirement
■
tCO Requirement
■
Minimum tCO Requirement
If any of your paths go through PLLs with a phase shift, you must correct the
converted values for those paths according to the formula in Equation 8–13:
Equation 8–13.
<pll output period>  <phase shift> 
<correct value> = <converted value> – ------------------------------------------------------------------------------------------360
Example 8–18 shows the incorrect conversion result for a tCO assignment and how to
correct it. For the example, assume the PLL output frequency is 200 MHz (period is
5 ns), the phase shift is 90 degrees, the tCO Requirement value is 1 ns, and it is made
to data[0]. The .qsf contains the following assignment:
Example 8–18. Assignment
set_instance_assignment -name TCO_REQUIREMENT -to data[0] 1.0
The conversion utility generates the SDC command shown in Example 8–19.
Example 8–19. SDC Command
set_max_delay -from [get_registers *] -to [get_ports data[0]] 1.0
To correct the value, use the formula and values above, as shown in the following
equation:
 5  90 
1.0 – -------------------- = – 0.25
360
Then, change the value so the SDC command so that it looks like Example 8–20.
Example 8–20. SDC Command with Correct Values
set_max_delay -from [get_registers *] -to [get_ports data[0]] -0.25
Quartus II Handbook Version 11.0 Volume 3: Verification
December 2010 Altera Corporation
Chapter 8: Switching to the Quartus II TimeQuest Timing Analyzer
Conversion Utility
8–49
tCO Requirement Conversion
The conversion utility uses a special process to convert tCO Requirement and
Minimum tCO Requirement assignments. In addition to the set_max_delay or
set_min_delay commands, the conversion utility adds a set_output_delay constraint
relative to a virtual clock named N/C (Not a Clock). It also creates the virtual clock
named N/C with a period of 10 ns. Adding the virtual clock allows you to report
timing on the output paths. Without the virtual clock N/C, the clock used for
reporting would be blank. Example 8–21 shows how the conversion utility converts a
tCO Requirement assignment of 5.0 ns to data[0].
Example 8–21. Converting a tCO Requirement Assignment of 5.0 ns to data[0]
set_max_delay -from [get_registers *] -to [get_ports data[0]] 5.0
set_output_delay -clock "N/C" 0 [get_ports data[0]]
Entity-Specific Assignments
Next, the conversion utility converts the entity-specific assignments listed in
Table 8–15 that exist in the Timing Analyzer Settings report panel. This usually
occurs if you have any timing assignments in your Verilog HDL or VHDL source,
which can include MegaCore function files. These entity-specific assignments cannot
be automatically converted unless your project is compiled and a \db directory exists.
Table 8–15. Entity-Specific Timing Assignments
Classic Timing Analyzer
Assignment
1
QSF Variable
More Information
Multicycle
MULTICYCLE
Source Multicycle
SRC_MULTICYCLE
Multicycle Hold
HOLD_MULTICYCLE
Source Multicycle Hold
SRC_HOLD_MULTICYCLE
Setup Relationship
SETUP_RELATIONSHIP
page 8–24
Hold Relationship
HOLD_RELATIONSHIP
page 8–25
Cut Timing Path
CUT
page 8–40
page 8–27
You must manually convert all other entity-specific timing assignments.
Paths Between Unrelated Clock Domains
The conversion utility can create exceptions that cut paths between unrelated clock
domains, which matches the default behavior of the Classic Timing Analyzer. When
Cut paths between unrelated clock domains is turned on, the conversion utility
creates clock groups with the set_clock_groups command and uses the -exclusive
option to cut paths between the clock groups.
December 2010
Altera Corporation
Quartus II Handbook Version 11.0 Volume 3: Verification
8–50
Chapter 8: Switching to the Quartus II TimeQuest Timing Analyzer
Conversion Utility
Unsupported Instance Assignments
Finally, the conversion utility checks for the unsupported instance assignments listed
in Table 8–16 and warns you if any exist. Refer to the indicated page for information
about each assignment.
1
You can manually convert some of the assignments to SDC constraints.
Table 8–16. Instance Timing Assignments
Assignment Name
QSF Variable
More
Information
Inverted Clock
INVERTED_CLOCK
page 8–25
Maximum Clock Arrival Skew
MAX_CLOCK_ARRIVAL_SKEW
page 8–41
Maximum Data Arrival Skew
MAX_DATA_ARRIVAL_SKEW
page 8–41
Maximum Delay
MAX_DELAY
page 8–40
Minimum Delay
MIN_DELAY
page 8–41
Virtual Clock Reference
VIRTUAL_CLOCK_REFERENCE
page 8–26
Reviewing Conversion Results
You must review the messages that are generated during the conversion process, and
review the .sdc file for correctness and completeness. Warning and critical warning
messages identify significant differences between the Classic Timing Analyzer and
TimeQuest analyzer behaviors. In some cases, warning messages indicate that the
conversion utility ignored assignments because it could not determine the intended
functionality of your design. You must add to or modify the SDC constraints as
necessary based on your knowledge of the design.
The conversion utility creates an .sdc with the same name as your current revision,
<revision>.sdc, and it overwrites any existing <revision>.sdc. If you use the conversion
utility to create an .sdc, you should make additions or corrections in a separate .sdc, or
a copy of the .sdc created by the conversion utility. That way, you can rerun the
conversion utility later without overwriting your additions and changes. If you have
constraints in multiple .sdc files, refer to“Constraint File Priority” on page 8–7 to learn
how to add constraints to your project.
Warning Messages
The conversion utility may generate any of the following warning messages. Refer to
the information provided for each warning message to learn what to do in that
instance.
Ignored QSF Variable <assignment>
The conversion utility ignored the specified assignment. Determine whether an
equivalent constraint is necessary and manually add one if appropriate. Refer to
“Timing Assignment Conversion” on page 8–24 for information about conversions for
all QSF timing assignments.
Quartus II Handbook Version 11.0 Volume 3: Verification
December 2010 Altera Corporation
Chapter 8: Switching to the Quartus II TimeQuest Timing Analyzer
Conversion Utility
8–51
Global <name> = <value>
The conversion utility ignored the global assignment <name>. Manually add an
equivalent constraint if appropriate. Refer to “Unsupported Global Assignments” on
page 8–43 for information about conversions for these assignments.
QSF: Expected <name> to be set to <expected value> but it is set to <actual value>
The behavior of the TimeQuest analyzer is closest to the Classic Timing Analyzer
when the value for the specified assignment is the expected value. Because the actual
assignment value is not the expected value in your project, the TimeQuest analyzer
analysis may be different from the Classic Timing Analyzer analysis. Refer to
“Recommended Global Assignments” on page 8–43 for an explanation about the
indicated QSF variable names.
QSF: Found Global FMAX Requirement. Translation will be done using derive_clocks
Your design includes a global fMAX requirement, and the requirement is converted to
the derive_clocks command. Refer to “Default Required fMAX Assignment” on
page 8–26 for information about how to convert to an SDC constraint.
TAN Report Database not found. HDL based assignments will not be migrated
You did not analyze your design with the Classic Timing Analyzer before running the
conversion utility. As a result, the conversion utility did not convert any timing
assignments in your HDL source code to SDC constraints. If you have timing
assignments in your HDL source code, you must find and convert them manually, or
analyze your design with the Classic Timing Analyzer and rerun the conversion
utility.
Ignored Entity Assignment (Entity <entity>): <variable> = <value> -from <from> -to <to>
The conversion utility ignored the specified entity assignment because the utility
cannot automatically convert the assignment. Table 8–15 on page 8–49 lists the
entity-specific assignments the script can convert automatically.
Refer to “Timing Assignment Conversion” on page 8–24 for information about how to
convert the entity assignment manually.
Ignoring OFFSET_FROM_BASE_CLOCK assignment for clock <clock>
In some cases, this assignment is used to work around a limitation in how the Classic
Timing Analyzer handles some forms of clock inversion. The conversion script
ignores the assignment because it cannot determine whether the assignment is used
as a workaround. Review your clock setting and add the assignment in your .sdc if
appropriate. Refer to “Clock Offset” on page 8–10 for more information about
converting clock offset.
Clock <clock> has no FMAX_REQUIREMENT - No clock was generated
The conversion utility did not convert the clock named <clock> because it has no fMAX
requirement. You should add a clock constraint with an appropriate period to your
.sdc.
No Clock Settings defined in .qsf
If your .qsf has no clock settings, ignore this message. You must add clock constraints
in your .sdc manually.
December 2010
Altera Corporation
Quartus II Handbook Version 11.0 Volume 3: Verification
8–52
Chapter 8: Switching to the Quartus II TimeQuest Timing Analyzer
Conversion Utility
Clocks
Ensure that the conversion utility converted all clock assignments correctly. Run the
report_clocks command, or double-click Report Clocks in the Tasks pane in the
TimeQuest analyzer GUI. Make sure that the right number of clocks is reported. If any
clock constraints are missing, you must add them manually with the appropriate SDC
commands (create_clock or create_generated_clock). Confirm that each option for
each clock is correct.
The TimeQuest analyzer can create more clocks, such as:
■
derive_clocks selecting ripple clocks
■
derive_pll_clocks, adding
■
Extra clocks for PLL switchover
■
Extra clocks for LVDS pulse-generated clocks (~load_reg)
Clock Transfers
After you confirm that all clock assignments are correct, run the
report_clock_transfers command, or double-click Report Clock Transfers in the
Tasks pane in the TimeQuest analyzer GUI. The command generates a summary table
with the number of paths between each clock domain. If the number of cross-clock
domain paths seems high, remember that all clock domains are related in the
TimeQuest analyzer. You must cut unrelated clock domains. Refer to “Related and
Unrelated Clocks” on page 8–10 for information about how to cut unrelated clock
domains.
Path Details
If you have unexpected differences between the Classic Timing Analyzer and the
TimeQuest analyzer on some paths, follow these steps to identify the cause of the
difference.
1. Report timing on the path in the TimeQuest analyzer.
2. Compare slack values.
3. Compare source and destination clocks.
4. Compare the launch/latch times in the TimeQuest analyzer to the setup/hold
relationship in the Classic Timing Analyzer. The times are absolute in the
TimeQuest analyzer and relative in the Classic Timing Analyzer.
5. Compare clock latency values.
Unconstrained Paths
Next, run the report_ucp command, or double-click Report Unconstrained Paths in
the Tasks pane in the TimeQuest analyzer GUI. This command generates a series of
reports that detail any unconstrained paths in your design. If your design was
completely constrained in the Classic Timing Analyzer, but there are unconstrained
paths in the TimeQuest analyzer, some assignments may not have been converted
properly. Also, some of the assignments could be ambiguous. The TimeQuest
analyzer analyzes more paths than the Classic Timing Analyzer does, so any
unconstrained paths might be paths you could not constrain in the Classic Timing
Analyzer.
Quartus II Handbook Version 11.0 Volume 3: Verification
December 2010 Altera Corporation
Chapter 8: Switching to the Quartus II TimeQuest Timing Analyzer
Notes
8–53
Bus Names
If your design includes Classic Timing Analyzer timing assignments to buses, and the
bus names do not include square brackets enclosing an asterisk, such as: address[*],
you should review the SDC constraints to ensure the conversion is correct. Refer to
“Bus Name Format” on page 8–6 for more information.
Other
Review the notes listed in “Conversion Utility” on page 8–55.
Rerunning the Conversion Utility
You can force the conversion utility to run even if it can find an .sdc according to the
priority described in “Constraint File Priority” on page 8–7. Any method described in
“Create SDC Constraints from Existing Timing Assignments” on page 8–2 forces the
conversion utility to run even if it can find an .sdc.
Notes
This section describes notes for the TimeQuest analyzer.
Output Pin Load Assignments
The TimeQuest analyzer takes Output Pin Load values into account when it analyzes
your design. If you change Output Pin Load assignments and do not recompile
before you analyze timing, you must use the -force_dat option when you create the
timing netlist. Type the following command at the Tcl console of the TimeQuest
analyzer:
create_timing_netlist -force_dat r
If you change Output Pin Load assignments and recompile before you analyze
timing, do not use the -force_dat option when you create the timing netlist. You can
create the timing netlist with the create_timing_netlist command, or with the Create
Timing Netlist task in the Tasks pane.
Also note that the SDC set_output_load command is not supported, so you must
make all output load assignments in the .qsf.
Constraint Target Types
The TimeQuest analyzer supports mixed exception types; you can apply an exception
of any clock/node combination.
December 2010
Altera Corporation
Quartus II Handbook Version 11.0 Volume 3: Verification
8–54
Chapter 8: Switching to the Quartus II TimeQuest Timing Analyzer
Notes
DDR Constraints with the DDR Timing Wizard
The DDR Timing Wizard creates an .sdc that contains constraints for a DDR interface.
You can use that .sdc with the TimeQuest analyzer to analyze only the DDR interface
part of a design.
You should use the .sdc created by DDR Timing Wizard for constraining a DDR
interface in the TimeQuest analyzer. Additionally, your .qsf should not contain timing
assignments for the DDR interface if you plan to use the conversion utility to create an
.sdc. You should run the conversion utility before you use DDR Timing Wizard, and
you should choose not to apply assignments to the .qsf.
However, if you used DDR Timing Wizard and chose to apply assignments to a .qsf,
before you used the conversion utility, you should remove the DDR Timing
Wizard-generated QSF timing assignments and rerun the conversion utility. The
conversion utility creates some incompatible SDC constraints from the DDR Timing
Wizard QSF assignments.
Unsupported SDC Features
Some SDC commands and features are not supported by the current version of the
TimeQuest analyzer, including the following commands and features:
■
The get_designs command, because the Quartus II software supports a single
design, so this command is not necessary
■
True latch analysis with time-borrowing feature; it can, however, convert latches to
negative-edge-triggered registers
■
The case analysis feature
■
Loads, clock transitions, input transitions, and other features
Constraint Passing and Optimization
The Quartus II software can read constraints generated by other EDA software, and
write constraints to be read by other EDA software.
Other synthesis software can generate constraints that target the .qsf. If you change
timing constraints in synthesis software after creating an .sdc for the TimeQuest
analyzer, you must update the SDC constraints. You can use the conversion utility, or
update the .sdc manually.
If you use physical synthesis with the TimeQuest analyzer, the design may have lower
performance.
Clock Network Delay Reporting
The TimeQuest analyzer reports delay on the clock network by node-to-node
segments; the Classic Timing Analyzer reports delay on the clock network as a single
number, rather than node-to-node segments
Quartus II Handbook Version 11.0 Volume 3: Verification
December 2010 Altera Corporation
Chapter 8: Switching to the Quartus II TimeQuest Timing Analyzer
Document Revision History
8–55
Project Management
If you use the project_open Tcl command in the TimeQuest analyzer to open a project
compiled with an earlier version of the Quartus II software, the TimeQuest analyzer
overwrites the compilation results (\db folder) without warning. Opening a project
any other way results in a warning, and you can choose not to open the project.
Conversion Utility
This section describes the notes for the QSF assignment to SDC constraint conversion
utility.
tPD and Minimum tPD Requirement Conversion
The conversion utility treats the targets of single-point tPD and minimum tPD
assignments as device outputs. It does not correctly convert targets of single-point tPD
and minimum tPD assignments that are device inputs. The following QSF assignment
applies to an a device input named d_in:
set_intance_assignment -name TPD_REQUIREMENT -to d_in "3 ns"
The conversion utility creates the following SDC command, regardless of whether
d_in is a device input or device output:
set_max_delay "3 ns" -from [get_ports *] -to [get_ports d_in]
You must update any incorrect SDC constraints manually.
f For more detailed information about the features and capabilities of the TimeQuest
analyzer, refer to the Quartus II TimeQuest Timing Analyzer chapter in volume 3 of the
Quartus II Handbook.
Document Revision History
Table 8–17. Document Revision History
Date
Version
December 2010
10.1.0
Changes
■
Changed to new document template.
■
Removed deprecated Classic Timing Analyzer features.
■
Minor updates to content.
July 2010
10.0.0
Minor updates to content.
November 2009
9.1.0
No change to content.
March 2009
9.0.0
This was chapter 8 in version 8.1.
November 2008
8.1.0
Changed to 8-1/2 x 11 page size. No change to content.
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.
December 2010
Altera Corporation
Quartus II Handbook Version 11.0 Volume 3: Verification
8–56
Quartus II Handbook Version 11.0 Volume 3: Verification
Chapter 8: Switching to the Quartus II TimeQuest Timing Analyzer
Document Revision History
December 2010 Altera Corporation
9. Synopsys PrimeTime Support
December 2010
QII53005-10.0.1
QII53005-10.0.1
PrimeTime is the Synopsys stand-alone full chip, gate-level static timing analyzer. The
Quartus® II software makes it easy for designers to analyze their Quartus II projects
using the PrimeTime software. The Quartus II software exports a netlist, design
constraints (in the PrimeTime format), and libraries to the PrimeTime software
environment. Figure 9–1 shows the PrimeTime flow diagram.
Figure 9–1. PrimeTime Software Flow Diagram
The Quartus II Software
Design Netlist
(Verilog HDL or
VHDL Format)
Constraints in
PrimeTime
Format
Standard Delay
Format Output
File (Timing
Information)
The PrimeTime Software
Timing Reports Generated
DB lib
HDL lib
This chapter contains the following sections:
■
“Quartus II Settings for Generating the PrimeTime Software Files”
■
“Files Generated for the PrimeTime Software Environment” on page 9–2
■
“Running the PrimeTime Software” on page 9–6
■
“PrimeTime Timing Reports” on page 9–7
■
“Static Timing Analyzer Differences” on page 9–18
Quartus II Settings for Generating the PrimeTime Software Files
To set up the Quartus II software to generate files for the PrimeTime software,
perform the following steps:
1. In the Quartus II software, on the Assignments menu, click Settings, and then
click EDA Tool Settings.
2. In the Category list, under EDA Tool Settings, select Timing Analysis.
3. In the Tool name list, select PrimeTime, and in the Format for output netlist list,
select either Verilog HDL or VHDL.
© 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
Subscribe
9–2
Chapter 9: Synopsys PrimeTime Support
Files Generated for the PrimeTime Software Environment
When you compile your project after making these settings, the Quartus II software
runs the EDA Netlist Writer to create three files for the PrimeTime software. These
files are saved in the <revision_name>/timing/primetime directory by default, where
<revision_name> is the name of your Quartus II software revision. If it is not, you have
used the wrong variable name.
Files Generated for the PrimeTime Software Environment
The Quartus II software generates a flattened netlist, a Standard Delay Output File
(.sdo), and a Tcl script that prepares the PrimeTime software for timing analysis of the
Quartus II project. These files are saved in the <project directory>/timing/primetime
directory.
The Quartus II software uses the EDA Netlist Writer to generate PrimeTime files
based on either the Classic Timing Analyzer or the TimeQuest Timing Analyzer static
timing analysis results. When you run the EDA Netlist Writer, the PrimeTime .sdo
files are based on delays generated by the currently selected timing analysis tool in
the Quartus II software.
To specify the timing analyzer, on the Assignments menu, click Settings. The Settings
dialog box appears. Under Category, click Timing Analysis Settings. Select the
timing analyzer of your choice.
f For more information about specifying the Quartus II timing analyzers, refer to either
the Quartus II Classic Timing Analyzer or the Quartus II TimeQuest Timing Analyzer
chapter in volume 3 of the Quartus II Handbook. Also, refer to the Switching to the
Quartus II TimeQuest Timing Analyzer chapter in volume 3 of the Quartus II Handbook to
help you decide which timing analyzer is most appropriate for your design.
The Netlist
Depending on whether Verilog HDL or VHDL is selected as the Format for output
netlist option, in the Tool name list on the Timing Analysis page of the Settings
dialog box, the netlist is written and saved as either <project name>.vo or
<project name>.vho, respectively. This file contains the flattened netlist representing
the entire design.
1
When you select the TimeQuest analyzer, only a Verilog HDL PrimeTime netlist can
be generated.
The .sdo File
The Quartus II software saves the .sdo file as either <revision_name>_v.sdo or
<revision_name>_vhd.sdo, depending on whether you select Verilog HDL or VHDL
in the Tool name list on the Timing Analysis page of the Settings dialog box.
This file contains the timing information for each timing path between any two nodes
in the design.
When you enable the Classic Timing Analyzer, the slow-corner (worst-case) timing
models are used by default when generating the .sdo file. To generate the .sdo file
using the fast-corner (best-case) timing models, perform the following steps:
Quartus II Handbook Version 11.0 Volume 3: Verification
December 2010 Altera Corporation
Chapter 9: Synopsys PrimeTime Support
Files Generated for the PrimeTime Software Environment
9–3
1. In the Quartus II software, on the Processing menu, point to Start and click Start
Classic Timing Analyzer (Fast Timing Model).
2. After the fast-corner timing analysis is complete, on the Processing menu, point to
Start and click Start EDA Netlist Writer to create a <revision_name>_v_fast.sdo or
<revision_name>_vhd_fast.sdo file, which contains the best-case delay values for
each timing path.
1
If you are running a best-case timing analysis, the Quartus II software generates a Tcl
script similar to the following: <revision_name>_pt_v_fast.tcl.
When the TimeQuest analyzer is run with the fast-corner netlist, or when the
Optimize fast-corner timing check box is selected in the Fitter Settings dialog box,
the fast-corner Synopsys Design Constraints File (.sdc) file is generated.
After the EDA Netlist Writer has finished, two .sdc files are created:
<revision_name>_v.sdo (slow corner) and <revision_name>_v_fast.sdo (fast corner).
Generating Multiple Operating Conditions with the TimeQuest Analyzer
You can specify different operating conditions to the EDA Netlist Writer for
PrimeTime analysis. The different operating conditions are reflected in the .sdo file
generated by the EDA Netlist Writer.
1
From the TimeQuest analyzer console pane, use the command
get_available_operating_conditions to obtain a list of available operating
conditions for the target device.
The following steps show how to generate the .sdo files for the three different
operating conditions for a Stratix III design. Enter each command at the command
prompt.
1
The --tq2pt option for quartus_sta is required only if the project does not specify
that the PrimeTime tool is be used as the timing analysis tool.
1. Generate the first slow-corner model at the operating conditions: slow, 1100 mV,
and 85º C.
quartus_sta --model=slow --voltage=1100 --temperature=85 <project name>
2. Generate the fast-corner model at the operating conditions: fast, 1100 mV, and 0º C.
quartus_sta --model=fast --voltage=1100 --temperature=0
--tq2pt <project name>
3. Generate the PrimeTime output files for the corners specified above. The output
files are generated in the primetime_two_corner_files directory.
quartus_eda --timing_analysis --tool=primetime
--format=verilog
--output_directory=primetime_two_corner_files
--write_settings_files=off <project name>
December 2010
Altera Corporation
Quartus II Handbook Version 11.0 Volume 3: Verification
9–4
Chapter 9: Synopsys PrimeTime Support
Files Generated for the PrimeTime Software Environment
4. Generate the second slow-corner model at the operating conditions: slow,
1100 mV, and 0º C.
quartus_sta --model=slow --voltage=1100 --temperature=0
--tq2pt <project name>
5. Generate the PrimeTime output files for the second slow corner. The output files
are generated in the primetime_one_slow_corner_files directory.
quartus_eda --timing_analysis --tool=primetime
--format=verilog
--output_directory=primetime_one_slow_corner_files
--write_settings_files=off $revision
To summarize, the previous steps generate the following files for the three operating
conditions:
1
■
First slow corner (slow, 1100 mV, 85º C):
.vo file—primetime_two_corner_files/<project name>.vo
.sdo file—primetime_two_corner_files/<project name>_v.sdo
■
Fast corner (fast, 1100 mV, 0º C):
.vo file—primetime_two_corner_files/<project name>.vo
.sdo file—primetime_two_corner_files/<project name>_v_fast.sdo
■
Second slow corner (slow, 1100 mV, 0º C):
.vo file—primetime_one_slow_corner_files/<project name>.vo
.sdo file—primetime_one_slow_corner_files/<project name>_v.sdo
The primetime_one_slow_corner_files directory may also have files for fast corner.
These files can be ignored because they were already generated in the
primetime_two_corner_files directory.
The Tcl Script
The Tcl script generated by the Quartus II software contains information required by
the PrimeTime software to analyze the timing and set up your post-fit design. This
script specifies the search path and the names of the PrimeTime database library files
provided with the Quartus II software. The search_path and link_path variables are
defined at the beginning of the Tcl file. The link_path variable is a space-delimited list
that contains the names of all database files used by the PrimeTime software.
Depending on whether you select Verilog HDL or VHDL in the Format for output
netlist list on the Timing Analysis page of the Settings dialog box, when the Classic
Timing Analyzer is enabled, the EDA Netlist Writer generates and saves the script as
either <revision_name>_pt_v.tcl or <revision_name>_pt_vhd.tcl.
To access the EDA Settings dialog box, perform the following:
1. On the Assignments menu, click Settings, and then click EDA Tool Settings
2. Expand EDA Tool Settings under the Category list.
In the dialog box, you can specify VHDL or Verilog HDL for the format of the output
netlist.
Quartus II Handbook Version 11.0 Volume 3: Verification
December 2010 Altera Corporation
Chapter 9: Synopsys PrimeTime Support
Files Generated for the PrimeTime Software Environment
1
9–5
The script also directs the PrimeTime software to use the <device family>_all_pt.v or
<device family>_all_pt.vhd file, which contains the Verilog HDL or VHDL description
of library cells for the targeted device family.
Example 9–1 shows the search_path and link_path variables defined in the Tcl script:
Example 9–1. Sample PrimeTime Setup Script
set quartus_root "altera/quartus/"
set search_path [list . [format "%s%s" $quartus_root "eda/synopsys/primetime/lib"]
]
set link_path [list * stratixii_lcell_comb_lib.db stratixii_lcell_ff_lib.db
stratixii_asynch_io_lib.db stratixii_io_register_lib.db stratixii_termination_lib.db
bb2_lib.db stratixii_ram_internal_lib.db stratixii_memory_register_lib.db
stratixii_memory_addr_register_lib.db stratixii_mac_out_internal_lib.db
stratixii_mac_mult_internal_lib.db stratixii_mac_register_lib.db
stratixii_lvds_receiver_lib.db stratixii_lvds_transmitter_lib.db
stratixii_asmiblock_lib.db stratixii_crcblock_lib.db stratixii_jtag_lib.db
stratixii_rublock_lib.db stratixii_pll_lib.db stratixii_dll_lib.db alt_vtl.db]
read_vhdl
-vhdl_compiler
stratixii_all_pt.vhd
The EDA Netlist Writer converts any Classic Timing Analyzer timing assignments to
the PrimeTime software constraints and exceptions when it generates the PrimeTime
files. The converted constraints are saved to the Tcl script. The Tcl script also includes
a PrimeTime software command that reads the .sdo file generated by the Quartus II
software. You can place additional commands in the Tcl script to analyze or report on
timing paths.
Table 9–1 shows some examples of timing assignments converted by the Quartus II
software for the PrimeTime software. For example, the set_input_delay -max
command sets the input delay on an input pin.
Table 9–1. Equivalent Quartus II and PrimeTime Software Constraints
Quartus II Equivalent
PrimeTime Constraint
Clock defined on input pin, clock of 10 ns
period and 50% duty cycle
create_clock -period 10.000 -waveform {0 5.000} \
[get_ports clk] -name clk
Input maximum delay of 1 ns on input pin, din
set_input_delay -max -add_delay 1.000 -clock \
[get_clocks clk] [get_ports din]
Input minimum delay of 1 ns on input pin, din
set_input_delay -min -add_delay 1.000 -clock \
[get_clocks clk] [get_ports din]
Output maximum delay of 3 ns on output pin,
out
set_output_delay -max -add_delay 3.000 -clock \
[get_clocks clk] [get_ports out]
When the TimeQuest analyzer is turned on, the EDA Netlist Writer generates and
saves the script as <revision_name>.pt.tcl.
The EDA Netlist Writer converts all TimeQuest analyzer .sdc constraints and
exceptions into compatible PrimeTime software constraints and exceptions when it
generates the PrimeTime files. The constraints and exceptions are saved to the
<revision_name>.constraints.sdc file.
December 2010
Altera Corporation
Quartus II Handbook Version 11.0 Volume 3: Verification
9–6
Chapter 9: Synopsys PrimeTime Support
Running the PrimeTime Software
Generated File Summary
The files that are generated by the EDA Netlist Writer for the PrimeTime software
depend on the Quartus II timing analysis tool you select.
Table 9–2 shows the files that are generated for the PrimeTime software when the
Classic Timing Analyzer is selected.
Table 9–2. Classic Timing Analyzer-Generated PrimeTime Files
File
Description
<revision_name>.vho |
<revision_name>.vo
The PrimeTime software output netlist. Either a VHDL Output File (.vho) or a Verilog
Output File (.vo) is generated, depending on the output netlist language set.
<revision_name>_vhd.sdo |
<revision_name>_v.sdo
The PrimeTime software standard delay file. Either a VHDL Standard Delay Output File
(vhd.sdo) or a Verilog Standard Delay Output File (v.sdo) is generated, depending on the
output netlist language set.
<revision_name>_pt_vhd.tcl |
<revision_name>_pt_v.tcl
PrimeTime setup and constraint script. Either a VHDL Tcl Script File (vhd.tcl) or a
Verilog Tcl Script File (v.tcl) is generated, depending on the output netlist language set.
Table 9–3 shows the files that are generated for the PrimeTime software when the
TimeQuest analyzer is selected. The EDA Netlist Writer supports the output netlist
format only when the TimeQuest analyzer is enabled.
Table 9–3. TimeQuest Timing Analyzer-Generated PrimeTime Files
File
Description
<revision_name>.vo
The PrimeTime software output netlist. When the TimeQuest analyzer is enabled,
only PrimeTime (Verilog HDL) is supported.
<revision_name>_v.sdo |
<revision_name>_v_fast.sdo
The PrimeTime software standard delay file. When the TimeQuest analyzer is
enabled, only PrimeTime (Verilog HDL) is supported.
<revision_name>.pt.tcl
PrimeTime setup and constraint script. When the TimeQuest analyzer is enabled,
only PrimeTime (Verilog HDL) is supported.
<revision_name>.collections.sdc
Contains the mapping from the TimeQuest analyzer netlist to the PrimeTime netlist.
<revision_name>.constraints.sdc
Contains the converted TimeQuest analyzer constraints for the PrimeTime
software.
Running the PrimeTime Software
The PrimeTime software runs only on UNIX operating systems. If the Quartus II
output files for the PrimeTime software were generated by running the Quartus II
software on a PC/Windows-based system, follow these steps to run the PrimeTime
software using Quartus II output files:
1. Install the PrimeTime libraries on a UNIX system by installing the Quartus II
software on UNIX.
The PrimeTime libraries are located in the <Quartus II installation
directory>/eda/synopsys/primetime/lib directory.
2. Copy the Quartus II output files to the appropriate UNIX directory. You may need
to run a PC to UNIX program, such as dos2unix, to remove any control characters.
Quartus II Handbook Version 11.0 Volume 3: Verification
December 2010 Altera Corporation
Chapter 9: Synopsys PrimeTime Support
PrimeTime Timing Reports
9–7
3. Modify the Quartus II path in Tcl scripts to point to the PrimeTime libraries using
the first line of Example 9–1:
set quartus_root "altera/quartus/" set search_path [list . [format
"%s%s" $quartus_root "eda/synopsys/primetime/lib"] ]
Analyzing Quartus II Projects
The PrimeTime software is controlled with Tcl scripts and can be run through
pt_shell. You can run the <revision_name>_pt_v.tcl script file. For example, type the
following at a UNIX system command prompt:
pt_shell -f <revision_name>_pt_v.tcl r
When the TimeQuest analyzer is selected, type the following at a UNIX system
command prompt:
pt_shell -f <revision_name>.pt.tcl r
After all Tcl commands in the script are interpreted, the PrimeTime software returns
control to the pt_shell prompt, which allows you to use other commands.
Other pt_shell Commands
You can run additional pt_shell commands at the pt_shell prompt, including the
man program. For example, to read documentation about the report_timing
command, type the following at the pt_shell prompt:
man report_timing r
You can list all commands available in pt_shell by typing the following at the
pt_shell prompt:
help r
Type quit r at the pt_shell prompt to close pt_shell.
1
You can also run pt_shell without a script file by typing pt_shellr at the UNIX
command line prompt.
PrimeTime Timing Reports
This section describes PrimeTime timing reports.
Sample PrimeTime Software Timing Report
After running the script, the PrimeTime software generates a timing report. If the
timing constraints are not met, Violated is displayed at the end of the timing report.
The timing report also gives the negative slack.
December 2010
Altera Corporation
Quartus II Handbook Version 11.0 Volume 3: Verification
9–8
Chapter 9: Synopsys PrimeTime Support
PrimeTime Timing Reports
The PrimeTime software timing report is similar to the sample shown in Example 9–2.
The starting point in this report is a register clocked by clock signal, clock, and the
endpoint is another register, inst3-I.lereg.
Example 9–2. Hold Path Report in PrimeTime
Startpoint: inst2~I.lereg
(rising edge-triggered flip-flop clocked by clock)
Endpoint: inst3~I.lereg
(rising edge-triggered flip-flop clocked by clock)
Path Group: clock
Path Type: min
Point
Incr
Path
---------------------------------------------------------------clock clock (rise edge)
0.000
0.000
clock network delay (propagated)
3.166
3.166
inst2~I.lereg.clk (stratix_lcell_register)
0.000
3.166r
inst2~I.lereg.regout (stratix_lcell_register) <- 0.176*
3.342r
inst2~I.regout (stratix_lcell)
0.000*
3.342r
inst3~I.datac (stratix_lcell)
0.000*
3.342r
inst3~I.lereg.datac (stratix_lcell_register)
3.413*
6.755r
data arrival time
6.755
clock clock (rise edge)
0.000
0.000
clock network delay (propagated)
3.002
3.002
inst3~I.lereg.clk (stratix_lcell_register)
3.002r
library hold time
0.100*
3.102
data required time
3.102
--------------------------------------------------------------data required time
3.102
data arrival time
-6.755
--------------------------------------------------------------slack (MET)
3.653
Comparing Timing Reports from the Classic Timing Analyzer and the
PrimeTime Software
Both the Classic Timing Analyzer and the TimeQuest analyzer generate a static timing
analysis report for every successful design compilation. The timing report lists all of
the timing paths in your design that were analyzed, and indicates whether these paths
have met or violated their timing requirements. Violations are reported only if timing
constraints were specified.
The TimeQuest analyzer and PrimeTime use an equivalent set of equations when
reporting the static timing analysis results for a design. However, the Classic Timing
Analyzer uses slightly different reporting equations when reporting the static timing
analysis results for a design. This section describes the differences between the Classic
Timing Analyzer and the PrimeTime software.
The timing report generated by the Classic Timing Analyzer differs from the report
generated by the PrimeTime software. Both tools provide the same data, but the data
is presented in different formats. The following sections show how the PrimeTime
software reports the following slack values differently from the Classic Timing
Analyzer report:
■
“Clock Setup Relationship and Slack” on page 9–9
■
“Clock Hold Relationship and Slack” on page 9–12
■
“Input Delay and Output Delay Relationships and Slack” on page 9–16
Quartus II Handbook Version 11.0 Volume 3: Verification
December 2010 Altera Corporation
Chapter 9: Synopsys PrimeTime Support
PrimeTime Timing Reports
9–9
Clock Setup Relationship and Slack
The Classic Timing Analyzer performs a setup check that ensures that the data
launched by source registers is latched correctly at the destination registers. The
Classic Timing Analyzer does this by determining the data arrival time and clock
arrival time at the destination registers, and compares this data with the setup time
delay of the destination register. Equation 9–1 expresses the inequality that is used for
a setup check. The data arrival time includes the longest path from the clock to the
source register, the clock-to-out micro delay of the source register, and the longest
path from the source register to the destination register. The clock arrival time is the
shortest delay from the clock to the destination register.
Equation 9–1.
Clock Arrival – Data Arrival  t su
Slack is the margin by which a timing requirement is met or not met. Positive slack
indicates the margin by which a requirement is met. Negative slack indicates the
margin by which a requirement is not met. The Classic Timing Analyzer determines
the clock setup slack, as shown in Equation 9–2:
Equation 9–2.
Clock Setup Slack = Largest Register-to-Register Requirement – Longest Register-to-Register Delay
1
The longest register-to-register delay in the previous equation is equal to the
register-to-register data delay.
Equation 9–3.
Largest Register-to-Register Requirement =
Setup Relationship between Source and Destination + Largest Clock Skew –
Micro t co of Destination Register – Micro t su of Destination Register
Setup Relationship between Source and Destination = Latch Edge – Launch Edge
Clock Skew = Shortest Clock Path to Destination – Longest Clock Path to Source
Figure 9–2 shows a simple three-register design.
Figure 9–2. Simple Three-Register Design
December 2010
Altera Corporation
Quartus II Handbook Version 11.0 Volume 3: Verification
9–10
Chapter 9: Synopsys PrimeTime Support
PrimeTime Timing Reports
The Classic Timing Analyzer generates a report for the design, as shown in
Figure 9–3.
Figure 9–3. Timing Analyzer Report from Figure 9–2
Equation 9–1, Equation 9–2, and Equation 9–3 are similar to those found in other
static timing analysis tools, such as the PrimeTime software. Equation 9–4 through
Equation 9–7, used by the PrimeTime software, are essentially the same as those used
by the Classic Timing Analyzer, but they are rearranged.
Equation 9–4.
Slack = Data Required – Data Arrival
Equation 9–5.
Clock Arrival = Latch Edge + Shortest Clock Path to Destination
Equation 9–6.
Data Required = Clock Arrival – Micro t su
Equation 9–7.
Data Arrival = Launch Edge + Longest Clock Path to Source + Micro tco + Longest Data Delay
1
The longest data delay in the previous equation is equal to
register-to-register data delay.
Quartus II Handbook Version 11.0 Volume 3: Verification
December 2010 Altera Corporation
Chapter 9: Synopsys PrimeTime Support
PrimeTime Timing Reports
9–11
Figure 9–4 shows a clock setup check in the Quartus II software.
Figure 9–4. Clock Setup Check Reporting with the Classic Timing Analyzer
The results in Equation 9–8 are obtained by extracting the numbers from the Classic
Timing Analyzer report and applying them to the clock setup slack equations from
the Classic Timing Analyzer:
Equation 9–8.
Setup Relationship between Source and Destination = Latch Edge – Launch Edge –
Clock Setup Uncertainty
8.0 – 0.0 – 0.0 = 8.0ns
Clock Skew = Shortest Clock Path to Destination – Longest Clock Path to Source
3.002 – 3.166 = – 0.164ns
Largest Register-to-Register Requirement =
Setup Relationship between Source & Destination + Largest Clock Skew
– Micro t co of Source Register – Micro t su of Destination Register
8 +  – 0.164  – 0.176 – 0.010 = 7.650ns
Clock Setup Slack = Largest Register-to-Register Requirement – Longest Register-to-Register Delay
7.650 – 3.413 = 4.237ns
December 2010
Altera Corporation
Quartus II Handbook Version 11.0 Volume 3: Verification
9–12
Chapter 9: Synopsys PrimeTime Support
PrimeTime Timing Reports
For the same register-to-register path, the PrimeTime software generates a clock setup
report as shown in Example 9–3:
Example 9–3. Setup Path Report in PrimeTime
Startpoint: inst2~I.lereg
(rising edge-triggered flip-flop clocked by clock)
Endpoint: inst3~I.lereg
(rising edge-triggered flip-flop clocked by clock)
Path Group: clock
Path Type: max
Point
Incr
Path
---------------------------------------------------------------clock clock (rise edge)
0.000
0.000
clock network delay (propagated)
3.166
3.166
inst2~I.lereg.clk (stratix_lcell_register)
0.000
3.166r
inst2~I.lereg.regout (stratix_lcell_register) <- 0.176*
3.342r
inst2~I.regout (stratix_lcell) <0.000*
3.342r
inst3~I.datac (stratix_lcell) <0.000*
3.342r
inst3~I.lereg.datac (stratix_lcell_register)
3.413*
6.755r
data arrival time
6.755
clock clock (rise edge)
8.000
8.000
clock network delay (propagated)
3.002
11.002
inst3~I.lereg.clk (stratix_lcell_register
11.002r
library setup time
-0.010* 10.992
data required time
10.992
---------------------------------------------------------------data required time
10.992
data arrival time
-6.755
---------------------------------------------------------------slack (MET)
4.237
Clock Hold Relationship and Slack
The Classic Timing Analyzer performs a hold time check along every
register-to-register path in the design to ensure that no hold time violations have
occurred. The hold time check verifies that data from the source register does not
reach the destination until after the hold time of the destination register. The condition
used for a hold check is shown in Equation 9–9:
Equation 9–9.
Data Arrival – Clock Arrival  t H
Quartus II Handbook Version 11.0 Volume 3: Verification
December 2010 Altera Corporation
Chapter 9: Synopsys PrimeTime Support
PrimeTime Timing Reports
9–13
The Classic Timing Analyzer determines the clock hold slack with Equation 9–10,
Equation 9–11, Equation 9–12, and Equation 9–13:
Equation 9–10.
Clock Hold Slack = Shortest Register-to-Register Delay – Smallest Register-to-Register Requirement
Equation 9–11.
Smallest Register-to-Register Requirement = Hold Relationship between Source & Destination +
Smallest Clock Skew – Micro t su of Source + Micro t H of Destination
Equation 9–12.
Hold Relationship between Source & Destination = Latch Edge – Launch Edge
Equation 9–13.
Smallest Clock Skew = Longest Clock Path from Clock to Destination Register –
Shortest Clock Path from Clock to Source Register
Figure 9–5 shows a simple three-register design.
Figure 9–5. Simple Three-Register Design
December 2010
Altera Corporation
Quartus II Handbook Version 11.0 Volume 3: Verification
9–14
Chapter 9: Synopsys PrimeTime Support
PrimeTime Timing Reports
The Classic Timing Analyzer generates a report as shown in Figure 9–6.
Figure 9–6. Timing Analyzer Report Generated from the Three-Register Design
The previous equations are similar to those found in the Quartus II software.
Equation 9–14 through Equation 9–17 are the same equations that are used by the
PrimeTime software, but they are rearranged.
Equation 9–14.
Slack = Data Required – Data Arrival
Equation 9–15.
Clock Arrival = Latch Edge + Longest Clock Path to Destination
Equation 9–16.
Data Required = Clock Arrival – Micro t H
Equation 9–17.
Data Arrival = Launch Edge + Longest Clock Path to Source + Micro tco + Shortest Data Delay
1
The shortest register-to-register delay in the previous equation is equal to
register-to-register data delay.
Quartus II Handbook Version 11.0 Volume 3: Verification
December 2010 Altera Corporation
Chapter 9: Synopsys PrimeTime Support
PrimeTime Timing Reports
9–15
Figure 9–7 shows a clock setup check with the Classic Timing Analyzer.
Figure 9–7. Clock Hold Check Reporting with the Classic Timing Analyzer
The results in Equation 9–18 are obtained by extracting the numbers from the Timing
Analysis report and applying the clock setup slack equations from the Classic Timing
Analyzer.
Equation 9–18.
Clock Hold Slack = Shortest Register-to-Register Delay – Smallest Register-to-Register Requirement
3.413 –  – 0.240  = 3.653ns
Smallest Register-to-Register Requirement = Hold Relationship between Source & Destination +
Smallest Clock Skew – Micro t co of Source + Micro t H of Destination
0 +  – 0.164  – 0.176 + 0.100 = – 0.240ns
Hold Relationship between Source & Destination = Latch – Launch
0.0 – 0.0ns
Smallest Clock Skew = Longest Clock Path from Clock to Destination Register –
Shortest Clock Path from Clock to Source Register
3.002 – 3.166 = – 0.164ns
December 2010
Altera Corporation
Quartus II Handbook Version 11.0 Volume 3: Verification
9–16
Chapter 9: Synopsys PrimeTime Support
PrimeTime Timing Reports
For the same register-to-register path, the PrimeTime software generates the report
shown in Example 9–4:
Example 9–4. Hold Path Report in PrimeTime
Startpoint: inst2~I.lereg
(rising edge-triggered flip-flop clocked by clock)
Endpoint: inst3~I.lereg
(rising edge-triggered flip-flop clocked by clock)
Path Group: clock
Path Type: min
Point
Incr
Path
---------------------------------------------------------------clock clock (rise edge)
0.000
0.000
clock network delay (propagated)
3.166
3.166
inst2~I.lereg.clk (stratix_lcell_register)
0.000
3.166r
inst2~I.lereg.regout (stratix_lcell_register)<- 0.176*
3.342r
inst2~I.regout (stratix_lcell)
0.000*
3.342r
inst3~I.datac (stratix_lcell)
0.000*
3.342r
inst3~I.lereg.datac (stratix_lcell_register)
3.413*
6.755r
data arrival time
6.755
clock clock (rise edge)
0.000
0.000
clock network delay (propagated)
3.002
3.002
inst3~I.lereg.clk (stratix_lcell_register)
3.002r
library hold time
0.100*
3.102
data required time
3.102
-------------------------------------------------------------data required time
3.102
data arrival time
-6.755
-------------------------------------------------------------slack (MET)
3.653
Both sets of hold slack equations can be used to determine the hold slack value of any
path.
Input Delay and Output Delay Relationships and Slack
Input delay and output delay reports generated by the Classic Timing Analyzer are
similar to the clock setup and clock hold relationship reports. Figure 9–8 shows the
input delay and output delay report for the design shown in Figure 9–5 on page 9–13.
Figure 9–8. Input and Output Delay Reporting with the Classic Timing Analyzer
Quartus II Handbook Version 11.0 Volume 3: Verification
December 2010 Altera Corporation
Chapter 9: Synopsys PrimeTime Support
PrimeTime Timing Reports
9–17
Figure 9–9 shows the fully expanded view for the output delay path.
Figure 9–9. Output Delay Path Reporting with the Classic Timing Analyzer
For the same output delay path, the PrimeTime software generates a report similar to
Example 9–5:
Example 9–5. Setup Path Report in PrimeTime
Startpoint: inst3~I.lereg
(rising edge-triggered flip-flop clocked by clock)
Endpoint: data_out
(output port clocked by clock)
Path Group: clock
Path Type: max
Point
Incr
Path
---------------------------------------------------------------clock clock (rise edge)
0.000
0.000
clock network delay (propagated)
3.002
3.002
inst3~I.lereg.clk (stratix_lcell_register)
0.000
3.002r
inst3~I.lereg.regout (stratix_lcell_register)<- 0.176*
3.178r
inst3~I.regout (stratix_lcell)<0.000
3.178r
data_out~I.datain (stratix_io)<0.000
3.178r
data_out~I.out_mux3.A (mux21)<0.000
3.178r
data_out~I.out_mux3.MO (mux21)<0.000
3.178r
data_out~I.and2_22.IN1 (AND2)<0.000
3.178r
data_out~I.and2_22.Y (AND2)<0.000
3.178r
data_out~I.out_mux1.A (mux21)<0.000
3.178r
data_out~I.out_mux1.MO (mux21)<0.000
3.178r
data_out~I.inst1.datain (stratix_asynch_io)<0.902*
4.080r
data_out~I.inst1.padio (stratix_asynch_io)<2.495*
6.575r
data_out~I.padio (stratix_io)<0.000
6.575r
data_out (out)
0.000
6.575r
data arrival time
6.575
clock clock (rise edge)
8.000
8.000
clock network delay (propagated)
0.000
8.000
output external delay
1.250
6.750
data required time
6.750
--------------------------------------------------------------data required time
6.750
data arrival time
6.575
--------------------------------------------------------------slack (MET)
0.175
To generate a list of the 100 worst paths and place this data into a file called
file.timing, type the following command at the pt_shell prompt:
report_timing -nworst 100 > file.timing r
December 2010
Altera Corporation
Quartus II Handbook Version 11.0 Volume 3: Verification
9–18
Chapter 9: Synopsys PrimeTime Support
Static Timing Analyzer Differences
Timing paths in the PrimeTime software are listed in the order of most-negative-slack
to most-positive-slack. The PrimeTime software does not categorize failing paths by
default. Timing setup (tsu) and timing hold (th) times are not listed separately. In the
PrimeTime software, each path is shown with a start and end point; for example, if it
is a register-to-register or input-to-register type of path. If you only use the
report_timing part of the command without adding a -delay option, only the
setup-time-related timing paths are reported.
The following command is used to create a minimum timing report or a list of
hold-time-related violations:
report_timing -delay_type min r
Ensure that the correct .sdo file, either minimum or maximum delays, is loaded before
running this command.
Static Timing Analyzer Differences
Under certain design conditions, several static timing analysis differences can exist
between the Classic Timing Analyzer and the TimeQuest analyzer, and the PrimeTime
software. The following sections explain the differences between the two static timing
analysis engines and the PrimeTime software.
Classic Timing Analyzer and PrimeTime Software
The following section describes the differences between the Classic Timing Analyzer
and the PrimeTime software.
Rise/Fall Support
The Classic Timing Analyzer does not support rise/fall analysis. However, rise/fall
support is available in PrimeTime.
Minimum and Maximum Delays
The Classic Timing Analyzer calculates minimum and maximum delays for all device
components with the exception of clock routing. PrimeTime does not model these
delays. This can result in different slacks for a given path on average of 2 to 3%.
Recovery/Removal Analysis
The Classic Timing Analyzer performs a more pessimistic recovery/removal analysis
for asynchronous paths than PrimeTime. This can result in different delays reported
between the two tools.
Encrypted Intellectual Property Blocks
The Quartus II software has the capability to decrypt all intellectual property (IP)
blocks designed for Altera® devices that have been encrypted by their vendors. The
decryption process allows the Quartus II software to perform a full compilation of the
design that contains an encrypted IP block. This also allows the Classic Timing
Analyzer to perform a complete static timing analysis on the design. However,
licensed and encrypted IP blocks do not permit output netlists to be generated when
using PrimTime as the static timing analysis tool. (The EDA Netlist Writer does not
generate .vho or .vo netlist files.)
Quartus II Handbook Version 11.0 Volume 3: Verification
December 2010 Altera Corporation
Chapter 9: Synopsys PrimeTime Support
Static Timing Analyzer Differences
9–19
Registered Clock Signals
Registered clock signals are clock signals that pass through a register before reaching
the clock port of a sequential element. Figure 9–10 shows an example of a registered
clock signal.
Figure 9–10. Registered Clock Signal
reg2
D
Q
Logic
reg1
D
Q
If no clock setting is applied to the register on the clock path (shown as register reg_1
in Figure 9–10), the Classic Timing Analyzer treats the register in the clock path as a
buffer. The delay of the buffer is equal to the CELL delay of the register plus the tCO of
the register. The PrimeTime software does not treat the register as a buffer.
1
For more information about creating clock settings, refer to the Quartus II Classic
Timing Analyzer chapter in volume 3 of the Quartus II Handbook.
Multiple Source and Destination Register Pairs
In any design, multiple paths may exist from a source register to a destination register.
Each path from the source register to the destination register may have a different
delay value due to the different routes taken. For example, Figure 9–11 shows a
sample design that contains multiple path pairs between the source register and
destination register.
Figure 9–11. Multiple Source and Destination Pairs
Path 2
D
Q
D
Q
Path 1
The Classic Timing Analyzer analyzes all source and destination pairs, but reports
only the source and destination register pair with the worst slack. For example, if the
Path 2 pair delay is greater than the Path 1 pair delay in Figure 9–11, the Classic
Timing Analyzer reports the slack value of the Path 2 pair and not the Path 1 pair. The
PrimeTime software reports all possible source and destination register pairs.
Latches
By default, the Quartus II software implements all latches as combinational loops. The
Classic Timing Analyzer can analyze such latches by treating them as registers with
inverted clocks or analyze latches as a combinational loop modeled as a
combinational delay.
December 2010
Altera Corporation
Quartus II Handbook Version 11.0 Volume 3: Verification
9–20
Chapter 9: Synopsys PrimeTime Support
Static Timing Analyzer Differences
1
For more information about latch analysis, refer to the Quartus II Classic Timing
Analyzer chapter in volume 3 of the Quartus II Handbook.
The PrimeTime software always analyzes these latches as combinational loops, as
defined in the netlist file.
LVDS I/O
When analyzing the dedicated LVDS transceivers in your design, the Classic Timing
Analyzer generates the Receiver Skew Margin (RSKM) report and a
Channel-to-Channel Skew (TCCS) report. The PrimeTime software does not generate
these reports.
Clock Latency
When a single clock signal feeds both the source and destination registers of a
register-to-register path, and either an Early Clock Latency or a Late Clock Latency
assignment has been applied to the clock signal, the Classic Timing Analyzer does not
factor in the clock latency values when it calculates the clock skew between the two
registers. The Classic Timing Analyzer factors in the clock latency values when the
clock signal to the source and destination registers of a register-to-register path are
different. The PrimeTime software applies the clock latency values when a single
clock signal or different clock signals feeds the source and destination registers of a
register-to-register path.
Input and Output Delay Assignments
When a purely combinational (non-registered) path exists between an input pin and
output pin of the Altera FPGA and both pins have been constrained with an input
delay and an output delay assignment applied, respectively, the Classic Timing
Analyzer does not perform a clock setup or clock hold analysis. The PrimeTime
software analyzes these paths.
Generated Clocks Derived from Generated Clocks
The Classic Timing Analyzer does not support a generated clock derived from a
generated clock. This situation might occur if a generated clock feeds the input clock
pin of a PLL. The output clock of the PLL is a generated clock.
TimeQuest Timing Analyzer and PrimeTime Software
The following sections describe the static timing analysis differences between the
TimeQuest analyzer and the PrimeTime software.
Encrypted Intellectual Property Blocks
The Quartus II software has the capability to decrypt all IP blocks, designed for Altera
devices that have been encrypted by their vendors. The decryption process allows the
Quartus II software to perform a full compilation on the design containing an
encrypted IP block. This also allows the TimeQuest analyzer to perform a complete
static timing analysis on the design. However, licensed and encrypted IP blocks do
not permit output netlists to be generated when using PrimTime as the static timing
analysis tool. (The EDA Netlist Writer does not generate .vho or .vo netlist files.)
Quartus II Handbook Version 11.0 Volume 3: Verification
December 2010 Altera Corporation
Chapter 9: Synopsys PrimeTime Support
Static Timing Analyzer Differences
9–21
Latches
By default, the Quartus II software implements all latches as combinational loops. The
TimeQuest analyzer can analyze such latches by treating them as registers with
inverted clocks. The TimeQuest analyzer analyzes latches as a combinational loop
modeled as a combinational delay.
f For more information about latch analysis, refer to the Quartus II TimeQuest Timing
Analyzer chapter in volume 3 of the Quartus II Handbook.
The PrimeTime software always analyzes these latches as combinational loops, as
defined in the netlist file.
LVDS I/O
When analyzing the dedicated LVDS transceivers in your design, the TimeQuest
analyzer generates a Receiver Skew Margin (RSKM) report and a Channel-to-Channel
Skew (TCCS) report. The PrimeTime software does not generate these reports.
The TimeQuest Timing Analyzer .sdc File and PrimeTime Compatibility
Because of differences between node naming conventions with the netlist generated
by the EDA Netlist Writer and the internal netlist used by the Quartus II software,
.sdc files generated for the Quartus II software or the TimeQuest analyzer are not
compatible with the PrimeTime software.
Run the EDA Netlist Writer to generate a compatible .sdc file from the TimeQuest .sdc
file for the PrimeTime software. After the files <revision_name>.collections.sdc and
<revision_name>.constraints.sdc have been generated, both files can be read by the
PrimeTime software for compatibility of constraints between the TimeQuest analyzer
and the PrimeTime software.
Clock and Data Paths
If a timing path acts both as a clock path (a path that connects to a clock pin with a
clock associated with it), and a data path (a path that feeds into the data-in port of a
register), the TimeQuest analyzer reports the data paths, whereas PrimeTime does
not.
Inverting and Non-Inverting Propagation
The TimeQuest analyzer always propagates non-inverting sense for clocks through
non-unate paths in the clock network.
PrimeTime’s default behavior is to propagate both inverting and non-inverting senses
through a non-unate path in the clock network.
Multiple Rise/Fall Numbers For a Timing Arc
For a given timing path with a corresponding set of pins/ports that make up the path
(including source and destination pair), if the individual components of that path
have different rise/fall delays, there can potentially be many timing paths with
different delays using the same set of pins. If this occurs, the TimeQuest analyzer
reports only one timing path for the set of pins that make up the path.
December 2010
Altera Corporation
Quartus II Handbook Version 11.0 Volume 3: Verification
9–22
Chapter 9: Synopsys PrimeTime Support
Conclusion
Virtual Generated Clocks
PrimeTime does not support virtual generated clocks. To maintain compatibility
between the TimeQuest analyzer and PrimeTime, all generated clocks should have an
explicit target specified.
Generated Clocks Derived from Generated Clocks
The Classic Timing Analyzer does not support the creation of a generated clock
derived from a generated clock. This situation might occur if a generated clock feeds
the input clock pin of another generated clock. The output clock of the PLL is a
generated clock.
Conclusion
The Quartus II software can export a netlist, constraints, and timing information for
use with the PrimeTime software. The PrimeTime software can use data from either
best-case or worst-case Quartus II timing models to measure timing. The PrimeTime
software is controlled using a Tcl script generated by the Quartus II software that you
can customize to direct the PrimeTime software to produce violation and slack
reports.
Document Revision History
Table 9–4 shows the revision history for this chapter.
Table 9–4. Document Revision History
Date
Version
Changes Made
December 2010
10.0.1
Changed to new document template.
July 2010
10.0.0
■
Minor corrections throughout, and Quartus II interface changes.
November 2009
9.1.0
■
Updated “Setting the Quartus II Software to Generate the PrimeTime Software Files”
figure for changes in the Quartus II software version 9.1
March 2009
9.0.0
■
This was chapter 10 in version 8.1.
■
Updated for the Quartus II software version 9.0 release.
November 2008
8.1.0
■
Changed to 8-1/2 x 11 page size. No change to content.
May 2008
8.0.0
■
Updated to Quartus II software version 8.0 and date.
■
Added hyperlinks to referenced Altera documentation throughout the chapter.
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.
Quartus II Handbook Version 11.0 Volume 3: Verification
December 2010 Altera Corporation
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

Download PDF

advertisement