Quartus II Handbook Version 10.0 Volume 3: Verification

Quartus II Handbook Version 10.0 Volume 3: Verification
Quartus II Handbook Version 10.0
Volume 3: Verification
101 Innovation Drive
San Jose, CA 95134
www.altera.com
QII5V3-10.0.1
Copyright © 2010 Altera Corporation. All rights reserved. Altera, The Programmable Solutions Company, the stylized Altera logo, specific device designations, and all other
words and logos that are identified as trademarks and/or service marks are, unless noted otherwise, the trademarks and service marks of Altera Corporation in the U.S. and other
countries. All other product or service names are the property of their respective holders. Altera products are protected under numerous U.S. and foreign patents and pending applications, maskwork rights, and copyrights. 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 Corporation. 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.
Contents
Chapter Revision Dates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiii
Section I. Simulation
Chapter 1. Simulating Designs with EDA Tools
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1
PLD Design Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2
RTL Functional Simulation Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-3
Gate-Level Timing Simulation Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-4
Converting BDF Format to HDL Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-4
Simulation Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-5
RTL Functional Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-5
Gate-Level Timing Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-6
Simulation Netlist Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-6
Generating Post-Synthesis Simulation Netlist Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-7
Generating Gate-Level Timing Simulation Netlist Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-7
Generating Timing Simulation Netlist Files with Different Timing Models . . . . . . . . . . . . . . . . . . . . 1-8
EDA Simulation Library Compiler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-9
Running the EDA Simulation Library Compiler Through the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . 1-10
Running the EDA Simulation Library Compiler from the Command Line . . . . . . . . . . . . . . . . . . . 1-11
Using the NativeLink Feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-11
Setting Up the EDA Simulator Execution Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-11
Configuring NativeLink Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-12
Running RTL Functional Simulation Using the NativeLink Feature . . . . . . . . . . . . . . . . . . . . . . . . . 1-14
Running Gate-Level Timing Simulation Using the NativeLink Feature . . . . . . . . . . . . . . . . . . . . . . 1-14
Setting Up Testbench Files Using the NativeLink Feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-14
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-16
Document Revision History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-16
Chapter 2. Mentor Graphics ModelSim/QuestaSim Support
Software Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Design Flow with ModelSim-Altera or ModelSim/QuestaSim Software . . . . . . . . . . . . . . . . . . . . . . . .
Simulation Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Precompiled Simulation Libraries in the ModelSim-Altera Software . . . . . . . . . . . . . . . . . . . . . . . . .
Simulation Library Files in the Quartus II Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Disabling Timing Violation on Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Performing Simulation Using the ModelSim-Altera Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Performing Functional Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Setting Up a Quartus II Project for the ModelSim-Altera Software . . . . . . . . . . . . . . . . . . . . . . . . .
Compiling and Loading Designs with the ModelSim-Altera Software . . . . . . . . . . . . . . . . . . . . .
Performing the Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Performing Post-Synthesis Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Performing Gate-Level Timing Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Performing Simulation Using the ModelSim/QuestaSim Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Simulating VHDL Designs Using the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Performing Functional Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Performing Post-Synthesis Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Performing Gate-Level Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
© July 2010 Altera Corporation
2-1
2-2
2-2
2-2
2-3
2-3
2-3
2-3
2-4
2-4
2-4
2-4
2-4
2-5
2-5
2-5
2-6
2-7
Quartus II Handbook Version 10.0 Volume 3: Verification
iv
Contents
Simulating Verilog HDL Designs Using the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-7
Performing Functional Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-7
Performing Post-Synthesis Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-8
Performing Gate-Level Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-9
Simulating VHDL Designs From the Command Line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-9
Performing Functional Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-9
Performing Post-Synthesis Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-11
Performing Gate-Level Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-12
Simulating Verilog HDL Designs from the Command Line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-13
Performing Functional Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-13
Performing Post-Synthesis Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-14
Performing Gate-Level Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-15
Passing Parameter Information from Verilog to VHDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-15
Speeding Up Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-16
Simulating Designs that Include Transceivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-16
Functional Simulation for Stratix GX Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-17
Performing Functional Simulation in VHDL (ModelSim-Altera) . . . . . . . . . . . . . . . . . . . . . . . . . 2-17
Performing Functional Simulation in VHDL (ModelSim/QuestaSim) . . . . . . . . . . . . . . . . . . . . . 2-17
Performing Functional Simulation in Verilog HDL (ModelSim-Altera) . . . . . . . . . . . . . . . . . . . . 2-17
Performing Functional Simulation in Verilog HDL (ModelSim/QuestaSim) . . . . . . . . . . . . . . . 2-17
Gate-Level Timing Simulation for Stratix GX Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-18
Performing Gate-Level Timing Simulation in VHDL (ModelSim-Altera) . . . . . . . . . . . . . . . . . . 2-18
Performing Gate-Level Timing Simulation in VHDL (ModelSim/QuestaSim) . . . . . . . . . . . . . . 2-18
Performing Gate-Level Timing Simulation in Verilog HDL (ModelSim-Altera) . . . . . . . . . . . . . 2-18
Performing Gate-Level Timing Simulation in Verilog HDL (ModelSim/QuestaSim) . . . . . . . . 2-19
Functional Simulation for Stratix II GX Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-19
Performing Functional Simulation in VHDL (ModelSim-Altera) . . . . . . . . . . . . . . . . . . . . . . . . . 2-19
Performing Functional Simulation in VHDL (ModelSim/QuestaSim) . . . . . . . . . . . . . . . . . . . . . 2-19
Performing Functional Simulation in Verilog HDL (ModelSim-Altera) . . . . . . . . . . . . . . . . . . . . 2-20
Performing Functional Simulation in Verilog HDL (ModelSim/QuestaSim) . . . . . . . . . . . . . . . 2-20
Gate-Level Timing Simulation for Stratix II GX Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-20
Performing Gate-Level Timing Simulation in VHDL (ModelSim-Altera) . . . . . . . . . . . . . . . . . . 2-20
Performing Gate-Level Timing Simulation in VHDL (ModelSim/QuestaSim) . . . . . . . . . . . . . . 2-20
Performing Gate-Level Timing Simulation in Verilog HDL ModelSim-Altera) . . . . . . . . . . . . . 2-21
Performing Gate-Level Timing Simulation in Verilog HDL ModelSim/QuestaSim) . . . . . . . . . 2-21
Functional Simulation for Stratix IV GX Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-21
Performing Functional Simulation in VHDL (ModelSim-Altera) . . . . . . . . . . . . . . . . . . . . . . . . . 2-21
Performing Functional Simulation in VHDL (ModelSim/QuestaSim) . . . . . . . . . . . . . . . . . . . . . 2-21
Performing Functional Simulation in Verilog HDL (ModelSim-Altera) . . . . . . . . . . . . . . . . . . . . 2-22
Performing Functional Simulation in Verilog HDL (ModelSim/QuestaSim) . . . . . . . . . . . . . . . 2-22
Gate-Level Timing Simulation for Stratix IV GX Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-22
Performing Gate-Level Timing Simulation in VHDL (ModelSim-Altera) . . . . . . . . . . . . . . . . . . 2-22
Performing Gate-Level Timing Simulation in VHDL (ModelSim/QuestaSim) . . . . . . . . . . . . . . 2-22
Performing Gate-Level Timing Simulation in Verilog HDL (ModelSim-Altera) . . . . . . . . . . . . . 2-23
Performing Gate-Level Timing Simulation in Verilog HDL (ModelSim/QuestaSim) . . . . . . . . 2-23
Functional Simulation for Stratix V GX Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-23
Performing Functional Simulation in VHDL (ModelSim/QuestaSim) . . . . . . . . . . . . . . . . . . . . . 2-24
Performing Functional Simulation in Verilog HDL (ModelSim-Altera) . . . . . . . . . . . . . . . . . . . . 2-24
Performing Functional Simulation in Verilog HDL (ModelSim/QuestaSim) . . . . . . . . . . . . . . . 2-24
Transport Delays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-24
+transport_path_delays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-24
+transport_int_delays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-24
Using the NativeLink Feature with ModelSim-Altera or ModelSim/QuestaSim Software . . . . . . . . 2-24
ModelSim/QuestaSim Error Message Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-25
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Contents
v
Generating a Timing Value Change Dump (.vcd) File for the PowerPlay Power Analyzer . . . . . . . .
Viewing a Waveform from a .wlf File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Scripting Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Generating a Post-Synthesis Simulation Netlist for ModelSim/QuestaSim . . . . . . . . . . . . . . . . . . .
Tcl Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Command Prompt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Generating a Gate-Level Timing Simulation Netlist for ModelSim/QuestaSim . . . . . . . . . . . . . . .
Tcl Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Command Line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Software Licensing and Licensing Setup in ModelSim-Altera Subscription Edition . . . . . . . . . . . . . .
LM_LICENSE_FILE Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Document Revision History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2-25
2-26
2-26
2-27
2-27
2-27
2-27
2-27
2-28
2-28
2-29
2-29
2-30
Chapter 3. Synopsys VCS and VCS MX Support
Software Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1
Using the VCS or VCS MX Software in the Quartus II Design Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1
Compiling Libraries Using the EDA Simulation Library Compiler . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2
Functional Simulations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2
Functional Simulation for Verilog HDL Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2
Functional Simulation for VHDL Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-3
Post-Synthesis Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-4
Post-Synthesis Simulation for Verilog HDL Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-5
Post-Synthesis Simulation for VHDL Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-5
Gate-Level Timing Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-6
Gate-Level Timing Simulation for Verilog HDL Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-6
Gate-Level Timing Simulation for VHDL Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-6
Disabling Timing Violation on Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-7
Performing Timing Simulation Using the Post-Synthesis Netlist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-7
Common VCS and VCS MX Software Compiler Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-8
Using DVE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-8
Debugging Support Command-Line Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-8
Simulating Designs that Include Transceivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-9
Functional Simulation for Stratix GX Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-9
Compiling Library Files for Functional Simulation in Verilog HDL . . . . . . . . . . . . . . . . . . . . . . . . 3-9
Gate-Level Timing Simulation for Stratix GX Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-9
Compiling Library Files for Gate-Level Timing Simulation in Verilog HDL . . . . . . . . . . . . . . . . 3-10
Functional Simulation for Stratix II GX Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-10
Compiling Library Files for Functional Simulation in Verilog HDL . . . . . . . . . . . . . . . . . . . . . . . 3-10
Gate-Level Timing Simulation for Stratix II GX Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-10
Compiling Library Files for Gate-Level Timing Simulation in Verilog HDL . . . . . . . . . . . . . . . . 3-11
Functional Simulation for Stratix IV GX Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-11
Compiling Library Files for Functional Simulation in Verilog HDL . . . . . . . . . . . . . . . . . . . . . . . 3-11
Gate-Level Timing Simulation for Stratix IV GX Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-11
Compiling Library Files for Gate-Level Timing Simulation in Verilog HDL . . . . . . . . . . . . . . . . 3-12
Functional Simulation for Stratix V GX Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-12
Compiling Library Files for Functional Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-12
Transport Delays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-13
+transport_path_delays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-13
+transport_int_delays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-13
Using NativeLink with the VCS or VCS MX Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-13
Generating a Timing .vcd File for the PowerPlay Power Analyzer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-13
Viewing a Waveform from a .vpd or .vcd File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-14
Scripting Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-15
© July 2010 Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
vi
Contents
Generating a Post-Synthesis Simulation Netlist for VCS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Tcl Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Command Prompt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Generating a Gate-Level Timing Simulation Netlist for VCS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Tcl Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Command Prompt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Document Revision History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3-15
3-15
3-15
3-15
3-15
3-15
3-16
3-16
Chapter 4. Cadence NC-Sim Support
Software Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1
Simulation Flow Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1
Operation Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2
Quartus II Software and NC Simulation Flow Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2
Compiling Libraries Using the EDA Simulation Library Compiler . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-3
Functional Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-3
Creating Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-4
For VHDL Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-4
For Verilog HDL Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-4
Compiling Source Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-5
Elaborating Your Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-6
Simulating Your Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-6
Post-Synthesis Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-7
Quartus II Simulation Output Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-7
Creating Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-7
Compiling Project Files and Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-7
Elaborating Your Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-7
Simulating Your Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-8
Gate-Level Timing Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-8
Generating a Gate-Level Timing Simulation Netlist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-8
Disabling Timing Violation on Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-8
Creating Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-9
Compiling Project Files and Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-9
Elaborating Your Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-9
Compiling the .sdo File (VHDL Only) in Command-Line Mode . . . . . . . . . . . . . . . . . . . . . . . . . . 4-10
Compiling the .sdo File (VHDL Only) in GUI Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-10
Simulating Your Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-10
Simulating Designs that Include Transceivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-10
Functional Simulation for Stratix GX Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-11
Compiling Library Files for Functional Simulation in VHDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-11
Compiling Library Files for Functional Simulation in Verilog HDL . . . . . . . . . . . . . . . . . . . . . . . 4-11
Gate-Level Timing Simulation for Stratix GX Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-11
Compiling Library Files for Gate-Level Timing Simulation in VHDL . . . . . . . . . . . . . . . . . . . . . 4-11
Compiling Library Files for Gate-Level Timing Simulation in Verilog HDL . . . . . . . . . . . . . . . . 4-12
Functional Simulation for Stratix II GX Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-12
Compiling Library Files for Functional Simulation in VHDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-13
Compiling Library Files for Functional Simulation in Verilog HDL . . . . . . . . . . . . . . . . . . . . . . . 4-13
Gate-Level Timing Simulation for Stratix II GX Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-13
Compiling Library Files for Gate-Level Timing Simulation in VHDL . . . . . . . . . . . . . . . . . . . . . 4-14
Compiling Library Files for Gate-Level Timing Simulation in Verilog HDL . . . . . . . . . . . . . . . . 4-14
Functional Simulation for Stratix IV GX Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-14
Compiling Library Files for Functional Simulation in VHDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-15
Compiling Library Files for Functional Simulation in Verilog HDL . . . . . . . . . . . . . . . . . . . . . . . 4-15
Gate-Level Timing Simulation for Stratix IV GX Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-15
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Contents
vii
Compiling Library Files for Gate-Level Timing Simulation in VHDL . . . . . . . . . . . . . . . . . . . . .
Compiling Library Files for Gate-Level Timing Simulation in Verilog HDL . . . . . . . . . . . . . . . .
Functional Simulation for Stratix V GX Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Compiling Library Files for Functional Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Compiling Library Files for Functional Simulation in VHDL . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Compiling Library Files for Functional Simulation in Verilog HDL . . . . . . . . . . . . . . . . . . . . . . .
Pulse Reject Delays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
-PULSE_R . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
-PULSE_INT_R . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Using the NativeLink Feature with NC-Sim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Generating a Timing VCD File for the PowerPlay Power Analyzer . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Viewing a Waveform from a .trn File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Scripting Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Generating NC-Sim Simulation Output Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Tcl Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Command Prompt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Document Revision History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4-16
4-16
4-16
4-17
4-17
4-17
4-18
4-18
4-18
4-18
4-18
4-19
4-20
4-20
4-20
4-21
4-21
4-21
Chapter 5. Aldec Active-HDL and Riviera-PRO Support
Software Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1
Using Active-HDL or Riviera-PRO Software in Quartus II Design Flows . . . . . . . . . . . . . . . . . . . . . . . . 5-1
Simulation Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-2
Simulation Library Files in the Quartus II Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-2
Disabling Timing Violation on Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-2
Compiling Libraries Using the EDA Simulation Library Compiler . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-2
Performing Simulation Using the Active-HDL Software (GUI Mode) . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-3
Simulating VHDL Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-3
Performing Functional Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-3
Simulating Verilog HDL Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-4
Performing Functional Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-4
Performing Simulation Using the Riviera-PRO Software (GUI Mode) . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-5
Performing Simulation Using the Active-HDL or Riviera-PRO Software (Command-Line Mode) . . . 5-6
Simulating Verilog HDL Designs Using the Active-HDL or Riviera-PRO Software . . . . . . . . . . . . . 5-6
Performing Functional Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-7
Performing Post-Synthesis Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-7
Performing Gate-Level Timing Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-8
Simulating VHDL Designs Using the Active-HDL or Riviera-PRO Software . . . . . . . . . . . . . . . . . . 5-8
Performing Functional Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-8
Performing Post-Synthesis Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-9
Performing Gate-Level Timing Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-10
Compiling System Verilog Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-10
Simulating Designs that Include Transceivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-10
Functional Simulation for Stratix II GX Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-11
Performing Functional Simulation in VHDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-11
Performing Functional Simulation in Verilog HDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-12
Gate-Level Timing Simulation for Stratix II GX Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-12
Performing Gate-Level Timing Simulation in VHDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-12
Performing Gate-Level Timing Simulation in Verilog HDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-12
Functional Simulation for Stratix GX Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-12
Performing Functional Simulation in VHDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-13
Performing Functional Simulation in Verilog HDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-13
Gate-Level Timing Simulation for Stratix GX Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-13
Performing Gate-Level Timing Simulation in VHDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-13
© July 2010 Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
viii
Contents
Performing Gate-Level Timing Simulation in Verilog HDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Functional Simulation for Stratix IV GX Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Performing Functional Simulation in VHDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Performing Functional Simulation in Verilog HDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Gate-Level Timing Simulation for Stratix IV GX Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Performing Gate-Level Timing Simulation in VHDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Performing Gate-Level Timing Simulation in Verilog HDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Functional Simulation for Stratix V GX Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Performing Functional Simulation in VHDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Performing Functional Simulation in Verilog HDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Transport Delays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Using the NativeLink Feature in Active-HDL or Riviera-PRO Software . . . . . . . . . . . . . . . . . . . . . . . .
Generating .vcd Files for the PowerPlay Power Analyzer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Scripting Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Generating a Post-Synthesis Simulation Netlist for Active-HDL or Riviera-PRO . . . . . . . . . . . . . .
Tcl Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Command Line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Generating a Gate-Level Timing Simulation Netlist for Active-HDL or Riviera-PRO . . . . . . . . . .
Tcl Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Command Line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Document Revision History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5-14
5-14
5-14
5-15
5-15
5-15
5-15
5-16
5-16
5-16
5-17
5-17
5-17
5-18
5-18
5-18
5-19
5-19
5-19
5-19
5-19
5-20
Chapter 6. Simulating Altera IP in Third-Party Simulation Tools
IP Functional Simulation Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-2
Verilog HDL and VHDL IPFS Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-3
Instantiate the IP in Your Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-4
Perform Functional Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-4
Simulating Altera IP Using the Quartus II NativeLink Feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-4
Perform Analysis and Elaboration on Your Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-5
Run Simulation Using the Quartus II NativeLink Feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-5
Simulating Altera IP Without the Quartus II NativeLink Feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-5
Using the EDA Simulation Library Compiler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-6
Design Language Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-6
Verilog HDL Example: Simulating the IPFS Model in the ModelSim SE Software . . . . . . . . . . . . . . 6-6
VHDL Example: Simulating the IPFS Model in the ModelSim SE Software . . . . . . . . . . . . . . . . . . . . 6-8
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-9
Document Revision History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-10
Section II. Timing Analysis
Chapter 7. The Quartus II TimeQuest Timing Analyzer
Getting Started with the TimeQuest Timing Analyzer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Running the TimeQuest Timing Analyzer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Running the TimeQuest Timing Analyzer from the Quartus II GUI . . . . . . . . . . . . . . . . . . . . . . . . . .
Running the TimeQuest Timing Analyzer as a Stand-Alone Application . . . . . . . . . . . . . . . . . . . . .
Running the quartus_sta Executable at a System Command Prompt . . . . . . . . . . . . . . . . . . . . . . . . .
Timing Analysis Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Open the Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Create a Timing Netlist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Constrain the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Update Timing Netlist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Generate Timing Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Quartus II Handbook Version 10.0 Volume 3: Verification
7-2
7-3
7-3
7-4
7-4
7-5
7-6
7-6
7-6
7-7
7-7
© July 2010 Altera Corporation
Contents
ix
The Timing Netlist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-8
Clock Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-11
Clock Setup Check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-11
Clock Hold Check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-12
Recovery and Removal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-13
Multicycle Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-14
Metastability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-16
Common Clock Path Pessimism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-17
Clock-As-Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-19
Collections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-20
Adding and Removing Collection Items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-21
SDC Constraint Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-22
Fitter and Timing Analysis with SDC Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-22
Specifying SDC Files for Place-and-Route . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-22
Specifying SDC Files for Static Timing Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-23
Synopsys Design Constraints File Precedence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-23
Clock Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-23
Generated Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-24
Virtual Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-26
Multi-Frequency Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-27
Automatic Clock Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-28
Derive PLL Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-28
Default Clock Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-30
Clock Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-30
Clock Effect Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-32
Clock Latency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-32
Clock Uncertainty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-33
Intra-Clock Transfers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-34
Inter-Clock Transfers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-34
I/O Interface Clock Transfers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-34
I/O Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-35
Input and Output Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-36
Set Input Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-36
Set Output Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-37
Delay and Skew Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-38
set_net_delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-38
set_max_skew . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-38
Timing Exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-39
Precedence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-39
False Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-39
Minimum Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-39
Maximum Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-40
Multicycle Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-41
Delay Annotation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-42
Constraint and Exception Removal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-43
Timing Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-43
report_timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-44
report_exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-45
report_metastability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-46
report_clock_transfers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-46
report_clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-47
report_min_pulse_width . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-47
report_net_timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-48
report_sdc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-48
© July 2010 Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
x
Contents
report_ucp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
report_bottleneck . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
report_datasheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
report_rskm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
report_tccs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
report_partitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
report_path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
report_net_delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
report_max_skew . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
report_skew . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
check_timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
report_clock_fmax_summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
create_timing_summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Other Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Multi-Corner Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Advanced I/O Timing and Board Trace Model Assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Wildcard Assignments and Collections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Resetting a Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Cross-Probing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
locate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The Quartus II Software Options and Compilation Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Document Revision History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7-49
7-49
7-50
7-50
7-51
7-51
7-51
7-53
7-53
7-54
7-55
7-55
7-56
7-57
7-57
7-59
7-59
7-60
7-61
7-61
7-62
7-63
7-63
Chapter 8. Best Practices for the Quartus II TimeQuest Timing Analyzer
Clock Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Base Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Derived Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Virtual Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
I/O Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Input Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Output Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
False Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Minimum and Maximum Delays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Multicycles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Document Revision History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8-1
8-1
8-2
8-2
8-4
8-4
8-5
8-5
8-5
8-6
8-6
8-7
8-7
Chapter 9. Switching to the Quartus II TimeQuest Timing Analyzer
Benefits of Switching to the Quartus II TimeQuest Timing Analyzer . . . . . . . . . . . . . . . . . . . . . . . . .
Chapter Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Switching Your Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Compile Your Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Create an .sdc File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Conversion Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Start the Quartus II TimeQuest Timing Analyzer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Set the Default Timing Analyzer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Differences Between the Timing Analyzers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Netlists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Collections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Quartus II Handbook Version 10.0 Volume 3: Verification
9-1
9-1
9-2
9-2
9-2
9-2
9-3
9-3
9-3
9-4
9-4
9-5
9-5
© July 2010 Altera Corporation
Contents
xi
Constraint Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-5
Constraint Entry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-6
Constraint File Priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-7
Constraint Priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-9
Ambiguous Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-9
Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-10
Related and Unrelated Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-10
Clock Offset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-11
Clock Latency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-11
Offset and Latency Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-11
Clock Uncertainty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-13
Derived and Generated Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-14
Automatic Clock Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-15
Hold Relationship . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-17
Clock Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-18
Hold Multicycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-18
Fitter Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-20
Fitter Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-20
Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-20
Paths and Pairs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-21
Default Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-21
Netlist Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-21
Non-Integer Clock Periods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-22
Other Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-23
Timing Assignment Conversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-24
Setup Relationship . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-24
Hold Relationship . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-25
Clock Latency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-25
Clock Uncertainty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-25
Inverted Clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-25
Not a Clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-26
Default Required fMAX Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-26
Virtual Clock Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-26
Clock Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-27
Multicycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-27
Clock Enable Multicycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-28
I/O Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-28
Input and Output Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-29
tSU Requirement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-29
tH Requirement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-31
tCO Requirement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-33
Minimum tCO Requirement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-35
tPD Requirement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-37
Minimum tPD Requirement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-38
Cut Timing Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-38
Maximum Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-38
Minimum Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-39
Maximum Clock Arrival Skew . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-39
Maximum Data Arrival Skew . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-39
Constraining Skew on an Output Bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-39
Conversion Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-41
Unsupported Global Assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-41
Recommended Global Assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-41
Clock Conversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-42
© July 2010 Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
xii
Contents
Instance Assignment Conversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
PLL Phase Shift Conversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
tCO Requirement Conversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Entity-Specific Assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Paths Between Unrelated Clock Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Unsupported Instance Assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Reviewing Conversion Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Warning Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Clock Transfers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Path Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Unconstrained Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Bus Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Other . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Re-Running the Conversion Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Output Pin Load Assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Constraint Target Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
DDR Constraints with the DDR Timing Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Unsupported SDC Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Constraint Passing and Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Clock Network Delay Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Project Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Conversion Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
tPD and Minimum tPD Requirement Conversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Document Revision History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9-43
9-45
9-46
9-46
9-47
9-47
9-47
9-47
9-49
9-49
9-49
9-50
9-50
9-50
9-50
9-50
9-50
9-51
9-51
9-51
9-51
9-51
9-52
9-52
9-52
9-52
Chapter 10. Quartus II Classic Timing Analyzer
Timing Analysis Tool Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2
Static Timing Analysis Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2
Clock Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-4
Clock Setup Check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-4
Clock Hold Check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-6
Multicycle Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-7
Clock Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-8
Individual Clock Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-8
Default Clock Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-8
Clock Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-9
Base Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-9
Derived Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-9
Undefined Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-9
PLL Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-10
Clock Uncertainty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-10
Clock Latency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-11
Timing Exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-13
Multicycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-14
Destination Multicycle Setup Exception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-14
Destination Multicycle Hold Exception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-14
Source Multicycle Setup Exception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-15
Source Multicycle Hold Exception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-16
Default Hold Multicycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-16
Clock Enable Multicycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-16
Setup Relationship and Hold Relationship . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-19
Maximum Delay and Minimum Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-20
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Contents
xiii
False Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
I/O Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
External Input Delay and Output Delay Assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Input Delay Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Output Delay Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Virtual Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Asynchronous Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Recovery and Removal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Recovery Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Removal Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Skew Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Maximum Clock Arrival Skew . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Maximum Data Arrival Skew . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Generating Timing Analysis Reports with report_timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Other Timing Analyzer Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Wildcard Assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Assignment Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fast Corner Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Early Timing Estimation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Timing Constraint Checker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Latch Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Timing Analysis Using the Quartus II GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Assignment Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Timing Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Clock Settings Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
More Timing Settings Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Timing Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Advanced List Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Early Timing Estimate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Assignment Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Scripting Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Creating Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Base Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Derived Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Clock Latency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Clock Uncertainty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Cut Timing Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Input Delay Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Maximum and Minimum Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Maximum Clock Arrival Skew . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Maximum Data Arrival Skew . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Multicycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Output Delay Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Report Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Setup and Hold Relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Assignment Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Virtual Clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
MAX+PLUS II Timing Analysis Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
fM AX Relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Slack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
I/O Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
tSU Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
tH Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
tCO Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
© July 2010 Altera Corporation
10-20
10-22
10-22
10-22
10-23
10-24
10-25
10-25
10-25
10-27
10-29
10-29
10-29
10-30
10-31
10-31
10-32
10-33
10-33
10-34
10-34
10-35
10-35
10-36
10-36
10-36
10-36
10-37
10-38
10-38
10-39
10-39
10-39
10-39
10-39
10-40
10-40
10-40
10-41
10-41
10-41
10-41
10-42
10-42
10-42
10-43
10-43
10-43
10-43
10-43
10-44
10-44
10-45
10-45
Quartus II Handbook Version 10.0 Volume 3: Verification
xiv
Contents
Minimum tCO (min tCO ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
tPD Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Minimum tPD (min tPD ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Document Revision History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10-46
10-46
10-47
10-47
10-47
Chapter 11. Synopsys PrimeTime Support
Quartus II Settings for Generating the PrimeTime Software Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-1
Files Generated for the PrimeTime Software Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-2
The Netlist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-2
The .sdo File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-2
Generating Multiple Operating Conditions with the TimeQuest Analyzer . . . . . . . . . . . . . . . . . 11-3
The Tcl Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-4
Generated File Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-6
Running the PrimeTime Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-7
Analyzing Quartus II Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-7
Other pt_shell Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-7
PrimeTime Timing Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-8
Sample PrimeTime Software Timing Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-8
Comparing Timing Reports from the Classic Timing Analyzer and the PrimeTime Software . . . 11-8
Clock Setup Relationship and Slack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-9
Clock Hold Relationship and Slack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-12
Input Delay and Output Delay Relationships and Slack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-15
Static Timing Analyzer Differences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-17
Classic Timing Analyzer and PrimeTime Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-17
Rise/Fall Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-17
Minimum and Maximum Delays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-17
Recovery/Removal Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-17
Encrypted Intellectual Property Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-17
Registered Clock Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-18
Multiple Source and Destination Register Pairs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-18
Latches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-18
LVDS I/O . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-19
Clock Latency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-19
Input and Output Delay Assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-19
Generated Clocks Derived from Generated Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-19
TimeQuest Timing Analyzer and PrimeTime Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-19
Encrypted Intellectual Property Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-19
Latches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-20
LVDS I/O . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-20
The TimeQuest Timing Analyzer .sdc File and PrimeTime Compatibility . . . . . . . . . . . . . . . . 11-20
Clock and Data Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-20
Inverting and Non-Inverting Propagation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-20
Multiple Rise/Fall Numbers For a Timing Arc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-20
Virtual Generated Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-21
Generated Clocks Derived from Generated Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-21
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-21
Document Revision History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-21
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Contents
xv
Section III. Power Estimation and Analysis
Chapter 12. PowerPlay Power Analysis
Creating PowerPlay EPE Spreadsheets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-2
PowerPlay EPE File Generator Compilation Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-3
Types of Power Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-4
Factors Affecting Power Consumption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-4
Device Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-4
Environmental Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-5
Airflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-5
Heat Sink and Thermal Compound . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-5
Junction Temperature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-5
Board Thermal Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-5
Device Resource Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-6
Number, Type, and Loading of I/O Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-6
Number and Type of Logic Elements, Multiplier Elements, and RAM Blocks . . . . . . . . . . . . . . 12-6
Number and Type of Global Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-6
Signal Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-6
PowerPlay Power Analyzer Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-7
Operating Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-7
Signal Activities Data Sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-9
Simulation Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-9
Using Simulation Files in Modular Design Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-10
Complete Design Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-11
Modular Design Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-12
Multiple Simulations on the Same Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-12
Overlapping Simulations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-13
Partial Simulations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-13
Node Name Matching Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-13
Glitch Filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-14
Node and Entity Assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-15
Timing Assignments to Clock Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-16
Default Toggle Rate Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-16
Vectorless Estimation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-16
Using the PowerPlay Power Analyzer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-17
Common Analysis Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-17
Signal Activities from Full Post-Fit Netlist (Timing) Simulation . . . . . . . . . . . . . . . . . . . . . . . . . 12-17
Signal Activities from Full Post-Fit Netlist (Zero Delay) Simulation . . . . . . . . . . . . . . . . . . . . . . 12-17
Signal Activities from RTL (Functional) Simulation, Supplemented by Vectorless Estimation . . . .
12-17
Signal Activities from Vectorless Estimation and User-Supplied Input Pin Activities . . . . . . . 12-18
Signal Activities from User Defaults Only . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-18
Generating a .vcd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-18
Generating a .vcd from ModelSim Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-19
Generating a .vcd from Full Post-Fit Netlist (Zero Delay) Simulation . . . . . . . . . . . . . . . . . . . . 12-20
Running the PowerPlay Power Analyzer Using the Quartus II GUI . . . . . . . . . . . . . . . . . . . . . . . . 12-20
PowerPlay Power Analyzer Compilation Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-23
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-23
Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-23
Simulation Files Read . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-24
Operating Conditions Used . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-24
Thermal Power Dissipated by Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-24
Thermal Power Dissipation by Block Type (Device Resource Type) . . . . . . . . . . . . . . . . . . . . . . 12-24
© July 2010 Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
xvi
Contents
Thermal Power Dissipation by Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Core Dynamic Thermal Power Dissipation by Clock Domain . . . . . . . . . . . . . . . . . . . . . . . . . . .
Current Drawn from Voltage Supplies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Confidence Metric Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Signal Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Specific Rules for Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Scripting Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Running the PowerPlay Power Analyzer from the Command–Line . . . . . . . . . . . . . . . . . . . . .
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Document Revision History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12-24
12-24
12-24
12-25
12-25
12-25
12-25
12-26
12-26
12-27
12-28
Section IV. System Debugging Tools
Chapter 13. System Debugging Tools Overview
System Debugging Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-1
Analysis Tools for RTL Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-3
Resource Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-4
Pin Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-5
Usability Enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-6
Stimulus-Capable Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-8
In-System Sources and Probes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-8
In-System Memory Content Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-8
Virtual JTAG Interface Megafunction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-9
System Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-9
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-9
Document Revision History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-10
Chapter 14. Analyzing and Debugging Designs with the System Console
Setting Up the System Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-1
Interactive Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-1
Using the System Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-2
SOPC Builder Communications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-2
Console Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-4
Plug-ins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-5
Design Service Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-6
Data Pattern Generator Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-6
Data Pattern Checker Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-8
Programmable Logic Device (PLD) Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-9
Board Bring-Up Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-9
JTAG Debug Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-9
Clock and Reset Signal Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-10
Avalon-MM Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-10
Processor Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-12
Bytestream Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-12
Transceiver Toolkit Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-12
System Console Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-17
LED Light Show Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-18
JTAG Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-20
Verify JTAG Chain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-20
Verify Clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-21
Checksum Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-21
Nios II Processor Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-24
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Contents
xvii
Device Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-26
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-26
Document Revision History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-26
Chapter 15. Transceiver Link Debugging Using the Quartus II Software
Transceiver Toolkit Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-1
Auto Sweep . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-1
EyeQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-2
Control Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-2
Transceiver Link Debugging Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-2
Test Setup for Link Debugging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-2
Custom_phy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-4
Data Pattern Generator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-4
Data Checker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-5
Compiling Design Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-6
Changing Pin Assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-6
Transceiver Toolkit Link Test Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-7
Loading the Project in System Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-7
Linking the Hardware Resource . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-7
Creating the Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-8
Running the Link Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-9
Viewing Results in the EyeQ Feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-9
Tcl Script in System Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-11
Running Tcl Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-11
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Conclusion 15-12
Document Revision History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-12
Chapter 16. Quick Design Debugging Using SignalProbe
Debugging Using the SignalProbe Feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Reserve the SignalProbe Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Perform a Full Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Assign a SignalProbe Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Add Registers to the Pipeline Path to SignalProbe Pin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Perform a SignalProbe Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Analyze the Results of the SignalProbe Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Performing a SignalProbe Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Understanding the Results of a SignalProbe Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Analyzing SignalProbe Routing Failures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Scripting Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Make a SignalProbe Pin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Delete a SignalProbe Pin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Enable a SignalProbe Pin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Disable a SignalProbe Pin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Perform a SignalProbe Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Script Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Reserving SignalProbe Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Common Problems When Reserving a SignalProbe Pin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Adding SignalProbe Sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Assigning I/O Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Adding Registers for Pipelining . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Run SignalProbe Automatically . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Run SignalProbe Manually . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Enable or Disable All SignalProbe Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
© July 2010 Altera Corporation
16-1
16-1
16-2
16-2
16-2
16-3
16-3
16-4
16-4
16-6
16-6
16-6
16-7
16-7
16-7
16-7
16-7
16-7
16-7
16-8
16-8
16-8
16-9
16-9
16-9
Quartus II Handbook Version 10.0 Volume 3: Verification
xviii
Contents
Allow SignalProbe to Modify Fitting Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-9
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-9
Document Revision History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-10
Chapter 17. Design Debugging Using the SignalTap II Logic Analyzer
Hardware and Software Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-2
Design Flow Using the SignalTap II Logic Analyzer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-4
SignalTap II Logic Analyzer Task Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-4
Add the SignalTap II Logic Analyzer to Your Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-5
Configure the SignalTap II Logic Analyzer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-5
Define Trigger Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-6
Compile the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-6
Program the Target Device or Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-6
Run the SignalTap II Logic Analyzer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-6
View, Analyze, and Use Captured Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-7
Embedding Multiple Analyzers in One FPGA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-7
Monitoring FPGA Resources Used by the SignalTap II Logic Analyzer . . . . . . . . . . . . . . . . . . . . . . 17-7
Using the MegaWizard Plug-In Manager to Create Your Logic Analyzer . . . . . . . . . . . . . . . . . . . . 17-8
Configure the SignalTap II Logic Analyzer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-8
Assigning an Acquisition Clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-8
Adding Signals to the SignalTap II File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-9
Signal Preservation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-10
Assigning Data Signals Using the Technology Map Viewer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-11
Node List Signal Use Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-11
Untappable Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-11
Adding Signals with a Plug-In . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-12
Adding Finite State Machine State Encoding Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-13
Modifying and Restoring Mnemonic Tables for State Machines . . . . . . . . . . . . . . . . . . . . . . . . . 17-13
Additional Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-14
Specifying the Sample Depth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-14
Capturing Data to a Specific RAM Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-14
Choosing the Buffer Acquisition Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-14
Non-Segmented Buffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-15
Segmented Buffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-16
Using the Storage Qualifier Feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-16
Input Port Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-19
Transitional Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-20
Conditional Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-21
Start/Stop Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-22
State-Based . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-23
Showing Data Discontinuities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-23
Disable Storage Qualifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-23
Managing Multiple SignalTap II Files and Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-24
Define Triggers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-25
Creating Basic Trigger Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-25
Creating Advanced Trigger Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-26
Examples of Advanced Triggering Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-27
Trigger Condition Flow Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-28
Sequential Triggering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-28
State-Based Triggering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-29
SignalTap II Trigger Flow Description Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-32
State Labels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-33
Boolean_expression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-33
Action_list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-34
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Contents
xix
Resource Manipulation Action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Buffer Control Action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
State Transition Action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Using the State-Based Storage Qualifier Feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Specifying the Trigger Position . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Creating a Power-Up Trigger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Enabling a Power-Up Trigger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Managing and Configuring Power-Up and Runtime Trigger Conditions . . . . . . . . . . . . . . . . .
Using External Triggers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Using the Trigger Out of One Analyzer as the Trigger In of Another Analyzer . . . . . . . . . . . .
Compile the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Faster Compilations with Quartus II Incremental Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Enabling Incremental Compilation for Your Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Using Incremental Compilation with the SignalTap II Logic Analyzer . . . . . . . . . . . . . . . . . . .
Preventing Changes Requiring Recompilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Timing Preservation with the SignalTap II Logic Analyzer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Performance and Resource Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Program the Target Device or Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Querying the SignalTap II Instance on a Programmed Device . . . . . . . . . . . . . . . . . . . . . . . . . .
Run the SignalTap II Logic Analyzer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Runtime Reconfigurable Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
SignalTap II Status Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
View, Analyze, and Use Captured Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Capturing Data Using Segmented Buffers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Differences in Pre-fill Write Behavior Between Different Acquisition Modes . . . . . . . . . . . . . . . .
Creating Mnemonics for Bit Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Automatic Mnemonics with a Plug-In . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Locating a Node in the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Saving Captured Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Exporting Captured Data to Other File Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Creating a SignalTap II List File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Other Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Using the SignalTap II MATLAB MEX Function to Capture Data . . . . . . . . . . . . . . . . . . . . . . . . . .
Using SignalTap II in a Lab Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Remote Debugging Using the SignalTap II Logic Analyzer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Equipment Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Using the SignalTap II Logic Analyzer in Devices with Configuration Bitstream Security . . . . .
Backward Compatibility with Previous Versions of Quartus II Software . . . . . . . . . . . . . . . . . . . .
SignalTap II Scripting Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
SignalTap II Command-Line Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
SignalTap II Tcl Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Design Example: Using SignalTap II Logic Analyzers in SOPC Builder Systems . . . . . . . . . . . . . . .
Custom Triggering Flow Application Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Design Example 1: Specifying a Custom Trigger Position . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Design Example 2: Trigger When triggercond1 Occurs Ten Times between triggercond2 and
triggercond3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Document Revision History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
© July 2010 Altera Corporation
17-34
17-34
17-35
17-35
17-39
17-40
17-40
17-41
17-42
17-42
17-44
17-44
17-45
17-45
17-47
17-48
17-48
17-49
17-50
17-52
17-54
17-56
17-57
17-57
17-59
17-60
17-61
17-61
17-62
17-62
17-62
17-63
17-63
17-64
17-64
17-65
17-65
17-65
17-66
17-66
17-67
17-68
17-69
17-69
17-70
17-71
17-71
Quartus II Handbook Version 10.0 Volume 3: Verification
Chapter Revision Dates
The chapters in this book, Quartus II Handbook Version 10.0 Volume 3: Verification, were
revised on the following dates. Where chapters or groups of chapters are available
separately, part numbers are listed.
Chapter 1
Simulating Designs with EDA Tools
Revised:
July 2010
Part Number: QII53025-10.0.0
Chapter 2
Mentor Graphics ModelSim/
QuestaSim Support
Revised:
July 2010
Part Number: QII53001-10.0.0
Chapter 3
Synopsys VCS and VCS MX Support
Revised:
July 2010
Part Number: QII53002-10.0.0
Chapter 4
Cadence NC-Sim Support
Revised:
July 2010
Part Number: QII53003-10.0.0
Chapter 5
Aldec Active-HDL and
Riviera-PRO Support
Revised:
July 2010
Part Number: QII53023-10.0.0
Chapter 6
Simulating Altera IP in Third-Party Simulation Tools
Revised:
August 2010
Part Number: QII53014-10.0.1
Chapter 7
The Quartus II TimeQuest Timing Analyzer
Revised:
July 2010
Part Number: QII53018-10.0.0
Chapter 8
Best Practices for the Quartus II TimeQuest Timing Analyzer
Revised:
July 2010
Part Number: QII53024-10.0.0
Chapter 10 Quartus II Classic Timing Analyzer
Revised:
July 2010
Part Number: QII53004-10.0.0
Chapter 11 Synopsys PrimeTime Support
Revised:
July 2010
Part Number: QII53005-10.0.0
Chapter 12 PowerPlay Power Analysis
Revised:
July 2010
Part Number: QII53013-10.0.0
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
xxiv
Chapter Revision Dates
Chapter 13 System Debugging Tools Overview
Revised:
July 2010
Part Number: QII53027-10.0.0
Chapter 14 Analyzing and Debugging Designs with the System Console
Revised:
July 2010
Part Number: QII53028-10.0.0
Chapter 15 Transceiver Link Debugging Using the Quartus II Software
Revised:
August 2010
Part Number: QII53029-10.0.1
Chapter 16 Quick Design Debugging Using SignalProbe
Revised:
July 2010
Part Number: QII53008-10.0.0
Chapter 17 Design Debugging Using the SignalTap II Logic Analyzer
Revised:
July 2010
Part Number: QII53009-10.0.0
Chapter 18 In-System Debugging Using External Logic Analyzers
Revised:
August 2010
Part Number: QII53016-10.0.1
Chapter 19 In-System Modification of Memory and Constants
Revised:
August 2010
Part Number: QII53012-10.0.1
Chapter 20 Design Debugging Using In-System Sources and Probes
Revised:
July 2010
Part Number: QII53021-10.0.0
Chapter 21 Cadence Encounter Conformal Support
Revised:
July 2010
Part Number: QII53011-10.0.0
Chapter 22 Quartus II Programmer
Revised:
July 2010
Part Number: QII53022-10.0.0
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Section I. Simulation
As the design complexity of FPGAs continues to rise, verification engineers are
finding it increasingly difficult to simulate their system-on-a-programmable-chip
(SOPC) designs in a timely manner. The verification process is now the bottleneck in
the FPGA design flow. The Quartus II software provides a wide range of features for
performing functional and timing simulation of designs in EDA simulation tools.
This section includes the following chapters:
■
Chapter 1, Simulating Designs with EDA Tools
This chapter provides guidelines to help you perform simulation for your Altera®
designs using EDA simulators and the Quartus II NativeLink feature.
■
Chapter 2, Mentor Graphics ModelSim/ QuestaSim Support
This chapter provides detailed instructions about how to simulate your design in
the ModelSim-Altera® software or the Mentor Graphics® ModelSim software.
■
Chapter 3, Synopsys VCS and VCS MX Support
This chapter describes how to use the Synopsys VCS and VCS MX software to
simulate designs that target Altera FPGAs.
■
Chapter 4, Cadence NC-Sim Support
This chapter describes the basic NC-Sim, NC-Verilog, and NC-VHDL functional,
post-synthesis, and gate-level timing simulations.
■
Chapter 5, Aldec Active-HDL and Riviera-PRO Support
This chapter describes how to use the Active-HDL software to simulate designs
that target Altera FPGAs.
■
Chapter 6, Simulating Altera IP in Third-Party Simulation Tools
This chapter describes the process for instantiating the IP megafunctions in your
design and simulating their functional simulation models in Altera-supported,
third-party simulation tools.
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
I–2
Quartus II Handbook Version 10.0 Volume 3: Verification
Section I: Simulation
© July 2010 Altera Corporation
1. Simulating Designs with EDA Tools
QII53025-10.0.0
This chapter provides guidelines to help you perform simulation for your Altera®
designs using EDA simulators and the Quartus® II NativeLink feature.
Introduction
The Quartus II software assists you in FPGA and ASIC designs, from RTL level to
on-chip level. Simulation is the process of verifying the design behavior and timing
before configuring the chip.
In previous versions of the Quartus II software, you could use either the Quartus II
simulator or an EDA simulator to perform your simulation. The Quartus II software
no longer supports a built-in simulator, and you must use EDA simulators to perform
simulation.
This chapter guides you through simulation of your Altera design using EDA
simulators. There are two ways to simulate your Altera design using EDA simulators:
■
Use the NativeLink feature to automatically create scripts for EDA simulators and
launch them
■
Perform manual simulation using EDA simulators
This chapter focuses on the steps required to perform your simulation using EDA
simulators with the NativeLink feature.
Manual simulation using EDA simulators is described in the Simulation section in
volume 3 of the Quartus II Handbook.
This chapter includes the following topics:
© July 2010
■
“PLD Design Flow” on page 1–2
■
“Simulation Libraries” on page 1–5
■
“EDA Simulation Library Compiler” on page 1–9
■
“Using the NativeLink Feature” on page 1–11
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
1–2
Chapter 1: Simulating Designs with EDA Tools
PLD Design Flow
PLD Design Flow
This section describes the programmable logic device (PLD) design flow.
Figure 1–1 shows the Altera design flow using EDA simulators and the Quartus II
software.
Figure 1–1. Altera Design Flow Using EDA Simulators and the Quartus II Software
.v/.vhd
Design Entry
Synthesis
Place and Route
Altera IP
.v/.vhd
RTL
Simulation
Library Files (2)
RTL Simulation (1), (3)
Generate Simulation
Netlist Files (Functional)
.vo/.vho
Generate Simulation
Netlist Files (Timing)
.vo/.vho
.sdo (4)
Timing Analysis
Program into
Device, PCB Board
Simulation, and Test
Post-Synthesis
Simulation (1), (3)
Gate-Level
Simulation
Library Files (2)
Gate-Level
Simulation (1), (3)
.v/.vhd
.v/.vhd
Testbench
Notes to Figure 1–1:
(1) Simulation can be run with the NativeLink feature or performed manually.
(2) ModelSim-Altera does not require simulation library source files for simulation.
(3) The simulation tools include ModelSim, ModelSim-Altera, QuestaSim, VCS, VCS MX, NCSim, Active-HDL, and Riviera-PRO.
(4) .vo, .vho, and .sdo are generated by the Quartus II Netlist Writer.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 1: Simulating Designs with EDA Tools
PLD Design Flow
1–3
RTL Functional Simulation Flow
Figure 1–2 shows the overall RTL functional simulation flow from the Quartus II
software. For information about running EDA simulation automatically through the
Quartus II software, refer to “Using the NativeLink Feature” on page 1–11.
f
For information about manual simulation, refer to the EDA simulator chapters in the
Simulation section in volume 3 of the Quartus II Handbook.
Figure 1–2. : EDA RTL Functional Simulation Flow from the Quartus II Software
Create your design and
testbench
BDF to HDL Conversion (1)
(If your design is created
in BDF)
Manual Simulation (ModelSim/QuestaSim Chapter) (5)
Compile Altera
Libraries with EDA
Simulation Library
Compiler? (2)
N
Y
Manual Simulation (VCS/VCS MX Chapter) (6)
EDA Simulation Library Compiler (3)
Manual Simulation (NCSim Chapter) (7)
Manual Simulation (Active-HDL/Riviera-PRO Chapter) (8)
Simulate via
NativeLink?
N
Y
NativeLink Topic (4)
Notes to Figure 1–2:
(1) For more information, refer to “Converting BDF Format to HDL Format” on page 1–4.
(2) Do not compile the Altera libraries if you are using ModelSim-Altera or ModelSim-Altera Web Edition.
(3) For more information, refer to Compiling Simulation Libraries in the Quartus II Software in Quartus II Help.
(4) For more information, refer to Using the NativeLink Feature with Other EDA Tools in Quartus II Help.
(5) For more information, refer to Performing a Functional Simulation with the ModelSim Software or Performing a Functional Simulation with the
QuestaSim Software in Quartus II Help.
(6) For more information, refer to Performing a Functional Simulation with the VCS Software or Performing a Functional Simulation with the VCS-MX
Software in Quartus II Help.
(7) For more information, refer to Performing a Functional Simulation with the NCSim Software in Quartus II Help.
(8) For more information, refer to Performing a Simulation of a Verilog HDL Design with the Active-HDL Software, Performing a Simulation of a VHDL
Design with the Active-HDL Software, or Performing an RTL Functional Simulation with the Riviera-PRO Software in Quartus II Help.
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
1–4
Chapter 1: Simulating Designs with EDA Tools
PLD Design Flow
Gate-Level Timing Simulation Flow
Figure 1–3 shows the overall gate-level timing simulation flow from the Quartus II
software. For information about running EDA simulation automatically through the
Quartus II software, refer to “Using the NativeLink Feature” on page 1–11.
f
For information about manual simulation, refer to the EDA simulator chapters in the
Simulation section in volume 3 of the Quartus II Handbook.
Figure 1–3. EDA Gate-Level Timing Simulation Flow from Quartus II Software
Create your design and
testbench
Synthesis and Fitting
Timing Analysis
Generate Simulation Netlist (1)
Manual Simulation (ModelSim/QuestaSim Chapter) (5)
Compile Altera
Libraries with EDA
Simulation Library
Compiler? (2)
N
Simulate via
NativeLink?
Y
Manual Simulation (VCS/VCS MX Chapter) (6)
EDA Simulation Library Compiler (3)
Manual Simulation (NCSim Chapter) (7)
Manual Simulation (Active-HDL/Riviera-PRO Chapter) (8)
N
Y
NativeLink Topic (4)
Notes to Figure 1–3:
(1) For more information, refer to “Simulation Netlist Files” on page 1–6.
(2) Do not compile the Altera libraries if you are using ModelSim-Altera or ModelSim-Altera Web Edition.
(3) For more information, refer to Compiling Simulation Libraries in the Quartus II Software in Quartus II Help.
(4) For more information, refer to Using the NativeLink Feature with Other EDA Tools in Quartus II Help.
(5) For more information, refer to Performing a Timing Simulation with the ModelSim Software or Performing a Timing Simulation with the QuestaSim
Software in Quartus II Help.
(6) For more information, refer to Performing a Timing Simulation with the VCS Software or Performing a Timing Simulation with the VCS-MX (VHDL)
Software in Quartus II Help.
(7) For more information, refer to Performing a Timing Simulation with the NCSim Software in Quartus II Help.
(8) For more information, refer to Performing a Simulation of a Verilog HDL Design with the Active-HDL Software, Performing a Simulation of a VHDL
Design with the Active-HDL Software, or Performing a Gate-Level Simulation with the Riviera-PRO Software in Quartus II Help.
Converting BDF Format to HDL Format
If you create your design in BDF (Block Diagram Format), you must convert it to HDL
format (Verilog HDL or VHDL) to perform RTL functional simulation in EDA
simulators. To convert your design from BDF format to HDL format, follow these
steps:
1. Detach the BDF window.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 1: Simulating Designs with EDA Tools
Simulation Libraries
1–5
2. On the File menu, point to Create/Update and click Create HDL Design File for
Current File.
3. From the File type list, select VHDL or Verilog HDL.
4. Click OK.
After following these steps, the HDL file is generated. The HDL file and the BDF file
have the same name but different extensions (for example, if your BDF file is
example.bdf, the HDL file created is example.v or example.vhd).
Simulation Libraries
When you are using an EDA simulator, you must determine which libraries are
required for your simulation if you have used Altera megafunctions or IP in your
design.
RTL Functional Simulation
The following libraries are required to perform RTL functional simulation:
1
■
If your design does not include transceivers or a PCI Express® (PCIe®) core, you
need the AlteraBehaviorLibraries.
■
If your design includes transceivers, you need <family>_hssi_atoms, sgate, and
the AlteraBehaviorLibraries.
■
If your design includes a hard PCIe core, you need <family>_pcie_hip_atoms,
sgate, the above libraries, and the AlteraBehaviorLibraries.
■
For Stratix GX devices, you need stratixgx_mf, sgate, and the
AlteraBehaviorLibraries.
AlteraBehaviorLibraries refers to altera_mf, 220model, and altera_primitives.
If you are targeting a Stratix V device, compile the following files in the
quartus/eda/sim_lib/<vendor> directory:
■
stratixv_atoms_ncrypt.v
■
stratixv_hssi_atoms_ncrypt.v
■
stratixv_pcie_hip_atoms_ncrypt.v
These files contain IEEE encrypted Verilog models.
1
Vendor refers to Synopsys, Cadence Design Systems, Inc., Mentor Graphics, or Aldec,
Inc.
1
Compile stratixv_pcie_hip_atoms_ncrypt.v with the System Verilog option.
Also, compile the following files in the quartus/eda/sim_lib directory:
© July 2010
■
stratixv_atoms.v
■
stratixv_atoms.vhd
■
stratix_hssi_atoms.v
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
1–6
Chapter 1: Simulating Designs with EDA Tools
Simulation Libraries
■
stratix_hssi_atoms.vhd
■
stratixv_pcie_hip_atoms.v
■
stratixv_pcie_hip_atoms.vhd
■
stratixv_components.vhd
■
stratix_hssi_components.vhd
■
stratixv_pcie_hip_components.vhd
1
The PCIe files are required only if you are using the PCIe hard IP.
1
To simulate Stratix V devices in VHDL, you need a VHDL or Verilog co-simulator.
f
For a list of all RTL functional simulation library files in the Quartus II directory, refer
to Altera Functional Simulation Libraries in Quartus II Help.
Gate-Level Timing Simulation
The following libraries are required to perform gate-level timing simulation:
f
■
If your design does not include transceivers or a PCIe core, you need
<family>_atoms, sgate, and the AlteraBehaviorLibraries.
■
If your design includes transceivers, you need <family>_hssi_atoms,
<family>_atoms, sgate, and the AlteraBehaviorLibraries.
■
If your design includes transceivers and a PCIe core, you need
<family>_pcie_hip_atoms, <family>_hssi_atoms, <family>_atoms, sgate, and the
AlteraBehaviorLibraries.
For a list of all gate-level timing and post-fit simulation library files in the Quartus II
directory, refer to Altera Post-Fit Libraries in Quartus II Help.
Simulation Netlist Files
Simulation netlist files are required to perform post-synthesis simulation or gate-level
timing simulation. These simulation netlist files are generated using the EDA Netlist
Writer.
If you are performing post-synthesis simulation, the Verilog HDL Output File (.vo) or
the VHDL Output File (.vho) is required. For the steps required to generate
post-synthesis simulation netlist files for .vo or .vho files, refer to “Generating
Post-Synthesis Simulation Netlist Files”.
If you are performing gate-level timing simulation, the .vo or .vho file and the
Standard Delay Format Output File (.sdo) are required. The .sdo file is used to
annotate the delay for the elements found in the .vo or .vho file.
f
To specify options for generating .vo, .vho, and .sdo files, refer to Specifying HDL
Output Settings in Quartus II Help.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 1: Simulating Designs with EDA Tools
Simulation Libraries
1–7
Generating Post-Synthesis Simulation Netlist Files
To generate post-synthesis simulation netlist files in the Quartus II software, perform
the following steps:
1. On the Processing menu, point to Start and click Start Analysis & Synthesis (you
can also perform this after step 2).
2. Configure the EDA Netlist Writer to generate functional simulation netlist. Refer
to Specifying HDL Output Settings in Quartus II Help.
3. On the Processing menu, point to Start and click Start EDA Netlist Writer.
During the EDA Netlist Writer stage, the Quartus II software produces a .vo or .vho
file that can be used for post-synthesis simulations in the EDA simulators. This netlist
file is mapped to architecture-specific primitives. No timing information is included
at this stage. The resulting netlist is located in the output directory you specified in the
Settings dialog box, which defaults to the <project directory>/simulation/<EDA
Simulator> directory (<EDA Simulator> can be modelsim, questasim, vcs, vcs mx,
rivierapro, ncsim, or activehdl).
If you want to generate a post-synthesis simulation netlist with just the cell delays,
you can generate an .sdo file without running the Fitter. In this case, the .sdo file
includes all timing values for only the device cells. Interconnect delays are not
included because fitting (placement and routing) was not performed. To generate the
post-synthesis netlist and the .sdo file, type the following commands at a command
prompt:
quartus_map <project name> -c <revision name> r
quartus_sta <project name> -c <revision name> --post_map r
or
quartus_tan <project name> -c <revision name> --post_map --\
zero_ic_delays r
quartus_eda <project name> -c <revision name> --simulation \
--tool= <3rd party EDA tool> --format=<HDL language> r
f
For more information about the -format and -tool options, type the following
command at a command prompt:
quartus_eda --help=<options> r
Generating Gate-Level Timing Simulation Netlist Files
To perform gate-level timing simulation, the EDA simulators require information
about how the design was placed into device-specific architectural blocks. The
Quartus II software provides this information in the form of a .vo file for Verilog HDL
designs and a .vho file for VHDL designs. The accompanying timing information is
stored in the .sdo file, which annotates the delay for the elements found in the .vo file
or .vho file. To generate a gate-level timing simulation netlist in the Quartus II
software, follow these steps:
1. Configure the EDA Netlist Writer to generate functional simulation netlist. Refer
to “Generating Post-Synthesis Simulation Netlist Files” on page 1–7.
2. If you have not run a full compilation prior to the fitting process, perform a full
compilation. On the Processing menu, click Start Compilation.
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
1–8
Chapter 1: Simulating Designs with EDA Tools
Simulation Libraries
3. On the Processing menu, point to Start and click Start EDA Netlist Writer.
During the full compilation or EDA Netlist Writer stage, the Quartus II software
produces a .vo, a .vho, and a .sdo file used for gate-level timing simulations in the
EDA simulators. This netlist file is mapped to architecture-specific primitives. The
timing information for the netlist is included in the .sdo file. The resulting netlist is
located in the output directory you specified in the Settings dialog box, which
defaults to the <project directory>/simulation/<EDA Simulator> directory (<EDA
Simulator> can be modelsim, questasim, vcs, vcs mx, rivierapro, ncsim, or activehdl).
Generating Timing Simulation Netlist Files with Different Timing Models
In Stratix III and later devices, you can specify different temperature and voltage
parameters to generate the timing simulation netlist files. If you enable the Quartus II
TimeQuest Timing Analyzer or the Quartus II Classic Timing Analyzer when
generating the timing simulation netlist files (.vo, .vho, and .sdo files), different
timing models for different operating conditions are used by default. Multi-corner
timing analysis is run by default during the full compilation.
To manually generate the simulation netlist files (.vo or .vho and .sdo) for the three
different operating conditions, follow these steps:
1. Generate all available corner models at all operating conditions by typing the
following command at a command prompt:
quartus_sta <project name> --multicorner r
2. Generate the timing simulation netlist files for all three corners by performing
steps 1 through 3 in “Generating Gate-Level Timing Simulation Netlist Files” on
page 1–7. The output files are generated in the simulation output directory.
The following examples show the timing simulation netlist files are generated for the
operating conditions of the preceding steps when Verilog HDL is selected as the
output netlist format.
First Slow Corner (slow, 1100 mV, 85° C)
■
.vo file—<revision name>.vo
■
.sdo file—<revision name>_v.sdo
The <revision_name>.vo and <revision name>_v.sdo are generated for backward
compatibility in case there are existing scripts that still use them.
■
.vo file—<revision name>_<speedgrade>_1100mv_85c_slow.vo
■
.sdo file—<revision name>_<speedgrade>_1100mv_85c_v_slow.sdo
Second Slow Corner (slow, 1100 mV, 0° C)
■
.vo file—<revision name>_<speedgrade>_1100mv_0c_slow.vo
■
.sdo file—<revision name>_<speedgrade>_1100mv_0c_v_slow.sdo
Fast Corner (fast, 1100 mV, 0° C)
■
.vo file—<revision name>_min_1100mv_0c_fast.vo
■
.sdo file—<revision name>_min_1100mv_0c_v_fast.sdo
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 1: Simulating Designs with EDA Tools
EDA Simulation Library Compiler
1–9
For older devices, a slow-corner (worst case) timing model is used by default. There
are only two timing models available: slow-corner and fast-corner. To generate the
timing simulation netlist files using a different timing model, you must run the
Quartus II TimeQuest Timing Analyzer or the Quartus II Classic Timing Analyzer
with a different timing model before you start the EDA Netlist Writer.
To run the Quartus II TimeQuest Timing Analyzer with a best-case model, use the
-fast_model option after you create the timing netlist.
The following command enables the fast timing model:
create_timing_netlist --fast_model r
To run the Quartus II Classic Timing Analyzer with the best-case model, on the
Processing menu, point to Start and click Start Classic Timing Analyzer (Fast Timing
Model). After timing analysis is complete, the Compilation Report appears.
You can also perform classic timing analysis with the fast timing model by typing the
following command at a command prompt:
quartus_tan <project_name> --fast_model=on r
After running the Quartus II TimeQuest Timing Analyzer or the Quartus II Classic
Timing Analyzer, perform steps 1 through 3 in “Generating Gate-Level Timing
Simulation Netlist Files” on page 1–7 to generate the timing simulation netlist file. For
fast corner timing models, the -fast post fix is added to the .vo or .vho and .sdo file
(for example, my_project_fast.vo or my_project_fast.vho and my_project_fast.sdo).
f
For more information about performing multi-corner timing analysis, refer to the
Quartus II TimeQuest Timing Analyzer chapter or the Quartus II Classic Timing Analyzer
chapter in volume 3 of the Quartus II Handbook.
EDA Simulation Library Compiler
The EDA Simulation Library Compiler compiles Verilog HDL and VHDL simulation
libraries for all Altera devices and supported third-party simulators. You can use this
tool to compile all libraries required for RTL functional and gate-level timing
simulation.
When the compilation targets third-party simulation tools such as ModelSim,
QuestaSim, Active-HDL, Riviera-PRO, VCS, VCS MX, and NCSim, the compiled
libraries are kept in the directory you specified. When you perform the simulation
using these simulators, you can use or reuse the compiled libraries and avoid the
overhead associated with redundant library compilations.
If the compilation targets third-party simulation tool VCS, then the VCS options file
simlib_comp.vcs is generated after compilation. You can then include your design
and testbench files in the option files and invoke them with the vcs command.
Before using the EDA Simulation Library Compiler, ensure that the appropriate
simulation tools are already installed and their execution paths are specified. To
specify the path, refer to “Setting Up the EDA Simulator Execution Path” on
page 1–11.
f
© July 2010
For more information about compiling Verilog HDL and VHDL simulation libraries
for all Altera devices and supported third-party simulators, refer to Compiling
Simulation Libraries in the Quartus II Software in Quartus II Help.
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
1–10
Chapter 1: Simulating Designs with EDA Tools
EDA Simulation Library Compiler
Running the EDA Simulation Library Compiler Through the GUI
1
The EDA Simulation Library Compiler does not support ModelSim-Altera because
ModelSim-Altera already contains precompiled libraries.
To compile libraries with the EDA Simulation Library Compiler GUI, follow these
steps:
1. On the Tools menu, click Launch EDA Simulation Library Compiler. The EDA
Simulation Library Compiler dialog box appears.
2. In the Tool name list under EDA simulation tool, select your preferred EDA
simulator. The Executable location box displays the location of the simulation tool
you specified. This location must be set before running the EDA Simulation
Library Compiler.
3. Under Library families, select one or more device families for your design
compilation and move them to the Selected families box.
4. Under Library language, select VHDL, Verilog HDL, or both.
5. Specify the output netlist destination by editing or browsing to a directory in the
Output directory box.
You can then link to the directory so that the NativeLink feature will reuse the
compiled libraries rather than compile the Altera Libraries. Refer to step 9 under
“Configuring NativeLink Settings” on page 1–12.
6. Click Start Compilation.
When the EDA Simulation Library Compiler finishes, for ModelSim, QuestaSim,
Active-HDL, Riviera-PRO, VCS MX, and NCSim, all required libraries are compiled
and stored in <output location you specified>/<verilog_libs or vhdl_libs>. The library files
(for example, modelsim.ini, cds.lib, and synopsys_sim.setup) are also generated and
stored in <output location you specified>.
When the EDA Simulation Library Compiler finishes, for VCS, the simlib_comp.vcs
file is generated. Example 1–1 shows the contents of the simlib_comp.vcs file.
Example 1–1.
+cli+1 -line -timescale=1ps/1ps \
-v /apps/quartus/9.0/quartus/eda/sim_lib/altera_primitives.v \
-v /apps/quartus/9.0/quartus/eda/sim_lib/220model.v \
-v /apps/quartus/9.0/quartus/eda/sim_lib/sgate.v \
-v /apps/quartus/9.0/quartus/eda/sim_lib/altera_mf.v \
-v /apps/quartus/9.0/quartus/eda/sim_lib/stratixii_atoms.v \
+incdir+/apps/quartus/9.0/quartus/eda/sim_lib
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 1: Simulating Designs with EDA Tools
Using the NativeLink Feature
1–11
If you manually run a simulation using the Synopsys VCS simulator, you must
include your design file and testbench file in the option file, .synopys_sim.setup, as
shown in Example 1–2.
Example 1–2.
+cli+1 -line -timescale=1ps/1ps design_file.v test_bench_file.vt\
-v /apps/quartus/9.0/quartus/eda/sim_lib/altera_primitives.v \
-v /apps/quartus/9.0/quartus/eda/sim_lib/220model.v \
-v /apps/quartus/9.0/quartus/eda/sim_lib/sgate.v \
-v /apps/quartus/9.0/quartus/eda/sim_lib/altera_mf.v \
-v /apps/quartus/9.0/quartus/eda/sim_lib/stratixiii_atoms.v \
+incdir+/apps/quartus/9.0/quartus/eda/sim_lib
To compile all of the libraries, design files, and testbench files, type the following
command:
vcs -file simlib_comp.vcs r
Running the EDA Simulation Library Compiler from the Command Line
To set the EDA tool executable location, type the following command:
export QUARTUS_INIT_PATH=$PATH
To run the EDA Simulation Library Compiler from the command line, type the
following command:
quartus_sh --simlib_comp -family <device> -tool <simulation tool name>
-tool_path <simulator executable location>
-language <language> -directory <directory> r
f
For more information about the command line options and how to use them, type the
following command:
quartus_sh --help=simlib_comp r
Using the NativeLink Feature
The NativeLink feature in the Quartus II software facilitates the seamless transfer of
information between the Quartus II software and EDA tools and allows you to run an
EDA simulator within the Quartus II software.
Setting Up the EDA Simulator Execution Path
To run an EDA simulator automatically from the Quartus II software using the
NativeLink feature, specify the path to your simulation tool by performing the
following steps:
1. On the Tools menu, click Options. The Options dialog box appears.
2. In the Category list, select EDA Tool Options.
3. Double-click the entry under Location of executable beside the name of your EDA
tool.
4. Type the path or browse to the directory containing the executables of your EDA
tool.
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
1–12
Chapter 1: Simulating Designs with EDA Tools
Using the NativeLink Feature
Table 1–1 lists the execution paths for each EDA simulator.
Table 1–1. Execution Paths for EDA Simulators
Simulator
Path
ModelSim-Altera
c:\<ModelSim-Altera installation path>\win32aloem (Windows)
/<ModelSim-Altera installation path>/linuxaloem (Linux)
ModelSim
c:\<ModelSim installation path>\win32 (Windows)
/<ModelSim installation path>/bin (Linux)
QuestaSim
c:\<QuestaSim installation path>\win32 (Windows)
/<QuestaSim installation path>/bin (Linux)
VCS/VCS MX
/<VCS MX installation path>/bin (Linux)
NCSim
/<NCSim installation path>/tools/bin (Linux)
Active-HDL
c:\<Active-HDL installation path>\bin (Windows)
Riviera-PRO
c:\<Riviera-PRO installation path>\bin (Windows)
5. Click OK.
You can also specify the path to the simulator’s executables by typing the
set_user_option Tcl command, as follows:
set_user_option -name EDA_TOOL_PATH_MODELSIM <path to executables> r
set_user_option -name EDA_TOOL_PATH_MODELSIM_ALTERA <path to \
executables> r
set_user_option -name EDA_TOOL_PATH_QUESTASIM <path to executables> r
set_user_option -name EDA_TOOL_PATH_VCS <path to executables> r
set_user_option -name EDA_TOOL_PATH_VCS_MX <path to executables> r
set_user_option -name EDA_TOOL_PATH_NCSIM <path to executables> r
set_user_option -name EDA_TOOL_PATH_ACTIVEHDL <path to executables> r
set_user_option -name EDA_TOOL_PATH_RIVIERAPRO <path to executables> r
Configuring NativeLink Settings
To configure NativeLink settings, follow these steps:
1. On the Assignments menu, click Settings. The Settings dialog box appears.
2. In the Category list, select Simulation. The Simulation page appears.
3. In the Tool name list, select your preferred EDA simulator.
4. For gate-level simulation, if you want to run simulation in your EDA simulator
automatically after Quartus II full compilation, turn on Run gate-level simulation
automatically after compilation.
5. If you have testbench files or macro scripts, enter the information under
NativeLink settings.
For more information about setting up a testbench file with NativeLink, refer to
“Setting Up Testbench Files Using the NativeLink Feature” on page 1–14.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 1: Simulating Designs with EDA Tools
Using the NativeLink Feature
1–13
1. If you want to run the EDA simulator in command-line mode, follow these steps:
a. On the Simulation page, click More NativeLink Settings. The More
NativeLink Settings dialog box appears.
b. Under Existing option settings, click Launch third-party EDA tool in
command-line mode.
c. In the Setting field, select On.
d. Click OK.
2. If you want to generate only the simulation script without launching the EDA
simulator during NativeLink simulation, follow these steps:
a. On the Simulation page, click More NativeLink Settings. The More
NativeLink Settings dialog box appears.
b. Under Existing option settings, click Generate third-party EDA tool
command scripts without running the EDA tool.
c. In the Setting field, select On.
d. Click OK.
If you turn this option on and run NativeLink, only the simulation command
script is generated. The file names of simulation command scripts for various
simulators are as follows:
<project_name>_run_msim_<rtl/gate>_level_<verilog/vhdl>.do (ModelSim)
<project_name>_run_questasim_<rtl/gate>_level_<verilog/vhdl>.do (QuestaSim)
<project_name>_sim_<rtl/gate>_<verilog/vhdl>.do (Riviera-PRO and Active-HDL)
script_file.sh and <project_name>_rtl.vcs (VCS)
<project_name>_vcsmx_<rtl/gate>_<vhdl/verilog>.tcl (VCS MX)
<project_name>_ncsim_<rtl/gate>_<verilog/vhdl>.tcl (NCSim)
8. Depending on the simulator, perform the simulation by typing one of the
following commands:
do <script>.do r (ModelSim Macro File)
quartus_sh -t <script>.tcl r (Tcl Script File)
sh <script>.sh r (Shell script)
9. If you have compiled libraries using the EDA Simulation Library Compiler, follow
these steps:
a. On the Simulation page, click More EDA Netlist Writer Settings. The More
EDA Netlist Writer Settings dialog box appears.
b. Under Existing option settings, click Location of user compiled simulation
library.
c. In the Setting field, type the path that contains the user-compiled libraries that
are generated from the EDA Simulation Library Compiler. The path should be
the same as the path you have set in the Output Directory in the EDA
Simulation Library Compiler.
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
1–14
Chapter 1: Simulating Designs with EDA Tools
Using the NativeLink Feature
1
Step 9 is not applicable for Active-HDL and Riviera-PRO.
For more information about the EDA Simulation Library Compiler, refer to “EDA
Simulation Library Compiler” on page 1–9.
For more information about using the Quartus II software with other EDA tools, refer
to About Using the Quartus II Software with Other EDA Tools in Quartus II Help.
Running RTL Functional Simulation Using the NativeLink Feature
To run RTL functional simulation using the NativeLink feature, follow these steps:
1. Configure the NativeLink settings. Refer to “Configuring NativeLink Settings” on
page 1–12.
2. On the Processing menu, point to Start and click Start Analysis & Elaboration to
perform an Analysis and Elaboration. This command collects all your file name
information and builds your design hierarchy in preparation for simulation.
3. On the Tools menu, point to Run EDA Simulation Tool and click EDA RTL
Simulation to automatically run the EDA simulator, compile all necessary design
files, and complete a simulation.
Running Gate-Level Timing Simulation Using the NativeLink Feature
To run a gate-level timing simulation using the NativeLink feature, follow these steps:
1. Configure the EDA Netlist Writer settings. Refer to “Generating Post-Synthesis
Simulation Netlist Files” on page 1–7.
2. Configure the NativeLink settings. Refer to “Configuring NativeLink Settings” on
page 1–12.
3. On the Processing menu, click Start Compilation to perform Quartus II full
compilation, including generation of an EDA netlist file.
4. On the Tools menu, point to Run EDA Simulation Tool and click EDA Gate Level
Simulation to automatically run the EDA simulator, compile all necessary design
files, and complete a simulation.
1
If you have turned on Run gate-level simulation automatically after
compilation while configuring NativeLink settings, you can skip step 4.
Setting Up Testbench Files Using the NativeLink Feature
You can use the NativeLink feature to compile your design files and testbench files,
and run an EDA simulation tool to automatically perform a simulation.
To set up the NativeLink feature for simulation, follow these steps:
1. On the Assignments menu, click Settings. The Settings dialog box appears.
2. In the Category list, under EDA Tool Settings, click Simulation. The Simulation
page appears.
3. In the Tool name list, select your preferred EDA simulator.
4. Under NativeLink settings, select None, Compile test bench, or Script to
compile test bench (Table 1–2).
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 1: Simulating Designs with EDA Tools
Using the NativeLink Feature
1–15
Table 1–2. NativeLink Testbench Settings
Setting
Description
None
NativeLink compiles simulation models and design files.
Compile test bench
NativeLink compiles simulation models, design files, testbench files, and
starts simulation.
Script to compile test
bench
NativeLink compiles the simulation models and design files. The script you
provide is sourced after design files are compiled. Use this option when
you want to create your own script to compile your testbench file and
perform simulation.
If you select Compile test bench, select your testbench setup from the Compile test
bench list. You can use different testbench setups to specify different test scenarios. If
there are no testbench setups entered, create a testbench setup by following these
steps:
1. Click Test Benches. The Test Benches dialog box appears.
2. Click New. The New Test Bench Settings dialog box appears.
3. In the Top level module in test bench box, type the top-level testbench entity or
module name. For example, for a Quartus II-generated VHDL testbench, type
<Vector Waveform File name>_vhd_vec_tst. The testbench name in the Test bench
name box automatically follows the top-level testbench entity or module name.
4. For gate-level simulation, turn on Use test bench to perform VHDL timing
simulation. In the Design instance name in test bench box, type the full instance
path to the top level of your FPGA design. For example, for a Quartus II-generated
VHDL testbench, type i1.
5. Under Simulation period, select Run simulation until all vector stimuli are used
or specify the end time of the simulation.
6. Under Test bench files, browse and add all of your testbench files in the File name
box. Use the Up and Down buttons to reorder your files. The script used by the
NativeLink feature compiles the files in order from top to bottom.
1
You can also specify the library name and HDL version to compile the testbench file.
The NativeLink feature compiles the testbench file to a library name using the
specified HDL version.
7. Click OK.
8. In the Test benches dialog box, click OK.
9. Under NativeLink settings, turn on Use script to set up simulation and browse to
your script. Your script is executed to set up and run simulation after loading the
design using the vsim command.
If you select Script to compile test bench, browse to your script and click OK.
1
© July 2010
Altera Corporation
You can also use the NativeLink feature in your script to compile your
design files and testbench files with customized settings.
Quartus II Handbook Version 10.0 Volume 3: Verification
1–16
Chapter 1: Simulating Designs with EDA Tools
Conclusion
Conclusion
The Quartus II NativeLink feature eases the tasks of setting up and running a
simulation, enables you to launch third-party simulators to perform simulation from
within the Quartus II software, and automates the compilation and simulation of
testbenches.
Document Revision History
Table 1–3 shows the revision history for this chapter.
Table 1–3. Document Revision History
Date
Version
July 2010
10.0.0
November 2009
9.1.0
Changes Made
■
Linked to Quartus II Help where appropriate
■
Removed Referenced Documents section
■
Removed Creating Testbench Files
■
Added VCS and QuestaSim as third-party simulation tools
■
Updated “Running the EDA Simulation Library Compiler Through the GUI” on
page 1–10
■
Updated “Setting Up the EDA Simulator Execution Path” on page 1–11
■
Updated “Configuring NativeLink Settings” on page 1–12
■
Updated “Setting Up Testbench Files Using the NativeLink Feature” on page 1–14
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.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
2. Mentor Graphics ModelSim/
QuestaSim Support
QII53001-10.0.0
This chapter provides detailed instructions about how to simulate your design in the
ModelSim-Altera® software, Mentor Graphics® ModelSim software, and Mentor
Graphics QuestaSim software.
An Altera Quartus® II software subscription includes the ModelSim-Altera Starter
Edition, which is a a no-cost entry-level version of the ModelSim-Altera Subscription
Edition software. The ModelSim-Altera Subscription Edition software offers support
for all Altera devices. Both versions are available on PC and Linux platforms. You can
use the ModelSim-Altera software to perform functional, post-synthesis, and
gate-level timing simulations for either Verilog HDL or VHDL designs that target an
Altera FPGA.
1
In this chapter, ModelSim refers to ModelSim SE, PE, DE, and QuestaSim.
ModelSim-Altera refers to ModelSim-Altera Starter Edition and ModelSim-Altera
Subscription Edition software.
This chapter includes the following topics:
■
“Software Requirements”
■
“Design Flow with ModelSim-Altera or ModelSim/QuestaSim Software”
■
“Simulation Libraries” on page 2–2
■
“Performing Simulation Using the ModelSim-Altera Software” on page 2–3
■
“Performing Simulation Using the ModelSim/QuestaSim Software” on page 2–5
■
“Simulating Designs that Include Transceivers” on page 2–16
■
“Using the NativeLink Feature with ModelSim-Altera or ModelSim/QuestaSim
Software” on page 2–24
■
“Generating a Timing Value Change Dump (.vcd) File for the PowerPlay Power
Analyzer” on page 2–25
■
“Viewing a Waveform from a .wlf File” on page 2–26
■
“Scripting Support” on page 2–26
■
“Software Licensing and Licensing Setup in ModelSim-Altera Subscription
Edition” on page 2–28
Software Requirements
To simulate your design using the ModelSim-Altera and ModelSim/QuestaSim
software, you must first set up the Altera libraries. These libraries are installed with
the Quartus II software.
f
© July 2010
For more information about installing the software and directories created during the
Quartus II software installation, refer to the Altera Software Installation and Licensing
manual.
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
2–2
Chapter 2: Mentor Graphics ModelSim/ QuestaSim Support
Design Flow with ModelSim-Altera or ModelSim/QuestaSim Software
Design Flow with ModelSim-Altera or ModelSim/QuestaSim Software
You can perform the following types of simulations using the ModelSim-Altera and
ModelSim/QuestaSim software:
■
Functional simulation
■
Post-synthesis simulation
■
Gate-level timing simulation
1
Some versions of ModelSim and QuestaSim support SystemVerilog, PSL assertions,
SystemC, and more. Refer to Mentor Graphics literature or your salesperson to learn
more about the features supported in the different versions of ModelSim and
QuestaSim.
1
The VHDL version of ModelSim-Altera and other single-language VHDL versions of
ModelSim cannot simulate designs that target the Stratix V device family if you are
using transceivers.
You need a version of ModelSim that supports VHDL/Verilog co-simulation to
simulate designs that use Stratix V transceivers.
f
For more information about the Quartus II software design flow, refer to the “PLD
Design Flow” section in the Simulating Designs with EDA Tools chapter in volume 3 of
the Quartus II Handbook.
f
For additional documentation about ModelSim-Altera, refer to the ModelSim-Altera
Help that ships with the product. Click the Help button on the ModelSim-Altera
toolbar.
Simulation Libraries
Simulation model libraries are required to run a simulation whether you are running
a functional simulation, post-synthesis simulation, or gate-level timing simulation. In
general, running a functional simulation requires the functional simulation model
libraries, while running a post-synthesis or gate-level timing simulation requires the
gate-level timing simulation model libraries. Unless you are using ModelSim-Altera,
you must compile the necessary library files before you can run the simulation. The
ModelSim-Altera software has the Altera libraries pre-compiled and built in. Do not
compile these libraries again.
There are a few exceptions where you must compile gate-level timing simulation
library files to perform functional simulation. For example, some Altera
megafunctions require gate-level libraries to perform a functional simulation using
third-party simulators.
Precompiled Simulation Libraries in the ModelSim-Altera Software
Precompiled libraries for both functional and gate-level simulations are provided for
the ModelSim-Altera software. You should not compile these library files before
running a simulation.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 2: Mentor Graphics ModelSim/ QuestaSim Support
Performing Simulation Using the ModelSim-Altera Software
2–3
The precompiled libraries provided in <ModelSim Altera path>/altera> must be
compatible with the version of the Quartus II software that is used to create the
simulation netlist. To check whether the precompiled libraries are compatible with
your version of the Quartus II software, refer to the <ModelSim Altera
path>/altera/version.txt file. This file shows which version and build of the Quartus II
software was used to create the precompiled libraries.
f
For a list of precompiled library names for all functional and gate-level simulation
models, refer to ModelSim Precompiled Libraries in Quartus II Help.
Simulation Library Files in the Quartus II Software
In ModelSim/QuestaSim, no precompiled libraries are available. You must compile
the necessary libraries to perform functional or gate-level simulation.
f
For a list of all functional simulation library files in the Quartus II directory, refer to
Altera Functional Simulation Libraries in Quartus II Help. For a list of all post-synthesis
and post-fit (gate-level) library files in the Quartus II directory, refer to Altera Post-Fit
Libraries in Quartus II Help.
Disabling Timing Violation on Registers
In certain situations, a timing violation can be ignored and you can disable timing
violations on registers (for example, timing violations that occur in internal
synchronization registers used for asynchronous clock domain crossing).
By default, the x_on_violation_option logic option is On, which means simulation
shows “x” whenever a timing violation occurs. To disable showing the timing
violation on certain registers, set the x_on_violation_option logic option to Off on
those registers. The following Quartus II Tcl command disables timing violation on
registers. This Tcl command is also stored in the .qsf file.
set_instance_assignment -name X_ON_VIOLATION_OPTION OFF –to <register_name>
Performing Simulation Using the ModelSim-Altera Software
You can perform simulation of Verilog HDL or VHDL designs with the
ModelSim-Altera software at three levels: functional, post-synthesis, and gate-level.
For high-speed simulation, you must select ps in the Resolution list for your
simulator resolutions (Design tab of the Start Simulation dialog box). If you choose
slower than ps, the high-speed simulation may fail.
Performing Functional Simulation
Functional simulation verifies code syntax and design functionality. The following
sections describe how to perform functional simulation in the ModelSim-Altera
software for a Verilog HDL or VHDL design.
1
© July 2010
The ModelSim-Altera software includes precompiled simulation libraries for
Altera-provided models. You should not create simulation libraries and compile
simulation models for the pre-compiled Altera libraries.
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
2–4
Chapter 2: Mentor Graphics ModelSim/ QuestaSim Support
Performing Simulation Using the ModelSim-Altera Software
Setting Up a Quartus II Project for the ModelSim-Altera Software
The first steps in performing a simulation are starting the ModelSim-Altera software,
changing to your project/simulation directory, and creating libraries for your design.
f
For more information, refer to Setting Up a Project with the ModelSim-Altera Software in
Quartus II Help.
Compiling and Loading Designs with the ModelSim-Altera Software
f
For information about compiling and loading your design files and testbench files,
refer to Mapping to Libraries and Compiling Design Files with the ModelSim-Altera
Software in Quartus II Help.
Performing the Simulation
f
For information about performing a functional simulation with the ModelSim-Altera
software, refer to Performing a Functional Simulation with the ModelSim-Altera Software
in Quartus II Help.
Performing Post-Synthesis Simulation
You can perform post-synthesis simulation to verify that design functionality is
preserved after synthesis. You can create the post-synthesis netlist in the Quartus II
software and use the netlist to perform post-synthesis simulation with the
ModelSim-Altera software.
f
Before running post-synthesis simulation, generate post-synthesis simulation netlist
files. For more information, refer to the “Generating Post-Synthesis Simulation Netlist
Files” section in the Simulating Designs with EDA Tools chapter in volume 3 of the
Quartus II Handbook.
1
The ModelSim-Altera software includes precompiled simulation libraries. You should
not create simulation libraries and compile simulation models.
f
For information about performing a post-synthesis simulation with the
ModelSim-Altera software, refer to Performing a Timing Simulation with the
ModelSim-Altera Software in Quartus II Help.
Performing Gate-Level Timing Simulation
Gate-level timing simulation is an important step in ensuring that the device
functionality is correct and meets all timing requirements following place and route.
You can create the gate-level netlist in the Quartus II software and use the netlist to
perform gate-level timing simulation with the ModelSim-Altera software.
f
Before running gate-level timing simulation, generate gate-level timing simulation
netlist files. For more information, refer to the “Generating Gate-Level Timing
Simulation Netlist Files” section in the Simulating Designs with EDA Tools chapter in
volume 3 of the Quartus II Handbook.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 2: Mentor Graphics ModelSim/ QuestaSim Support
Performing Simulation Using the ModelSim/QuestaSim Software
1
2–5
The ModelSim-Altera software includes precompiled simulation libraries. It is not
necessary to create simulation libraries and compile simulation models.
f
For information about performing a gate-level simulation with the ModelSim-Altera
software, refer to Performing a Timing Simulation with the ModelSim-Altera Software in
Quartus II Help.
f
For additional documentation about ModelSim-Altera, refer to the ModelSim-Altera
Help that ships with the product. Click the Help button on the ModelSim-Altera
toolbar.
Performing Simulation Using the ModelSim/QuestaSim Software
You can perform simulation of Verilog HDL or VHDL designs with the
ModelSim/QuestaSim software at three levels: functional, post-synthesis, and
gate-level.
You can perform the simulation through the GUI or from the command line. The
following sections provide instructions to perform the simulation through the GUI
and from the command line. You can proceed to the specific section that meets your
needs.
For high-speed simulation, you must select ps in the Resolution list for your
simulator resolutions (Design tab of the Start Simulation dialog box). If you choose
slower than ps, the high-speed simulation may fail.
Simulating VHDL Designs Using the GUI
This section provides information about performing functional, post-synthesis, and
gate-level simulations of VHDL designs using the GUI.
Performing Functional Simulation
This section provides information about compiling simulation models and
performing a functional simulation.
Compiling Simulation Models into Simulation Libraries
If you are not using the EDA Simulation Library Compiler, as described in the
Simulating Designs with EDA Tools chapter in volume 3 of the Quartus II Handbook,
perform the following steps to compile simulation models into simulation libraries:
1. On the Compile menu, click Compile. The Compile Source Files dialog box
appears.
2. Select the library that you created (for example, altera_mf, lpm).
3. Browse to the <Quartus II installation directory>/eda/sim_lib and add the necessary
simulation model files to your project. Select the simulation model files and click
Compile.
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
2–6
Chapter 2: Mentor Graphics ModelSim/ QuestaSim Support
Performing Simulation Using the ModelSim/QuestaSim Software
If you are targeting a Stratix V device, compile the following files in the mentor
subdirectory:
stratixv_atoms_ncrypt.v
stratixv_hssi_atoms_ncrypt.v
stratixv_pcie_hip_atoms_ncrypt.v
These files contain IEEE encrypted Verilog models suitable for VHDL/Verilog
co-simulation. You need a co-simulation license from Mentor Graphics to use
these models.
1
Compile these encrypted Verilog files before you compile any VHDL files.
1
Compile stratixv_pcie_hip_atoms_ncrypt.v with the SystemVerilog option.
Also, compile the following files in the quartus/eda/sim_lib directory:
stratixv_atoms.vhd
stratixv_components.vhd
stratixv_hssi_components.vhd
stratixv_pcie_hip_components.vhd
stratixv_hssi_atoms.vhd
stratixv_pcie_hip_atoms.vhd
1
The PCIe® files are required only if you are using the PCIe HIP.
1
The altera_mf_components.vhd and altera_mf.vhd model files should be compiled
into the altera_mf library. The 220pack.vhd and 220model.vhd model files should be
compiled into the lpm library.
4. Repeat step 2 and step 3 to compile other simulation models.
5. Click Done.
Performing the Simulation
f
For information about simulating VHDL designs using the GUI, refer to Performing a
Functional Simulation with the ModelSim Software and Performing a Functional Simulation
with the QuestaSim Software in Quartus II Help.
f
To see all of the functional simulation library files, refer to Altera Functional Simulation
Libraries in Quartus II Help.
Performing Post-Synthesis Simulation
You can perform post-synthesis simulation to verify that design functionality is
preserved after synthesis. You can create the post-synthesis netlist in the Quartus II
software and use the netlist to perform post-synthesis simulation with the
ModelSim/QuestaSim software.
f
Before running post-synthesis simulation, generate post-synthesis simulation netlist
files. For more information, refer to the “Generating Post-Synthesis Simulation Netlist
Files” section in the Simulating Designs with EDA Tools chapter in volume 3 of the
Quartus II Handbook.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 2: Mentor Graphics ModelSim/ QuestaSim Support
Performing Simulation Using the ModelSim/QuestaSim Software
1
f
2–7
You cannot perform post-synthesis or post-fit (gate-level) simulation if you are
targeting the Stratix V device family.
For information about performing a post-synthesis simulation using the GUI, refer to
Performing a Timing Simulation with the ModelSim Software and Performing a Timing
Simulation with the QuestaSim Software in Quartus II Help.
Performing Gate-Level Simulation
Gate-level simulation is a very important step in ensuring that the FPGA device’s
functionality is still correct and meets all required timing requirements after the
design was placed and routed. You can create the gate-level netlist in the Quartus II
software and use the netlist to perform gate-level simulation with the
ModelSim/QuestaSim software.
1
You cannot perform post-synthesis or post-fit (gate-level) simulation if you are
targeting the Stratix V device family.
f
Before running gate-level simulation, generate gate-level timing simulation netlist
files. For more information, refer to the “Generating Gate-Level Timing Simulation
Netlist Files” section in the Simulating Designs with EDA Tools chapter in volume 3 of
the Quartus II Handbook.
f
For information about performing a gate-level simulation using the GUI, refer to
Performing a Timing Simulation with the ModelSim Software and Performing a Timing
Simulation with the QuestaSim Software in Quartus II Help.
Simulating Verilog HDL Designs Using the GUI
This section provides information about performing functional, post-synthesis, and
gate-level simulations of Verilog HDL designs using the GUI.
Performing Functional Simulation
This section provides information about compiling simulation models and
performing a functional simulation.
Compiling Simulation Models into Simulation Libraries
If you are not using the EDA Simulation Library Compiler, as described in the section
“EDA Simulation Library Compiler” in the Simulating Designs with EDA Tools chapter
in volume 3 of the Quartus II Handbook, perform the following steps to compile
simulation models into simulation libraries:
1. On the Compile menu, click Compile. The Compile Source Files dialog box
appears.
2. Select the library that you created (for example, altera_mf_ver or lpm_ver).
3. Browse to the <Quartus II installation directory>/eda/sim_lib and add the necessary
simulation model files to your project. Select the simulation model files and click
Compile.
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
2–8
Chapter 2: Mentor Graphics ModelSim/ QuestaSim Support
Performing Simulation Using the ModelSim/QuestaSim Software
If you are targeting a Stratix V device, compile the following files in the mentor
subdirectory:
stratixv_atoms_ncrypt.v
stratixv_hssi_atoms_ncrypt.v
stratixv_pcie_hip_atoms_ncrypt.v
These files contain IEEE encrypted Verilog models.
1
Compile stratixv_pcie_hip_atoms_ncrypt.v with the SystemVerilog option.
Also, compile the following files in the quartus/eda/sim_lib directory:
stratixv_atoms.v
stratixv_hssi_atoms.v
stratixv_pcie_hip_atoms.v
1
The PCIe file is required only if you are using the PCIe HIP.
1
The altera_mf.v model files should be compiled into the altera_mf_ver
library. The 220model.v model files should be compiled into the lpm_ver
library.
4. Repeat step 2 and step 3 to compile other simulation models.
5. Click Done.
Performing the Simulation
f
For information about performing a functional simulation using the GUI, refer to
Performing a Functional Simulation with the ModelSim Software and Performing a
Functional Simulation with the QuestaSim Software in Quartus II Help.
f
To see all of the functional simulation library files, refer to Altera Functional Simulation
Libraries in Quartus II Help.
Performing Post-Synthesis Simulation
Perform post-synthesis simulation to verify that design functionality is preserved
after synthesis. Create the post-synthesis netlist in the Quartus II software and use the
netlist to perform post-synthesis simulation with the ModelSim/QuestaSim software.
f
1
f
Before running post-synthesis simulation, generate post-synthesis simulation netlist
files. For more information, refer to the “Generating Post-Synthesis Simulation Netlist
Files” section in the Simulating Designs with EDA Tools chapter in volume 3 of the
Quartus II Handbook.
You cannot perform post-synthesis or post-fit (gate-level) simulation if you are
targeting the Stratix V device family.
For information about performing a post-synthesis simulation using the GUI, refer to
Performing a Timing Simulation with the ModelSim Software and Performing a Timing
Simulation with the QuestaSim Software in Quartus II Help.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 2: Mentor Graphics ModelSim/ QuestaSim Support
Performing Simulation Using the ModelSim/QuestaSim Software
2–9
Performing Gate-Level Simulation
Gate-level simulation is a very important step in ensuring that the FPGA device’s
functionality is still correct and meets all required timing requirements after the
design was placed and routed. You can create the gate-level netlist in the Quartus II
software and use the netlist to perform gate-level simulation with the
ModelSim/QuestaSim software.
1
You cannot perform post-synthesis or post-fit (gate-level) simulation if you are
targeting the Stratix V device family.
f
Before running gate-level simulation, generate gate-level timing simulation netlist
files. For more information, refer to the “Generating Gate-Level Timing Simulation
Netlist Files” section in the Simulating Designs with EDA Tools chapter in volume 3 of
the Quartus II Handbook.
f
For information about performing a gate-level simulation using the GUI, refer to
Performing a Timing Simulation with the ModelSim Software and Performing a Timing
Simulation with the QuestaSim Software in Quartus II Help.
Simulating VHDL Designs From the Command Line
This section provides information about performing functional, post-synthesis, and
gate-level simulations of VHDL designs from the command line.
Simulating VHDL designs from the ModelSim/QuestaSim command line gives you
more flexibility and control in compiling the libraries and loading and simulating the
VHDL design files. All simulation commands are Tcl commands that can be included
in the *.do file. Using the *.do file allows you to run simulation in batch mode. You
have to execute only the *.do file, and the ModelSim/QuestaSim tool automatically
executes all commands in the *.do script macro file.
Performing Functional Simulation
Function simulation verifies code syntax and design functionality.
Type the following commands to perform a functional simulation for VHDL designs
with one of the libraries (lib1) listed in the Altera Functional Simulation Libraries in
Quartus II Help.
To create and compile Altera libraries, type the following commands:
vlib
vmap
vcom
vlib
vmap
vcom
<lib1> r
<lib1> <lib1> r
-work <lib1> <lib1>.vhd r
<lib2> r
<lib2> <lib2> r
-work <lib2> <lib2>.vhd r
To create the work library and compile the design and testbench files, type the
following commands:
vlib work r
vmap work work r
vcom -work work <design_file1>.vhd <design file2>.vhd <testbench \
file>.vhd r
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
2–10
Chapter 2: Mentor Graphics ModelSim/ QuestaSim Support
Performing Simulation Using the ModelSim/QuestaSim Software
To load the design, type the following command:
vsim -L work -L <lib1> -L <lib2> work.<testbench module name> r
To add signals to the waveform viewer and run the simulation, type the following
commands:
add wave * r
run r
Example
# Create and compile Altera libraries
vlib
vmap
vcom
vlib
vmap
vcom
altera_mf
altera_mf altera_mf
-work altera_mf altera_mf_components.vhd altera_mf.vhd
lpm
lpm lpm
-work lpm 220pack.vhd 220model.vhd
# Create work library and compile design files and testbench file
vlib work
vmap work work
vcom -work work top_level.vhd adder.vhd testbench.vhd
# Load design
vsim -L work -L altera_mf -L lpm work.testbench
# add signals to the waveform viewer and run simulation
add wave *
run
If you are targeting a Stratix V device, compile the following files in the
quartus/eda/sim_lib/mentor directory:
stratixv_atoms_ncrypt.v
stratixv_hssi_atoms_ncrypt.v
stratixv_pcie_hip_atoms_ncrypt.v
These files contain IEEE encrypted Verilog models suitable for VHDL/Verilog
co-simulation. You need a co-simulation license from Mentor Graphics to use these
models.
Compile these encrypted Verilog files before you compile any VHDL files.
Compile stratixv_pcie_hip_atoms_ncrypt.v with the SystemVerilog option.
Also, compile the following files in the quartus/eda/sim_lib directory:
stratixv_atoms.vhd
stratixv_components.vhd
stratixv_hssi_components.vhd
stratixv_pcie_hip_components.vhd
stratixv_hssi_atoms.vhd
stratixv_pcie_hip_atoms.vhd
The PCIe® files are required only if you are using the PCIe HIP.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 2: Mentor Graphics ModelSim/ QuestaSim Support
Performing Simulation Using the ModelSim/QuestaSim Software
2–11
Performing Post-Synthesis Simulation
Perform post-synthesis simulation to verify that design functionality is preserved after
synthesis. Create the post-synthesis netlist in the Quartus II software and use the netlist
to perform post-synthesis simulation with the ModelSim/QuestaSim software. Before
running post-synthesis simulation, generate post-synthesis simulation netlist files.
f
For more information, refer to the “Generating Post-Synthesis Simulation Netlist Files”
section in the Simulating Designs with EDA Tools chapter in volume 3 of the Quartus II
Handbook.
f
You cannot perform post-synthesis or post-fit (gate-level) simulation if you are targeting
the Stratix V device family.
Type the following commands to perform a post-synthesis simulation for VHDL designs
with one of the libraries (lib1) listed in Altera Post-Fit Libraries in Quartus II Help.
To create and compile Altera libraries, type the following commands:
vlib
vmap
vcom
vlib
vmap
vcom
<lib1> r
<lib1> <lib1> r
-work <lib1> <lib1>.vhd r
<lib2> r
<lib2> <lib2>r
-work <lib2> <lib2>.vhd r
To create the work library and compile design and testbench files, type the following
commands:
vlib work r
vmap work work r
vcom -work work <output_netlist>.vho <testbench file>.vhd r
To load the design, type the following command:
vsim +transport_int_delays +transport_path_delays
<lib2> work.<testbench module name> r
-L work -L \ <lib1> -L
To add signals to the waveform viewer and run simulation, type the following
commands:
add wave * r
run r
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
2–12
Chapter 2: Mentor Graphics ModelSim/ QuestaSim Support
Performing Simulation Using the ModelSim/QuestaSim Software
Example
# Create and compile Altera libraries
vlib altera
vmap altera altera
vcom -work altera altera_primitives_components.vhd \
altera_primitives.vhd
vlib stratixiii
vmap stratixiii stratixiii
vcom -work stratixiii stratixiii.atoms.vhd stratixiii_components.vhd
# Create work library and compile design files and testbench file
vlib work
vmap work work
vcom -work work top_level.vho testbench.vhd
# Load design
vsim +transport_int_delays +transport_path_delays
-L stratixiii work.testbench
-L work -L \ altera
# add signals to the waveform viewer and run simulation
add wave *
run
Performing Gate-Level Simulation
The steps for gate-level timing simulation are almost same as the steps for
post-synthesis simulation.
The only difference is that the .sdo file must be back-annotated for gate level-timing
simulation.
For VHDL designs, add the -sdftyp option for back-annotating.
Example
vsim +transport_int_delays +transport_path_delays -sdftyp \ <instance
path to design>= <path to SDO file> -L work -L stratixiii -L \ altera
work.testbench
You do not have to set the value (minimum, average, maximum) for the *.sdo file,
because the Quartus II EDA Netlist Writer generates the *.sdo file using the same
value for the triplet (minimum, average, and maximum timing values).
If your design under test is instantiated in the testbench file under the i1 label, the
<design instance> should be "i1" (for example, /i1=<my design>.sdo).
1
You cannot perform post-synthesis or post-fit (gate-level) simulation if you are
targeting the Stratix V device family.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 2: Mentor Graphics ModelSim/ QuestaSim Support
Performing Simulation Using the ModelSim/QuestaSim Software
2–13
Simulating Verilog HDL Designs from the Command Line
This section provides information about performing functional, post-synthesis, and
gate-level simulations of Verilog HDL designs from the command line.
Simulating Verilog HDL designs from the ModelSim/QuestaSim command line gives
you more flexibility and control in compiling the libraries and loading and simulating
the Verilog HDL design files. All simulation commands are Tcl commands that can be
included in the *.do file. Using the *.do file allows you to run simulation in batch mode.
You have to execute only the *.do file, and the ModelSim/QuestaSim tool
automatically executes all commands in the *.do script macro file.
Performing Functional Simulation
Functional simulation verifies code syntax and design functionality.
Type the following commands to perform a functional simulation for Verilog HDL
designs with one of the libraries (lib1) listed in Altera Functional Simulation Libraries in
Quartus II Help.
To create and compile Altera libraries, type the following commands:
vlib
vmap
vlog
vlib
vmap
vlog
<lib1> r
<lib1> <lib1> r
-work <lib1> <lib1>.v r
<lib2> r
<lib2> <lib2> r
-work <lib2> <lib2>.v r
To create the work library and compile design and testbench files, type the following
commands:
vlib work r
vmap work work r
vlog -work work <design_file1>.v <design file2>.v <testbench file>.v r
To load the design, type the following command:
vsim -L work -L <lib1> -L <lib2> work.<testbench module name> r
To add signals to the waveform viewer and run simulation, type the following
commands:
add wave * r
run r
Example
# Create and compile Altera libraries
vlib
vmap
vlog
vlib
vmap
vlog
altera_mf_ver
altera_mf_ver altera_mf_ver
-work altera_mf_ver altera_mf.v
lpm_ver
lpm_ver lpm_ver
-work lpm_ver 220model.v
# Create work library and compile design files and testbench file
vlib work
vmap work work
vlog -work work top_level.v adder.v testbench.v
# Load design
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
2–14
Chapter 2: Mentor Graphics ModelSim/ QuestaSim Support
Performing Simulation Using the ModelSim/QuestaSim Software
vsim -L work -L altera_mf_ver -L lpm_ver work.testbench
# add signals to the waveform viewer and run simulation
add wave *
run
If you are targeting a Stratix V device, compile the following files in the
quartus/eda/sim_lib/mentor directory:
stratixv_atoms_ncrypt.v
stratixv_hssi_atoms_ncrypt.v
stratixv_pcie_hip_atoms_ncrypt.v
These files contain IEEE encrypted Verilog models.
1
Compile stratixv_pcie_hip_atoms_ncrypt.v with the SystemVerilog option.
Also, compile the following files in the quartus/eda/sim_lib directory:
stratixv_atoms.v
stratixv_hssi_atoms.v
stratixv_pcie_hip_atoms.v
1
The PCIe file is required only if you are using the PCIe HIP.
Performing Post-Synthesis Simulation
Perform post-synthesis simulation to verify that design functionality is preserved after
synthesis. Create the post-synthesis netlist in the Quartus II software and use the netlist
to perform post-synthesis simulation with the ModelSim/QuestaSim software. Before
running post-synthesis simulation, generate post-synthesis simulation netlist files.
f
1
For more information, refer to the “Generating Post-Synthesis Simulation Netlist Files”
section in the Simulating Designs with EDA Tools chapter in volume 3 of the Quartus II
Handbook.
You cannot perform post-synthesis or post-fit (gate-level) simulation if you are targeting
the Stratix V device family.
Type the following commands to perform a post-synthesis simulation for Verilog HDL
designs with one of the libraries (lib1) listed in Altera Post-Fit Libraries in Quartus II Help.
To create and compile Altera libraries, type the following commands:
vlib
vmap
vlog
vlib
vmap
vlog
<lib1> r
<lib1> <lib1> r
-work <lib1> <lib1>.v r
<lib2> r
<lib2> <lib2> r
-work <lib2> <lib2>.v r
To create the work library and compile design and testbench files, type the following
commands:
vlib work r
vmap work work r
vlog -work work <output_netlist>.vo <testbench file>.v r
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 2: Mentor Graphics ModelSim/ QuestaSim Support
Performing Simulation Using the ModelSim/QuestaSim Software
2–15
To load the design, type the following command:
vsim -t ps +transport_int_delays +transport_path_delays
<lib1> -L <lib2> work.<testbench module name> r
-L work -L \
To add signals to the waveform viewer and run the simulation, type the following
commands:
add wave * r
run r
Example
# Create and compile Altera libraries
vlib
vmap
vlog
vlib
altera_ver
altera_ver altera_ver
-work altera_ver altera_primitives.v
stratixiii_ver
vmap stratixiii_ver stratixiii_ver
vlog -work stratixiii_ver stratixiii_atoms.v
# Create work library and compile design files and testbench file
vlib work
vmap work work
vlog -work work top_level.vo testbench.v
# Load design
vsim +transport_int_delays +transport_path_delays
altera_ver -L stratixiii_ver work.testbench
-L work -L
#add signals to the waveform viwer and run simulation
add wave *
run
Performing Gate-Level Simulation
The steps for gate-level timing simulation are almost same as the steps for
post-synthesis simulation.
The only difference is that the .sdo file must be back-annotated for gate level-timing
simulation.
For Verilog HDL designs, the back-annotating process is done within the
output_netlist.vo script. Therefore, you are not required to back-annotate the SDO file
again.
1
You cannot perform post-synthesis or post-fit (gate-level) simulation if you are
targeting the Stratix V device family.
Passing Parameter Information from Verilog to VHDL
You must use in-line parameters to pass values from Verilog HDL to VHDL. Using the
defparam construct will cause an error in simulation. In the example below:
lpm_add_sub_component (
.dataa (dataa),
.datab (datab),
.result (sub_wire0)
);
defparam
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
2–16
Chapter 2: Mentor Graphics ModelSim/ QuestaSim Support
Simulating Designs that Include Transceivers
lpm_add_sub_component.lpm_direction = "ADD",
lpm_add_sub_component.lpm_hint =
"ONE_INPUT_IS_CONSTANT=NO,CIN_USED=NO",
lpm_add_sub_component.lpm_type = "LPM_ADD_SUB",
lpm_add_sub_component.lpm_width = 12;
You will see the following error message:
# ** Error: (vsim-3043)
/apps2/home/users/bhlee/SPR_ADOQS/ADOQS10000935_IN_LINE_PARAMETER/lpm_
add_sub1.v(67): Unresolved reference to 'lpm_add_sub_component' in
lpm_add_sub_component.lpm_direction.
# Region: /IN_LINE_PARAMETER_vlg_vec_tst/i1/b2v_inst
This megafunction instantiation has been modified to use in-line parameters:
lpm_add_sub#(12,"SIGNED","ADD",0,"LPM_ADD_SUB","ONE_INPUT_IS_CONSTANT=
NO,CIN_USED=NO")
lpm_add_sub_component (
.dataa (dataa),
.datab (datab),
.result (sub_wire0)
);
1
The sequence of the parameters depends on the sequence of the GENERIC in the
VHDL component declaration.
Speeding Up Simulation
By default, the ModelSim/QuestaSim software runs in a debug-optimized mode. To
run the ModelSim/QuestaSim software in speed-optimized mode, add the following
two vlog command line switches:
vlog -fast -05
In this mode, module boundaries are flattened and loops are optimized. This
eliminates levels of debugging hierarchy, which may result in faster simulation. This
switch is not supported in the ModelSim-Altera simulator.
Simulating Designs that Include Transceivers
If your design includes an Arria GX, Arria II GX, Cyclone IV, HardCopy IV,
Stratix GX, Stratix II GX, Stratix IV, or Stratix V transceiver, you must compile
additional library files to perform functional or gate-level timing simulations.
1
f
You cannot perform post-synthesis or post-fit (gate-level) simulation if you are
targeting the Stratix V device family.
For Stratix V, you must compile the libraries listed in Compiling Stratix V Libraries in
Quartus II Help.
Performing simulation with transceivers in Arria II, Cyclone IV, HardCopy IV, and
Stratix IV device families are very similar. You have to replace only stratixiigx_atoms
and stratixiigx_hssi_atoms model files with arriaii_atoms and arriaii_hssi_atoms
model files for Arria II devices, cycloneiv_atoms and cycloneiv_hssi_atoms model
files for Cyclone IV devices, and stratixiv_atoms and stratixiv_hssi_atoms model files
for Stratix IV devices.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 2: Mentor Graphics ModelSim/ QuestaSim Support
Simulating Designs that Include Transceivers
2–17
For high-speed simulation, you must select ps in the Resolution list for your simulator
resolutions (Design tab of the Start Simulation dialog box). If you choose slower than
ps, the high-speed simulation may fail.
f
1
If your design contains PCI Express® hard IP, refer to the “Simulate the Design” section
in the PCI Express Compiler User Guide.
The VHDL version of ModelSim-Altera and other single language VHDL versions of
ModelSim cannot simulate designs that target the Stratix V device family.
You need a version of ModelSim that supports VHDL/Verilog co-simulation to
simulate designs that use Stratix V transceivers.
Functional Simulation for Stratix GX Devices
To perform a functional simulation of your design that instantiates the ALTGXB
megafunction, which enables the gigabit transceiver block on Stratix GX devices,
compile the stratixgx_mf model file into the altgxb library.
1
The stratixgx_mf model file references the lpm and sgate libraries. If you are using
ModelSim/QuestaSim, you must create these libraries to perform a simulation.
Performing Functional Simulation in VHDL (ModelSim-Altera)
To perform functional simulation for Stratix GX devices in VHDL, type the following
commands:
vcom -work <my_design>.vhd <my testbench>.vhd r
vsim -L lpm -L altera_mf -L sgate -L altgxb work.<my_testbench> r
Performing Functional Simulation in VHDL (ModelSim/QuestaSim)
To perform functional simulation for Stratix GX devices in VHDL, type the following
commands:
vcom
vcom
vcom
vcom
vcom
vsim
-work altera_mf altera_mf_components.vhd altera_mf.vhd r
-work lpm 220pack.vhd 220model.vhd r
-work sgate sgate_pack.vhd sgate.vhd r
-work altgxb stratixgx_mf.vhd stratixgx_mf_components.vhd r
-work <my_design>.vhd <my_testbench>.vhd r
-L lpm -L altera_mf -L sgate -L altgxb work.<my testbench> r
Performing Functional Simulation in Verilog HDL (ModelSim-Altera)
To perform functional simulation for Stratix GX devices in Verilog HDL, type the
following commands:
vlog -work <my design>.v <my testbench>.v r
vsim -L lpm_ver -L altera_mf_ver -L sgate_ver -L altgxb work.<my testbench> r
Performing Functional Simulation in Verilog HDL (ModelSim/QuestaSim)
To perform functional simulation for Stratix GX devices in Verilog HDL, type the
following commands:
vlib
vlib
vlib
vlib
vlib
© July 2010
Altera Corporation
work_ver r
lpm_ver r
altera_mf_ver r
sgate_ver r
altgxb_ver r
Quartus II Handbook Version 10.0 Volume 3: Verification
2–18
Chapter 2: Mentor Graphics ModelSim/ QuestaSim Support
Simulating Designs that Include Transceivers
vlog
vlog
vlog
vlog
vlog
vsim
-work lpm_ver 220model.v r
-work altera_mf_ver altera_mf.v r
-work sgate_ver sgate.v r
-work altgxb_ver stratixgx_mf.v r
-work <my design>.v <my testbench>.v r
-L lpm_ver -L sgate_ver-L altgxb_ver work.<my testbench> r
Gate-Level Timing Simulation for Stratix GX Devices
Perform a gate-level timing simulation of your design that includes a Stratix GX
transceiver by compiling the stratixgx_atoms and stratixgx_hssi_atoms model files into
the stratixgx and stratixgx_gxb libraries, respectively.
1
The stratixgx_hssi_atoms model file references the lpm and sgate libraries. If you are
using ModelSim/QuestaSim, you must create these libraries to perform a simulation.
Performing Gate-Level Timing Simulation in VHDL (ModelSim-Altera)
To perform gate-level timing simulation for Stratix GX devices in VHDL, type the
following commands:
vcom -work <my design>.vho <my testbench>.vhd r
vsim -L lpm -L altera_mf -L sgate -L stratixgx -L stratixgx_gxb \
-sdftyp <design instance>=<path to .sdo file>.sdo work.<my testbench> \
-t ps - +transport_int_delays+transport_path_delaysr
Performing Gate-Level Timing Simulation in VHDL (ModelSim/QuestaSim)
To perform gate-level timing simulation for Stratix GX devices in VHDL, type the
following commands:
vcom -work lpm 220pack.vhd 220model.vhd r
vcom -work altera_mf altera_mf_components.vhd altera_mf.vhd r
vcom -work sgate sgate_pack.vhd sgate.vhd r
vcom -work stratixgx stratixgx_atoms.vhd stratixgx_components.vhd r
vcom -work stratixgx_gxb stratixgx_hssi_atoms.vhd \
stratixgx_hssi_components.vhd r
vcom -work <my design>.vho <my testbench>.vhd r
vsim -L lpm -L altera_mf -L sgate -L stratixgx -L stratixgx_gxb \
-sdftyp <design instance>=<path to .sdo file>.sdo work.<my testbench> \
-t ps +transport_int_delays +transport_path_delays r
Performing Gate-Level Timing Simulation in Verilog HDL (ModelSim-Altera)
To perform gate-level timing simulation for Stratix GX devices in Verilog HDL, type the
following commands:
vlog -work <my design>.vo <my testbench>.v r
vsim -L lpm_ver -L altera_mf_ver -L sgate_ver -L stratixgx_ver -L \
stratixgx_gxb_ver work.<my testbench> -t ps +transport_int_delays \
+transport_path_delays r
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 2: Mentor Graphics ModelSim/ QuestaSim Support
Simulating Designs that Include Transceivers
2–19
Performing Gate-Level Timing Simulation in Verilog HDL (ModelSim/QuestaSim)
To perform gate-level timing simulation for Stratix GX devices in Verilog HDL, type the
following commands:
vlog -work lpm_ver 220model.v r
vlog -work altera_mf_ver altera_mf.v r
vlog -work sgate_ver sgate.v r
vlog -work stratixgx_ver stratixgx_atoms.v r
vlog -work stratixgx_gxb_ver stratixgx_hssi_atoms.v r
vlog -work <my design>.vo <my testbench>.v r
vsim -L lpm_ver -L altera_mf_ver -L sgate_ver -L stratixgx_ver \
-L stratixgx_gxb_ver work.<my testbench> -t ps +transport_int_delays \
+transport_path_delays r
Functional Simulation for Stratix II GX Devices
To perform functional simulation of your design that instantiates the ALT2GXB
megafunction, which enables the gigabit transceiver block on Stratix II GX devices,
compile the stratixiigx_hssi model file into the stratixiigx_hssi library.
1
The stratixiigx_hssi_atoms model file references the lpm and sgate libraries. If you are
using ModelSim/QuestaSim, you must create these libraries to perform a simulation.
Generate a functional simulation netlist by turning on Generate Simulation Model in the
Simulation Library tab of the ALT2GXB MegaWizard Plug-In Manager. The <alt2gxb
entity name>.vho or <alt2gxb module name>.vo is generated in the current project directory.
1
The ALT2GXB functional simulation library file generated by the Quartus II software
references stratixiigx_hssi WYSIWYG atoms.
Performing Functional Simulation in VHDL (ModelSim-Altera)
To perform functional simulation for Stratix II GX devices in VHDL, type the following
commands:
vcom -work work <alt2gxb entity name>.vho r
vcom -work <my design>.vhd <my testbench>.vhd r
vsim -L lpm -L altera_mf -L sgate -L stratixgx_hssi work.<my design> r
Performing Functional Simulation in VHDL (ModelSim/QuestaSim)
To perform functional simulation for Stratix II GX devices in VHDL, type the following
commands:
vcom -work lpm 220pack.vhd 220model.vhd r
vcom -work altera_mf altera_mf_components.vhd altera_mf.vhd r
vcom -work sgate sgate_pack.vhd sgate.vhd r
vcom -work stratixiigx_hssi stratixiigx_hssi_components.vhd \
stratixiigx_hssi_atoms.vhd r
vcom -work work <alt2gxb entity name>.vho r
vcom -work <my design>.vhd <my testbench>.vhd r
vsim -L lpm -L altera_mf -L sgate -L stratixgx_hssi work.<my testbench> r
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
2–20
Chapter 2: Mentor Graphics ModelSim/ QuestaSim Support
Simulating Designs that Include Transceivers
Performing Functional Simulation in Verilog HDL (ModelSim-Altera)
To perform functional simulation for Stratix II GX devices in Verilog HDL, type the
following commands:
vlog -work work <alt2gxb module name>.vo r
vlog -work <my design>.v <my testbench>.v r
vsim -L lpm_ver -L altera_mf_ver -L sgate_ver -L stratixgx_hssi_ver \
work.<my testbench> r
Performing Functional Simulation in Verilog HDL (ModelSim/QuestaSim)
To perform functional simulation for Stratix II GX devices in Verilog HDL, type the
following commands:
vlog -work lpm_ver 220model.v r
vlog -work altera_mf_ver altera_mf.v r
vlog -work sgate_ver sgate.v r
vlog -work stratixiigx_hssi_ver stratixiigx_hssi_atoms.v r
vlog -work work <alt2gxb module name>.vo r
vlog -work <my design>.v <my testbench>.v r
vsim -L lpm_ver -L altera_mf_ver -L sgate_ver -L stratixgx_hssi_ver \
work.<my testbench> r
Gate-Level Timing Simulation for Stratix II GX Devices
To perform a gate-level timing simulation of your design that includes a Stratix II GX
transceiver, compile stratixiigx_atoms and stratixiigx_hssi_atoms into the stratixiigx
and stratixiigx_hssi libraries, respectively.
1
The stratixiigx_hssi_atoms model file references the lpm and sgate libraries. If you
are using ModelSim/QuestaSim, you must create these libraries to perform a
simulation.
Performing Gate-Level Timing Simulation in VHDL (ModelSim-Altera)
To perform gate-level timing simulation for Stratix II GX devices in VHDL, type the
following commands:
vcom -work <my design>.vho <my testbench>.vhd r
vsim -L lpm -L altera_mf -L sgate -L stratixiigx -L stratixiigx_hssi \
-sdftyp <design instance>=<path to .sdo file>.sdo work.<my testbench> \
-t ps +transport_int_delays +transport_path_delays r
Performing Gate-Level Timing Simulation in VHDL (ModelSim/QuestaSim)
To perform gate-level timing simulation for Stratix II GX devices in VHDL, type the
following commands:
vcom -work lpm 220pack.vhd 220model.vhd r
vcom -work altera_mf altera_mf_components.vhd altera_mf.vhd r
vcom -work sgate sgate_pack.vhd sgate.vhd r
vcom -work stratixiigx stratixiigx_atoms.vhd \
stratixiigx_components.vhd r
vcom -work stratixiigx_hssi stratixiigx_hssi_components.vhd \
stratixiigx_hssi_atoms.vhd r
vcom -work <my design>.vho <my testbench>.vhd r
vsim -L lpm -L altera_mf -L sgate -L stratixiigx -L stratixiigx_hssi \
-sdftyp <design instance>=<path to .sdo file>.sdo work.<my testbench> \
-t ps +transport_int_delays +transport_path_delays r
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 2: Mentor Graphics ModelSim/ QuestaSim Support
Simulating Designs that Include Transceivers
2–21
Performing Gate-Level Timing Simulation in Verilog HDL ModelSim-Altera)
To perform gate-level timing simulation for Stratix II GX devices in Verilog HDL, type
the following commands:
vlog -work <my design>.vo <my testbench>.v r
vsim -L lpm_ver -L altera_mf_ver -L sgate_ver -L stratixiigx_ver \
-L stratixiigx_hssi_ver work.<my testbench> -t ps \
+transport_int_delays +transport_path_delays r
Performing Gate-Level Timing Simulation in Verilog HDL ModelSim/QuestaSim)
To perform gate-level timing simulation for Stratix II GX devices in Verilog HDL, type
the following commands:
vlog -work lpm_ver 220model.v r
vlog -work altera_mf_ver altera_mf.v r
vlog -work sgate_ver sgate.v r
vlog -work stratixiigx_ver stratixiigx_atoms.v r
vlog -work stratixiigx_hssi_ver stratixiigx_hssi_atoms.v r
vlog -work <my design>.vo <my testbench>.v r
vsim -L lpm_ver -L altera_mf_ver -L sgate_ver -L stratixiigx_ver \
-L stratixiigx_hssi_ver work.<my testbench> -t ps \
+transport_int_delays +transport_path_delays r
Functional Simulation for Stratix IV GX Devices
To perform a functional simulation of your design that instantiates the ALTGX
megafunction, which enables the gigabit transceiver block on Stratix IV devices, compile
the stratixiv_hssi model file into the altgx library.
1
The stratixiv_hssi model file references the lpm and sgate libraries. If you are using
ModelSim/QuestaSim, you must create these libraries to perform a simulation.
Performing Functional Simulation in VHDL (ModelSim-Altera)
To perform functional simulation for Stratix IV devices in VHDL, type the following
commands:
vcom -work <my design>.vhd <my testbench>.vhd r
vsim -L lpm -L altera_mf -L sgate -L stratixiv_hssi work.<my testbench>r
Performing Functional Simulation in VHDL (ModelSim/QuestaSim)
To perform functional simulation for Stratix IV devices in VHDL, type the following
commands:
vcom -work altera_mf altera_mf_components.vhd altera_mf.vhd r
vcom -work lpm 220pack.vhd 220model.vhd r
vcom -work sgate sgate_pack.vhd sgate.vhd r
vcom -work stratixiv_hssi \
stratixiv_hssi_atoms.vhd stratixiv_hssi_components.vhd r
vcom -work <my design>.vhd <my testbench>.vhd r
vsim -L lpm -L altera_mf -L sgate -L stratixiv_hssi work.<my testbench> r
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
2–22
Chapter 2: Mentor Graphics ModelSim/ QuestaSim Support
Simulating Designs that Include Transceivers
Performing Functional Simulation in Verilog HDL (ModelSim-Altera)
To perform functional simulation for Stratix IV devices in Verilog HDL, type the
following commands:
vlog -work <my design>.v <my testbench>.v r
vsim -L lpm_ver -L altera_mf_ver -L sgate_ver -L \
stratixiv_hssi_ver work.<my testbench> r
Performing Functional Simulation in Verilog HDL (ModelSim/QuestaSim)
To perform functional simulation for Stratix IV devices in Verilog HDL, type the
following commands:
vlog
vlog
vlog
vlog
vlog
vsim
-work lpm_ver 220model.v r
-work altera_mf_ver altera_mf.v r
-work sgate_ver sgate.v r
-work straixiv_hssi_ver stratixiv_hssi_atoms.v r
-work <my design>.v <my testbench>.v r
-L lpm_ver -L sgate_ver-L stratixiv_hssi_ver work.<my testbench> r
Gate-Level Timing Simulation for Stratix IV GX Devices
Perform a gate-level timing simulation of your design that includes a Stratix IV
transceiver by compiling the stratixiv_atoms and stratixiv_hssi_atoms model files
into the stratixiv and stratixiv_hssi libraries, respectively.
1
The stratixgx_hssi_atoms model file references the lpm and sgate libraries. If you are
using ModelSim/QuestaSim, you must create these libraries to perform a simulation.
Performing Gate-Level Timing Simulation in VHDL (ModelSim-Altera)
To perform gate-level timing simulation for Stratix IV devices in VHDL, type the
following commands:
vcom -work <my design>.vho <my testbench>.vhd r
vsim -L lpm -L altera_mf -L sgate -L stratixiv -L stratixiv_hssi \
-sdftyp <design instance>=<path to .sdo file>.sdo work.<my testbench> \
-t ps - +transport_int_delays +transport_path_delays r
Performing Gate-Level Timing Simulation in VHDL (ModelSim/QuestaSim)
To perform gate-level timing simulation for Stratix IV devices in VHDL, type the
following commands:
vcom -work lpm 220pack.vhd 220model.vhd r
vcom -work altera_mf altera_mf_components.vhd altera_mf.vhd r
vcom -work sgate sgate_pack.vhd sgate.vhd r
vcom -work stratixiv stratixiv_atoms.vhd stratixiv_components.vhd r
vcom -work stratixiv_hssi stratixiv_hssi_atoms.vhd \
stratixiv_hssi_components.vhd r
vcom -work <my design>.vho <my testbench>.vhd r
vsim -L lpm -L altera_mf -L sgate -L stratixiv -L stratixiv_hssi \
-sdftyp <design instance>=<path to .sdo file>.sdo work.<my testbench> \
-t ps +transport_int_delays +transport_path_delays r
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 2: Mentor Graphics ModelSim/ QuestaSim Support
Simulating Designs that Include Transceivers
2–23
Performing Gate-Level Timing Simulation in Verilog HDL (ModelSim-Altera)
To perform gate-level timing simulation for Stratix IV devices in Verilog HDL, type
the following commands:
vlog -work <my design>.vo <my testbench>.v r
vsim -L lpm_ver -L altera_mf_ver -L sgate_ver -L stratixiv_ver -L \
stratixiv_hssi_ver work.<my testbench> -t ps +transport_int_delays \
+transport_path_delays r
Performing Gate-Level Timing Simulation in Verilog HDL (ModelSim/QuestaSim)
To perform gate-level timing simulation for Stratix IV devices in Verilog HDL, type
the following commands:
vlog -work lpm_ver 220model.v r
vlog -work altera_mf_ver altera_mf.v r
vlog -work sgate_ver sgate.v r
vlog -work stratixiv_ver stratixiv_atoms.v r
vlog -work stratixiv_hssi_ver stratixiv_hssi_atoms.v r
vlog -work <my design>.vo <my testbench>.v r
vsim -L lpm_ver -L altera_mf_ver -L sgate_ver -L stratixiv_ver \
-L stratixiv_hssi_ver work.<my testbench> -t ps +transport_int_delays \
+transport_path_delays r
Functional Simulation for Stratix V GX Devices
To perform a functional simulation of your design that instantiates the Custom PHY
megafunction, which enables the gigabit transceiver block on Stratix V devices,
compile the stratixv_hssi model file.
© July 2010
1
The stratixiv_hssi model file references the lpm and sgate libraries. You must create
these libraries to perform a simulation using ModelSim/QuestaSim.
1
The transceiver module from the MegaWizard Plug-In Manager is created in
Interfaces/Transceiver PHY. Select Custom PHY.
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
2–24
Chapter 2: Mentor Graphics ModelSim/ QuestaSim Support
Using the NativeLink Feature with ModelSim-Altera or
Performing Functional Simulation in VHDL (ModelSim/QuestaSim)
For information about how to perform functional simulation for Stratix V devices in
VHDL, refer to “Performing Functional Simulation” on page 2–9.
Performing Functional Simulation in Verilog HDL (ModelSim-Altera)
For information about how to perform functional simulation for Stratix V devices in
Verilog HDL, refer to Performing a Functional Simulation with the ModelSim-Altera
Software and Compiling Stratix V Libraries in Quartus II Help.
Performing Functional Simulation in Verilog HDL (ModelSim/QuestaSim)
For information about how to perform functional simulation for Stratix V devices in
Verilog HDL, refer to “Performing Functional Simulation” on page 2–13.
Transport Delays
By default, the ModelSim/QuestaSim software filters out all pulses that are shorter
than the propagation delay between primitives. Turning on the transport delay
options in the ModelSim/QuestaSim software prevents the simulation tool from
filtering out these pulses. Use the following options to ensure that all signal pulses are
seen in the simulation results.
+transport_path_delays
Use this option when the pulses in your simulation are shorter than the delay within a
gate-level primitive.
+transport_int_delays
Use this option when the pulses in your simulation are shorter than the interconnect
delay between gate-level primitives.
1
The +transport_path_delays and +transport_int_delays options are also used by
default in the NativeLink feature for gate-level timing simulation.
f
For more information about either of these options, refer to the ModelSim-Altera
Command Reference installed with the ModelSim/QuestaSim software.
The following ModelSim/QuestaSim software command shows the command line
syntax to perform a gate-level timing simulation with the device family library:
vsim -t 1ps -L stratixii -sdftyp /i1=filtref_vhd.sdo work.filtref_vhd_vec_tst \
+transport_int_delays +transport_path_delays
Using the NativeLink Feature with ModelSim-Altera or
ModelSim/QuestaSim Software
The NativeLink feature in the Quartus II software facilitates the seamless transfer of
information between the Quartus II software and EDA tools and allows you to run
ModelSim/QuestaSim within the Quartus II software.
f
For more information, refer to the “Using the NativeLink Feature” section in the
Simulating Designs with EDA Tools chapter in volume 3 of the Quartus II Handbook.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 2: Mentor Graphics ModelSim/ QuestaSim Support
ModelSim/QuestaSim Error Message Verification
2–25
ModelSim/QuestaSim Error Message Verification
ModelSim/QuestaSim error and warning messages are tagged with a vsim or vcom
code. To determine the cause and resolution for a vsim or vcom error or warning, use
the verror command.
For example, ModelSim/QuestaSim may display the following error message:
# ** Error:
C:/altera_trn/DUALPORT_TRY/simulation/modelsim/DUALPORT_TRY.vho(31):
(vcom-1136) Unknown identifier "stratixiii".
In this case, type the following command:
verror 1136 r
At that point, the error message appears as follows:
#
#
#
#
vcom Message # 1136:
The specified name was referenced but was not found. This indicates
that either the name specified does not exist or is not visible at
this point in the code.
Generating a Timing Value Change Dump (.vcd) File for the PowerPlay
Power Analyzer
To generate a timing Value Change Dump (*.vcd) file for the PowerPlay Power
Analyzer, you must first generate a *.vcd script file in the Quartus II software and run
the *.vcd script file from the ModelSim/QuestaSim or ModelSim-Altera software to
generate a timing *.vcd file. This timing *.vcd file can then be used by PowerPlay for
power analysis. The following instructions show you step-by-step how to generate a
timing *.vcd file.
To generate timing VCD Scripts in the Quartus II software, perform the following
steps:
1. In the Quartus II software, on the Assignments menu, click Settings. The Settings
dialog box appears.
2. In the Category list, click the “+” icon to expand EDA Tool Settings and select
Simulation. The Simulation page appears.
3. Choose the appropriate third-party simulation tool (ModelSim/QuestaSim or
ModelSim-Altera) in the Tool name list. Turn on the Generate Value Change
Dump (VCD) file script option.
4. To generate the *.vcd script file, perform a full compilation.
To generate a timing *.vcd file in the ModelSim-Altera or ModelSim/QuestaSim
software, perform the following steps:
1. In the ModelSim/QuestaSim or ModelSim-Altera software, before simulating
your design, source the <revision_name>_dump_all_vcd_nodes.tcl script. To
source the Tcl script, run the following command before running the vsim
command. For example:
source <revision_name>_dump_all_vcd_nodes.tcl r
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
2–26
Chapter 2: Mentor Graphics ModelSim/ QuestaSim Support
Viewing a Waveform from a .wlf File
2. Continue to run the simulation as usual until the end of the simulation. Exit the
ModelSim/QuestaSim or ModelSim-Altera software. If you do not exit the
software, the ModelSim/QuestaSim software may end the writing process of the
timing *.vcd files improperly, resulting in a corrupted timing *.vcd file.
f
For more information about using the timing *.vcd file for power estimation, refer to
the PowerPlay Power Analysis chapter in volume 3 of the Quartus II Handbook.
Viewing a Waveform from a .wlf File
A .wlf file is automatically generated when your simulation is done. The .wlf file is
used for generating the waveform view through ModelSim-Altera or
ModelSim/QuestaSim.
To view a waveform from a .wlf file through ModelSim-Altera or
ModelSim/QuestaSim, perform the following steps:
1. Type vsim on the command line. The ModelSim/QuestaSim or ModelSim-Altera
dialog box appears.
2. On the File menu, click Datasets. The Datasets Browser dialog box appears.
3. Click Open and browse to the directory that contains your .wlf file.
4. Select the .wlf file and click Open, then click OK.
5. Click Done.
6. In the Object browser, select the signals that you want to observe.
7. On the Add menu, click Wave and then click Selected Signals.
You cannot view a waveform from a .vcd file in ModelSim-Altera or
ModelSim/QuestaSim directly. The .vcd file must first be converted to a .wlf file.
8. Use the vcd2wlf command to convert the file. For example, type the following on
a command-line:
vcd2wlf <example>.vcd <example>.wlf r
9. After you convert the .vcd file to a .wlf file, follow the procedures for viewing a
waveform from a .wlf file through ModelSim/QuestaSim.
You can also convert your .wlf file to a .vcd file by using the wlf2vcd command.
Scripting Support
You can run procedures and create settings described in this chapter in a Tcl script.
You can also run some procedures at the command line prompt.
f
For more information about Tcl scripting, refer to the Tcl Scripting chapter in volume 2
of the Quartus II Handbook.
f
For more information about command line scripting, refer to the Command Line
Scripting chapter in volume 2 of the Quartus II Handbook.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 2: Mentor Graphics ModelSim/ QuestaSim Support
Scripting Support
2–27
For detailed information about scripting command options, refer to the Quartus II
Help command line and Tcl API help browser. To access this information, type the
following command to start a help browser:
quartus_sh --qhelp r
Generating a Post-Synthesis Simulation Netlist for ModelSim/QuestaSim
You can use the Quartus II software to generate a post-synthesis simulation netlist
with Tcl commands or with a command at the command-line prompt. The following
example assumes that you are selecting ModelSim/QuestaSim (Verilog HDL output
from the Quartus II software).
Tcl Commands
Use the following Tcl commands to set the output format to Verilog HDL, the
simulation tool to ModelSim/QuestaSim for Verilog HDL, and to generate a
functional netlist:
set_global_assignment-name EDA_SIMULATION_TOOL "ModelSim (Verilog)" r
set_global_assignment-name EDA_GENERATE_FUNCTIONAL_NETLIST ON r
or
set_global_assignment-name EDA_SIMULATION_TOOL "QuestaSim (Verilog)" r
set_global_assignment-name EDA_GENERATE_FUNCTIONAL_NETLIST ON r
Command Prompt
Use the following command to generate a simulation output file for the
ModelSim/QuestaSim simulator. Specify VHDL or Verilog HDL for the format:
quartus_eda <project name> --simulation=on --format=<format> \
--tool=ModelSim --functional r
or
quartus_eda <project name> --simulation=on --format=<format> \
--tool=QuestaSim --functional r
Generating a Gate-Level Timing Simulation Netlist for ModelSim/QuestaSim
Use the Quartus II software to generate a gate-level timing simulation netlist with Tcl
commands or with a command at the command prompt.
Tcl Commands
Use one of the following Tcl commands:
■
set_global_assignment -name EDA_SIMULATION_TOOL \
"ModelSim-Altera (Verilog)" r
or
set_global_assignment -name EDA_SIMULATION_TOOL \
"QuestaSim-Altera (Verilog)" r
■
set_global_assignment -name EDA_SIMULATION_TOOL \
"ModelSim-Altera (VHDL)" r
or
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
2–28
Chapter 2: Mentor Graphics ModelSim/ QuestaSim Support
Software Licensing and Licensing Setup in ModelSim-Altera Subscription
set_global_assignment -name EDA_SIMULATION_TOOL \
"QuestaSim-Altera (VHDL)" r
■
set_global_assignment -name EDA_SIMULATION_TOOL \
"ModelSim (Verilog)" r
or
set_global_assignment -name EDA_SIMULATION_TOOL \
"QuestaSim (Verilog)" r
■
set_global_assignment -name EDA_SIMULATION_TOOL \
"ModelSim (VHDL)" r
or
set_global_assignment -name EDA_SIMULATION_TOOL \
"QuestaSim (VHDL)" r
Command Line
Generate a simulation output file for the ModelSim/QuestaSim simulator by
specifying VHDL or Verilog HDL for the format by typing the following command at
the command prompt:
quartus_eda <project name> --simulation=on --format=<format> \
--tool=ModelSim r
or
quartus_eda <project name> --simulation=on --format=<format> \
--tool=QuestaSim r
Software Licensing and Licensing Setup in ModelSim-Altera
Subscription Edition
License the ModelSim-Altera Subscription Edition software subscription with a
parallel port FIXEDPC license, or a network FLOATNET or FLOATPC license. Each
Altera software subscription includes a license for both VHDL and Verilog HDL. The
ModelSim-Altera Subscription Edition software supports both VHDL and Verilog
HDL, but the software does not support mixed language simulation.
1
The USB software guard is not supported by versions earlier than Mentor Graphics
ModelSim software 5.8d.
You can obtain a license for the ModelSim-Altera Subscription Edition software from
the Altera website at www.altera.com. Get licensing information for the
Mentor Graphics ModelSim software directly from Mentor Graphics. Refer to
Figure 2–1 for the set-up process.
1
For ModelSim-Altera software versions prior to 5.5b, use the PCLS utility included
with the software to set up the license.
For the Quartus II software version 8.1 and later, the no-cost entry level of the
ModelSim-Altera software does not require a license file. However, you must request
a license file to use the ModelSim-Altera Subscription Edition software.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 2: Mentor Graphics ModelSim/ QuestaSim Support
Conclusion
2–29
Figure 2–1. ModelSim-Altera Subscription Edition Software Licensing Set Up Process
Start
Initial Installation
Using
the ModelSim-Altera
Starter Edition
software?
yes
no
Is the ModelSim-Altera
software properly licensed?
yes
no
Set the LM_LICENSE_FILE Variable
End
LM_LICENSE_FILE Variable
Altera recommends setting the LM_LICENSE_FILE environment variable to the
location of the license file. For example, the value for the LM_LICENSE_FILE
environment variable should point to <path to license file>\license.dat.
f
For more information about setting up the license for ModelSim-Altera Subscription
Edition software, refer to the Altera Software Installation and Licensing manual.
Conclusion
Using the ModelSim/QuestaSim and ModelSim-Altera simulation software within
the Altera FPGA design flow enables Altera software users to easily and accurately
perform functional simulations, post-synthesis simulations, and gate-level
simulations on their designs. Proper verification of designs at the functional,
post-synthesis, and post place-and-route stages using the ModelSim/QuestaSim and
ModelSim-Altera software helps ensure design functionality and success and,
ultimately, a quick time-to-market.
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
2–30
Chapter 2: Mentor Graphics ModelSim/ QuestaSim Support
Document Revision History
Document Revision History
Table 2–1 shows the revision history for this chapter.
Table 2–1. Document Revision History (Part 1 of 2)
Date
July 2010
November 2009
March 2009
Version
10.0.0
9.1.0
9.0.0
Changes Made
■
Removed simulation library tables and linked to Quartus II Help
■
Added other links to Quartus II Help and ModelSim-Altera Help where appropriate
and removed redundant information
■
Added QuestaSim support
■
Added Stratix V simulation information
■
Minor editorial changes throughout
■
Removed Referenced Documents section
■
Removed NativeLink information and referenced new Simulating Designs with EDA
Tools chapter
■
Added Stratix IV transceiver simulation section
■
Reformatted transceiver simulation sections
■
Text edits throughout chapter
Added the following sections:
■
“Compile Libraries Using the EDA Simulation Library Compiler” on page 2–17
■
“Generate Simulation Script from EDA Netlist Writer” on page 2–77
■
“Viewing a Waveform from a .wlf File” on page 2–78
Updated the following:
November 2008
8.1.0
■
Table 2–1, Table 2–2, Table 2–5, Table 2–6, Table 2–7, Table 2–8, Table 2–9,
Table 2–10
■
Figure 2–4 on page 2–81
■
All sections titled “Loading the Design”
Updated the following:
■
Table 2–2, Table 2–3, Table 2–4, Table 2–5, Table 2–6
■
Removed --zero_ic_delays from quartus_sta option in “Generate
Post-Synthesis Simulation Netlist Files” on page 2–11
■
Removed steps to include the library when the simulation is run in VHDL mode from
all procedures; this is no longer necessary
■
Added information about the Altera Simulation Library Compiler throughout the
chapter
■
Added “Compile Libraries Using the Altera Simulation Library Compiler” on
page 2–15
■
Added “Disabling Simulation” on page 2–72
■
Minor editorial updates
■
Updated entire chapter using 8½” × 11” chapter template
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 2: Mentor Graphics ModelSim/ QuestaSim Support
Document Revision History
2–31
Table 2–1. Document Revision History (Part 2 of 2)
Date
Version
May 2008
© July 2010
8.0.0
Changes Made
Updated the following:
■
“Altera Design Flow with ModelSim-Altera or ModelSim Software” on page 2–3
■
“Simulation Libraries” on page 2–4
■
“Simulation Netlist Files” on page 2–11
■
“Perform Simulation Using ModelSim-Altera Software” on page 2–15
■
“Perform Simulation Using ModelSim Software” on page 2–33
■
“Simulating Designs that Include Transceivers” on page 2–57
■
“Using the NativeLink Feature with ModelSim-Altera or ModelSim Software” on
page 2–63
■
“Generating a Timing VCD File for PowerPlay” on page 2–68
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.
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
2–32
Quartus II Handbook Version 10.0 Volume 3: Verification
Chapter 2: Mentor Graphics ModelSim/ QuestaSim Support
Document Revision History
© July 2010 Altera Corporation
3. Synopsys VCS and VCS MX Support
QII53002-10.0.0
This chapter describes how to use the Synopsys VCS and VCS MX software to
simulate designs that target Altera® FPGAs. This chapter provides step-by-step
instructions about how to perform functional simulations, post-synthesis simulations,
and gate-level timing simulations.
1
Verilog HDL design simulation is the same in both the VCS and VCS MX software. In
this chapter, VCS MX is used in VHDL design simulation examples.
This chapter includes the following topics:
■
“Software Requirements”
■
“Using the VCS or VCS MX Software in the Quartus II Design Flow” on page 3–1
■
“Common VCS and VCS MX Software Compiler Options” on page 3–8
■
“Using DVE” on page 3–8
■
“Debugging Support Command-Line Interface” on page 3–8
■
“Simulating Designs that Include Transceivers” on page 3–9
■
“Transport Delays” on page 3–13
■
“Using NativeLink with the VCS or VCS MX Software” on page 3–13
■
“Generating a Timing .vcd File for the PowerPlay Power Analyzer” on page 3–13
■
“Viewing a Waveform from a .vpd or .vcd File” on page 3–14
■
“Scripting Support” on page 3–15
Software Requirements
To simulate your design using the Synopsys VCS or VCS MX software, you must first
set up the Altera libraries. These libraries are installed with the Quartus® II software.
f
For more information about installing the software and the directories created during
the Quartus II software installation, refer to the Altera Software Installation and
Licensing manual.
Using the VCS or VCS MX Software in the Quartus II Design Flow
You can perform the following types of simulations using the VCS and VCS MX
software:
f
© July 2010
■
Functional simulation
■
Post-synthesis simulation
■
Gate-level timing simulation
Refer to the “PLD Design Flow” section in the Simulating Designs with EDA Tools
chapter in volume 3 of the Quartus II Handbook for the Quartus II software design flow.
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
3–2
Chapter 3: Synopsys VCS and VCS MX Support
Using the VCS or VCS MX Software in the Quartus II Design Flow
Compiling Libraries Using the EDA Simulation Library Compiler
The EDA Simulation Library Compiler is used to compile Verilog HDL and VHDL
simulation libraries for all Altera devices and supported third-party simulators. You
can compile all libraries required by functional and gate-level timing simulations.
f
For more information, refer to the “EDA Simulation Library Compiler” section in the
Simulating Designs with EDA Tools chapter in volume 3 of the Quartus II Handbook.
Functional Simulations
Functional simulations verify the functionality of the design before synthesis,
placement, and routing. These simulations are independent of any Altera FPGA
architecture implementation. After the HDL designs are verified to be functionally
correct, the next step is to synthesize the design and use the Quartus II software to
place-and-route the design in an Altera device.
To functionally simulate an Altera FPGA design in the VCS or VCS MX software that
uses Altera intellectual property (IP) megafunctions or a library of parameterized
modules (LPM) functions, you must include certain libraries during the compilation.
f
For a list of the functional simulation library files in the Quartus II directory, refer to
Altera Functional Simulation Libraries in Quartus II Help.
Functional Simulation for Verilog HDL Designs
The following VCS command performs a functional simulation for Verilog HDL
designs with one of the libraries listed in Altera Functional Simulation Libraries in
Quartus II Help:
vcs -R <testbench>.v <design name>.v –v <altera_library1>.v -v <altera_library2>.v r
If you have already generated the option file (simlib_comp.vcs) from “Compiling
Libraries Using the EDA Simulation Library Compiler” on page 3–2, type the
following command:
vcs -f simlib_comp.vcs r
Be sure to include the design files and testbench files in simlib_comp.vcs.
Alternatively, you can use the following commands to perform functional simulation
for Verilog HDL designs:
# Create Libraries Directories
mkdir <Directory_to_store_compiled_altera_library1>
mkdir <Directory_to_store_compiled_altera_library2>
# Create Work Directory
mkdir <Directory_to_store_compiled_design_and_testbench_files>
# Compilation
# (Before this step, make sure the mapped file "synopsys_sim.setup" was created.)
# Libraries Compilation
vlogan -work <altera_library1_name> <altera_library1>.v
vlogan -work <altera_library2_name> <altera_library2>.v
# Design and Test bench files Compilation
vlogan -work <work_library_name> <design>.v <testbench>.v
# Eleboration
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 3: Synopsys VCS and VCS MX Support
Using the VCS or VCS MX Software in the Quartus II Design Flow
3–3
vcs -debug_all <work_library_name>.<testbench_top_level_module>
# Run Simulation
simv -gui
The synopsys_sim.setup file contains the following mapping commands to map the
libraries:
<altera_library1_name> : <Directory_to_store_compiled_altera_library1>
<altera_library2_name> : <Directory_to_store_compiled_altera_library2>
<work_library_name> : <Directory_to_store_compiled_design_and_testbench_files>
1
The altera_mf.v model files should be compiled into the altera_mf_ver library. The
220model.v model files should be compiled into the lpm_ver library.
If you are targeting a Stratix V device, compile the following files in the
quartus/eda/sim_lib/synopsys directory:
stratixv_atoms_ncrypt.v
stratixv_hssi_atoms_ncrypt.v
stratixv_pcie_hip_atoms_ncrypt.v
These files contain IEEE encrypted Verilog models.
1
Compile stratixv_pcie_hip_atoms_ncrypt.v with the SystemVerilog option.
Also, compile the following files in the quartus/eda/sim_lib directory:
stratixv_atoms.v
stratixv_hssi_atoms.v
stratixv_pcie_hip_atoms.v
1
The PCIe® files are required only if you are using the PCIe HIP.
Functional Simulation for VHDL Designs
For VHDL designs, you need to use VCS MX software to perform all three types of
simulations. The following commands are for performing a functional simulation for
VHDL designs with one of the libraries listed in Altera Functional Simulation Libraries
in Quartus II Help:
# Create Libraries Directories
mkdir <Directory_to_store_compiled_altera_library1>
mkdir <Directory_to_store_compiled_altera_library2>
# Create Work Directory
mkdir <Directory_to_store_compiled_design_and_testbench_files>
# Compilation
# (Before this step, make sure the mapped file "synopsys_sim.setup" is created.)
# Libraries Compilation
vhdlan -work <altera_library1_name> <altera_library1>.vhd
vhdlan -work <altera_library2_name> <altera_library2>.vhd
# Design and Test bench files Compilation
vhdlan -work <work_library_name> <design>.vhd <testbench>.vhd
# Eleboration
vcs -debug_all <work_library_name>.<testbench_top_level_module>
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
3–4
Chapter 3: Synopsys VCS and VCS MX Support
Using the VCS or VCS MX Software in the Quartus II Design Flow
# Run Simulation
simv -gui
The synopsys_sim.setup file contains the following mapping commands to map the
libraries:
<altera_library1_name> : <Directory_to_store_compiled_altera_library1>
<altera_library2_name> : <Directory_to_store_compiled_altera_library2>
<work_library_name> : <Directory_to_store_compiled_design_and_testbench_files>
1
The altera_mf.v model files should be compiled into the altera_mf_ver library. The
220model.v model files should be compiled into the lpm_ver library.
1
If you have generated the Altera libraries with the EDA Simulation Library Compiler,
ignore the steps # Create Libraries Directories and # Libraries Compilation.
If you are targeting a Stratix V device, compile the following files in the
quartus/eda/sim_lib/synopsys directory:
stratixv_atoms_ncrypt.v
stratixv_hssi_atoms_ncrypt.v
stratixv_pcie_hip_atoms_ncrypt.v
These files contain IEEE encrypted Verilog models suitable for VHDL/Verilog
co-simulation. You need a co-simulation license from Synopsys to use these models.
1
Compile these encrypted Verilog files before you compile any VHDL files.
1
Compile stratixv_pcie_hip_atoms_ncrypt.v with the SystemVerilog option.
Also, compile the following files in the quartus/eda/sim_lib directory:
stratixv_atoms.vhd
stratixv_components.vhd
stratixv_hssi_components.vhd
stratixv_hssi_atoms.vhd
stratixv_pcie_components.vhd
stratixv_pcie_hip_atoms.vhd
1
The PCIe files are required only if you are using the PCIe HIP.
Post-Synthesis Simulation
A post-synthesis simulation verifies the functionality of a design after synthesis has
been performed. You can create a post-synthesis netlist in the Quartus II software and
use this netlist to perform a post-synthesis simulation in the VCS or VCS MX
software. When the post-synthesis version of the design has been verified, the next
step is to place-and-route the design in the target architecture using the Quartus II
software.
f
For more information, refer to the “Generating Post-Synthesis Simulation Netlist
Files” section in the Simulating Designs with EDA Tools chapter in volume 3 of the
Quartus II Handbook.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 3: Synopsys VCS and VCS MX Support
Using the VCS or VCS MX Software in the Quartus II Design Flow
1
3–5
You cannot perform post-synthesis or post-fit simulation if you are targeting the
Stratix V device family.
Post-Synthesis Simulation for Verilog HDL Designs
The following VCS command shows the command-line syntax used to perform a
post-synthesis simulation with the appropriate device family library listed in Altera
Functional Simulation Libraries in Quartus II Help.
vcs -R <testbench> <post synthesis netlist> -v <altera_library1> r
If you have already generated the option file (simlib_comp.vcs) as described in
“Compiling Libraries Using the EDA Simulation Library Compiler” on page 3–2,
modify the simlib_comp.vcs file to add the testbench and post synthesis netlist, and
then type the following command:
vcs -f simlib_comp.vcs r
Be sure to include the post synthesis netlist file and testbench files in
simlib_comp.vcs.
Alternatively, you can use the following commands to perform Post-Synthesis
simulation for Verilog HDL designs:
# Create Libraries Directories
mkdir <Directory_to_store_compiled_altera_library1>
mkdir <Directory_to_store_compiled_altera_library2>
# Create Work Directory
mkdir <Directory_to_store_compiled_post_synthesis_netlist_and_testbench_files>
# Compilation
# (Before this step, make sure that mapped file "synopsys_sim.setup" is created.)
# Libraries Compilation
vlogan -work <altera_library1_name> <altera_library1>.v
vlogan -work <altera_library2_name> <altera_library2>.v
# Design and Test bench files Compilation
vlogan -work <work_library_name> <post_synthesis_netlist>.vo <test_bench>.v
# Eleboration
vcs -debug_all <work_library_name>.<testbench_top_level_module>
# Run Simulation
simv -gui
The synopsys_sim.setup file contains the following commands to map the libraries:
<altera_library1_name> : <Directory_to_store_compiled_altera_library1>
<altera_library2_name> : <Directory_to_store_compiled_altera_library2>
<work_library_name> :
<Directory_to_store_compiled_post_synthesis_netlist_and_testbench_files>
Post-Synthesis Simulation for VHDL Designs
The following VCS MX commands show the command-line syntax used to perform a
post-synthesis simulation with the appropriate device family library listed in Altera
Post-Fit Libraries in Quartus II Help.
# Create Libraries Directories
mkdir <Directory_to_store_compiled_altera_library1>
mkdir <Directory_to_store_compiled_altera_library2>
# Create Work Directory
mkdir <Directory_to_store_compiled_post_synthesis_netlist_and_testbench_files>
# Compilation
#(Before this step, make sure that mapped file "synopsys_sim.setup" is created.)
# Libraries Compilation
vhdlan -work <altera_library1_name> <altera_library1>.vhd
vhdlan -work <altera_library2_name> <altera_library2>.vhd
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
3–6
Chapter 3: Synopsys VCS and VCS MX Support
Using the VCS or VCS MX Software in the Quartus II Design Flow
# Design and Test bench files Compilation
vhdlan -work <work_library_name> <post_synthesis_netlist>.vho <test_bench>.vhd
# Eleboration
vcs -debug_all <work_library_name>.<testbench_top_level_module>
# Run Simulation
simv -gui
The synopsys_sim.setup file contains the following commands to map the libraries:
<altera_library1_name> : <Directory_to_store_compiled_altera_library1>
<altera_library2_name> : <Directory_to_store_compiled_altera_library2>
<work_library_name> :
<Directory_to_store_compiled_post_synthesis_netlist_and_testbench_files>
1
If you have generated the Altera libraries as described in “Compiling Libraries Using
the EDA Simulation Library Compiler” on page 3–2, ignore the steps # Create
Libraries Directories and # Libraries Compilation.
Gate-Level Timing Simulation
A gate-level timing simulation verifies the functionality and timing of the design after
place-and-route. You can create a post-fit netlist in the Quartus II software and use
this netlist to perform a gate-level timing simulation in the VCS or VCS MX software.
f
For information about how to generate a gate-level timing simulation netlist, refer to
the “Generating Gate-Level Timing Simulation Netlist Files” section in the Simulating
Designs with EDA Tools chapter in volume 3 of the Quartus II Handbook.
f
For a list of the gate-level timing simulation library files in the Quartus II directory,
refer to Altera Post-Fit Libraries in Quartus II Help.
1
You cannot perform post-synthesis or post-fit simulation if you are targeting the
Stratix V device family.
Gate-Level Timing Simulation for Verilog HDL Designs
For gate-level timing simulation, follow the steps in “Post-Synthesis Simulation for
Verilog HDL Designs” on page 3–5.
You do not have to specify the Standard Delay Output File (*.sdo) file because it is
already specified in the Verilog Output File (*.vo) file. However, the *.sdo file must be
in the same directory as the simulator executable file simv generated by VCS.
Gate-Level Timing Simulation for VHDL Designs
For gate-level timing simulation, follow the steps in “Post-Synthesis Simulation for
VHDL Designs” on page 3–5.
For VHDL, the *.sdo file must be specified in the simv command as follows:
simv -xlrm -gui -sdf typ:<testbench module name>/<design instnace
name>.sdo r
1
Adding the -xlrm switch avoids the errors that occur when the timing arcs in SDO
do not match Altera VHDL simulation models as per the IEEE VITAL ASIC standard.
However, adding this switch reduces timing accuracy, as it may cause some SDO
delays to be ignored. Therefore, Altera recommends generating the Verilog HDL
simulation output netlist (.vo) if you want to perform gate-level timing simulation.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 3: Synopsys VCS and VCS MX Support
Using the VCS or VCS MX Software in the Quartus II Design Flow
3–7
Disabling Timing Violation on Registers
In certain situations, the timing violations can be ignored and you can disable the “X”
propagation that happens when there are timing violations on registers (for example,
timing violations that occur in internal synchronization registers used for
asynchronous clock-domain crossing).
By default, the x_on_violation_option logic option that applies to all registers in the
design is On, which means a register outputs “X” whenever a timing violation occurs.
To disable “X” propagation due to a timing violation on certain registers, you can set
the x_on_violation_option logic option to Off for those registers. The following
command is an example of the Quartus II Settings File (.qsf):
set_instance_assignment -name X_ON_VIOLATION_OPTION OFF –to <register_name> r
Performing Timing Simulation Using the Post-Synthesis Netlist
You can perform a timing simulation using the post-synthesis netlist instead of using
a gate-level netlist, and you can generate an .sdo file without running the Fitter. In this
case, the .sdo file includes all timing values for the device cells only. Interconnect
delays are not included because fitting (placement and routing) has not been
performed.
To generate the post-synthesis netlist and the .sdo file, type the following commands
at a command prompt:
quartus_map <project
quartus_tan <project
--zero_ic_delays r
quartus_eda <project
--tool= <third-party
name> -c <revision name> r
name> -c <revision name> --post_map \
name> -c <revision name> --simulation \
EDA tool> --format=<HDL language> r
For more information about the -format and -tool options, type the following
command:
quartus_eda -help=<options> command r
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
3–8
Chapter 3: Synopsys VCS and VCS MX Support
Common VCS and VCS MX Software Compiler Options
Common VCS and VCS MX Software Compiler Options
The VCS software has options that help you simulate your design. Table 3–1 lists
some of the available options.
Table 3–1. VCS Software Compiler Options
Library
Description
-R
Runs the executable file immediately.
-v <library filename>
Specifies a Verilog HDL library file (for example, 220model.v or altera_mf.v). The VCS
software looks in this file for module definitions that are found in the source code.
-y <library directory> Specifies a Verilog HDL library directory. The VCS software looks for library files in this
folder that contain module definitions that are instantiated in the source code.
+compsdf
Indicates that the VCS software compiler includes the back-annotated Standard Delay
File (.sdf) file in the compilation.
+cli
The VCS software enters Command-Line Interface (CLI) mode upon successful
compilation completion.
+race
Specifies that the VCS software generate a report that indicates all of the race conditions
in the design. The default report name is race.out.
-P
Compiles user-defined Programming Language Interface (PLI) table files.
-q
Indicates the VCS software runs in quiet mode. All messages are suppressed.
f
For more information about VCS software options, refer to the VCS User Guide.
Using DVE
Design Viewpoint Editor (DVE) is the graphical debugging system for the VCS and
VCS MX software. This tool is included with the VCS MX software. It can be run by
using the -gui (simulating option) when running a simulation.
The following VCS or VCS MX software command shows the command-line syntax
for simulating in DVE:
simv -gui (for Verilog HDL simulations)
However, to open the GUI with these commands, you must enable the use of Unified
Command Line Interface (UCLI) and DVE when performing elaboration. To enable
UCLI and DVE, enter the following command:
vcs -debug_all (for Verilog HDL simulations)
f
For more information about using DVE, refer to the DVE User Guide included in the
VCS MX software installation.
Debugging Support Command-Line Interface
The Synopsys VCS software has an interactive non-graphical debugging capability
that is very similar to other UNIX debuggers such as the GNU debugger (GDB). The
VCS software UCLI can be used to halt simulations at user-defined break points, force
registers with values, and display register values.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 3: Synopsys VCS and VCS MX Support
Simulating Designs that Include Transceivers
3–9
Enable the non-graphical capability by using the +ucli run-time option. Use the VCS
software UCLI to debug your Altera FPGA design by typing the following command:
vcs -R <testbench>.v <design name>.vo -v <path to Quartus II \
installation> \eda\sim_lib\<device family>_atoms.v +compsdf +ucli r
The +ucli command takes an optional number argument that specifies the level of
debugging capability. As the optional debugging capability is increased, there is an
increase in simulation time.
f
For more information about the +ucli options, refer to the VCS User Guide included
in the VCS software installation.
For the design examples to run gate-level timing simulations in VHDL or Verilog
HDL language, refer to Synopsys VCS Simulation Design Example.
Simulating Designs that Include Transceivers
If your design includes Arria®, Arria II, Cyclone® IV, HardCopy® IV, Stratix®, Stratix II,
Stratix IV, or Stratix V transceivers, you must compile additional library files to
perform functional or gate-level timing simulations.
For high-speed simulation, you must select ps in the Resolution list for your
simulator resolutions (Design tab of the Start Simulation dialog box). If you choose
slower than ps, the high-speed simulation might fail.
f
If your design contains PCI Express hard IP, refer to the “Simulate the Design” section
in the PCI Express Compiler User Guide.
Functional Simulation for Stratix GX Devices
To perform a functional simulation of your design that instantiates the ALTGXB
megafunction, enabling the gigabit transceiver block gigabit transceiver block on
Stratix GX devices, compile the stratixgx_mf model file into the altgxb library.
1
The stratixgx_mf model file references the lpm and sgate libraries. You must create
these libraries to perform a simulation.
Compiling Library Files for Functional Simulation in Verilog HDL
To compile the libraries necessary for functional simulation of a Verilog HDL design
targeting a Stratix GX device, at the VCS command prompt, type the following
command:
vcs -R <testbench>.v <design files>.v -v stratixgx_mf.v -v sgate.v \
-v 220model.v -v altera_mf.v r
Gate-Level Timing Simulation for Stratix GX Devices
Perform a gate-level timing simulation of your design that includes a Stratix GX
transceiver by compiling the stratixgx_atoms and stratixgx_hssi_atoms model files
into the stratixgx and stratixgx_gxb libraries, respectively.
1
© July 2010
The stratixgx_hssi_atoms model file references the lpm and sgate libraries. You must
create these libraries to perform a simulation.
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
3–10
Chapter 3: Synopsys VCS and VCS MX Support
Simulating Designs that Include Transceivers
Compiling Library Files for Gate-Level Timing Simulation in Verilog HDL
To compile the libraries necessary for timing simulation of a Verilog HDL design
targeting a Stratix GX device, at the VCS command prompt, type the following
command:
vcs -R <testbench>.v <gate-level netlist>.vo -v stratixgx_atoms.v -v \
stratixgx_hssi_atoms.v -v sgate.v -v 220model.v -v altera_mf.v +transport_int_delays \
+pulse_int_e/0 +pulse_int_r/0 +transport_path_delays +pulse_e/0 +pulse_r/0 r
Functional Simulation for Stratix II GX Devices
Functional simulation for Stratix II GX devices is similar to functional simulation for
Arria GX devices. To simulate the transceiver in Arria GX devices, you only have to
replace the stratixiigx_hssi model file with the arriagx_hssi model file.
To perform a functional simulation of your design that instantiates the ALT2GXB
megafunction, enabling the gigabit transceiver block on Stratix II GX devices, compile
the stratixiigx_hssi model file into the stratixiigx_hssi library.
1
The stratixiigx_hssi_atoms model file references the lpm and sgate libraries. You
must create these libraries to perform a simulation.
Generate a functional simulation netlist by turning on Generate Simulation Model in
the Simulation Library in the ALT2GXB MegaWizard™ Plug-In Manager. The
<alt2gxb entity name>.vho file or <alt2gxb module name>.vo file is generated in the
current project directory.
1
The ALT2GXB functional simulation library file generated by the Quartus II software
references stratixiigx_hssi wysiwyg atoms.
Compiling Library Files for Functional Simulation in Verilog HDL
To compile the libraries necessary for functional simulation of a Verilog HDL design
targeting a Stratix II GX device, type the following command at the VCS command
prompt:
vcs -R <testbench>.v <alt2gxb simulation netlist>.vo -v \
stratixgx_hssi_atoms.v -v sgate.v -v 220model.v -v altera_mf.v r
Gate-Level Timing Simulation for Stratix II GX Devices
Gate-level timing simulation for Stratix II GX devices is similar to gate-level timing
simulation for Arria GX devices. To simulate the transceiver in Arria GX devices, you
only have to replace the stratixiigx_hssi model file with the arriagx_hssi model file.
To perform a gate-level timing simulation of your design that includes a Stratix II GX
transceiver, compile stratixiigx_atoms and stratixiigx_hssi_atoms into the stratixiigx
and stratixiigx_hssi libraries, respectively.
1
The stratixiigx_hssi_atoms model file references the lpm and sgate libraries. You
must create these libraries to perform a simulation.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 3: Synopsys VCS and VCS MX Support
Simulating Designs that Include Transceivers
3–11
Compiling Library Files for Gate-Level Timing Simulation in Verilog HDL
To compile the libraries necessary for timing simulation of a Verilog HDL design
targeting a Stratix II GX device, type the following command at the VCS command
prompt:
vcs -R <testbench>.v <gate-level netlist>.vo -v stratixiigx_atoms.v -v \
stratixiigx_hssi_atoms.v -v sgate.v -v 220model.v -v altera_mf.v \
+transport_int_delays +pulse_int_e/0 +pulse_int_r/0 \
+transport_path_delays +pulse_e/0 +pulse_r/0 r
Functional Simulation for Stratix IV GX Devices
Functional simulation for Stratix IV devices is similar to functional simulation for
Arria II, Cyclone IV, and HardCopy IV devices. To simulate transceivers in Arria II,
Cyclone IV, and HardCopy IV devices, you only have to replace the stratixiv_hssi
model file with the arriaii_hssi, cycloneiv_hssi, and hardcopyiv_hssi model files,
respectively.
To perform a functional simulation of your design that instantiates the ALTGX
megafunction, enabling the gigabit transceiver block on Stratix IV devices, compile
the stratixiv_hssi model file into the stratixiv_hssi library,
The stratixiv_hssi_atoms model file references the lpm and sgate libraries. You must
create these libraries to perform a simulation.
Compiling Library Files for Functional Simulation in Verilog HDL
To compile the libraries necessary for functional simulation of a Verilog HDL design
targeting a Stratix IV device, type the following command at the VCS command
prompt:
vcs -R <testbench>.v <altgx>.v -v \ stratixiv_hssi_atoms.v -v sgate.v \
-v 220model.v -v altera_mf.v r
Gate-Level Timing Simulation for Stratix IV GX Devices
Gate-level timing simulation for Stratix IV devices is similar to gate-level timing
simulation for Arria II, Cyclone IV, and HardCopy IV devices. To simulate
transceivers in Arria II, Cyclone IV, and HardCopy IV devices, you only have to
replace the stratixiv_hssi model file with the arriaii_hssi, cycloneiv_hssi, and
hardcopyiv_hssi model files, respectively.
To perform a gate-level timing simulation of your design that includes a Stratix IV
transceiver, compile stratixiv_atoms and stratixiv_hssi_atoms into the stratixiv and
stratixiv_hssi libraries, respectively.
To perform a gate-level timing simulation of your design that includes a Stratix IV
transceiver, compile stratixiv_atoms and stratixiv_hssi_atoms into the stratixiv and
stratixiv_hssi libraries, respectively.
The stratixiv_hssi_atoms model file references the lpm and sgate libraries. You must
create these libraries to perform a simulation.
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
3–12
Chapter 3: Synopsys VCS and VCS MX Support
Simulating Designs that Include Transceivers
Compiling Library Files for Gate-Level Timing Simulation in Verilog HDL
To compile the libraries necessary for timing simulation of a Verilog HDL design
targeting a Stratix IV device, type the following command at the VCS command
prompt:
vcs -R <testbench>.v <gate-level netlist>.vo -v stratixiv_atoms.v \
-v stratixiv_hssi_atoms.v -v sgate.v -v 220model.v -v altera_mf.v \
+transport_int_delays +pulse_int_e/0 +pulse_int_r/0 \
+transport_path_delays +pulse_e/0 +pulse_r/0
Functional Simulation for Stratix V GX Devices
Functional simulation for Stratix V devices is similar to functional simulation for
Arria II, Cyclone IV, HardCopy IV, and Stratix IV devices. To simulate transceivers in
Arria II, Cyclone IV, HardCopy IV, and Stratix IV devices, you only have to replace the
stratixv_hssi model file with the arriaii_hssi, cycloneiv_hssi, hardcopyiv_hssi, and
stratixiv_hssi model files, respectively.
The stratixv_hssi_atoms model file references the lpm and sgate libraries. You must
compile these libraries to perform a simulation.
1
The transceiver module from the MegaWizard Plug-In Manager is created in
Interfaces/Transceiver PHY. Select Custom PHY.
Compiling Library Files for Functional Simulation
To compile the libraries necessary for functional simulation of a Verilog HDL or VHDL
design targeting a Stratix V device, type the following commands at the VCS command
prompt:
mkdir
mkdir
mkdir
mkdir
-p
-p
-p
-p
./stratixv r
./stratixv_pcie_hip r
./stratixv_hssi r
./work r
vlogan +v2k -work stratixv \
$QUARTUS_ROOTDIR/eda/sim_lib/synopsys/stratixv_atoms_ncrypt.v r
vlogan +v2k -work stratixv_hssi \
$QUARTUS_ROOTDIR/eda/sim_lib/synopsys/stratixv_hssi_atoms_ncrypt.v r
vlogan -sverilog -work stratixv_pcie_hip \
$QUARTUS_ROOTDIR/eda/sim_lib/synopsys/stratixv_pcie_hip_atoms_ncrypt.v r
vhdlan -work stratixv_hssi \
$QUARTUS_ROOTDIR/eda/sim_lib/stratixv_hssi_components.vhd r
vhdlan -work stratixv_hssi \
$QUARTUS_ROOTDIR/eda/sim_lib/stratixv_hssi_atoms.vhd r
vcs test r
./simv r
1
The PCIe files are required only if you are using the PCIe HIP.
1
For VHDL, you must compile the Verilog HDL files first.
1
In addition to the top-level variant wrapper, <variant>.v, you also get a simulation files
subdirectory, <variant>_sim/. All Verilog (.v) and SystemVerilog (.sv) files in the
simulation directory must also be compiled into the simulation project.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 3: Synopsys VCS and VCS MX Support
Transport Delays
3–13
Transport Delays
By default, the VCS software filters out all pulses that are shorter than the propagation
delay between primitives. Turning on the transport delay options in the VCS software
prevents the simulation tool from filtering out these pulses. Use the following options to
ensure that all signal pulses are seen in the simulation results.
+transport_path_delays
Use this option when the pulses in your simulation are shorter than the delay within a
gate-level primitive. You must include the +pulse_e/number and +pulse_r/number
options.
+transport_int_delays
Use this option when the pulses in your simulation are shorter than the interconnect
delay between gate-level primitives. You must include the +pulse_int_e/number and
+pulse_int_r/number options.
1
f
The +transport_path_delays and +transport_int_delays options are also used by
default in the NativeLink feature for gate-level timing simulation.
For more information about either of these options, refer to the VCS User Guide installed
with the VCS software.
The following VCS software command shows the command-line syntax to perform a
post-synthesis simulation with the device family library:
vcs -R <testbench>.v <gate-level netlist>.v -v <Altera device family library>.v \
+transport_int_delays +pulse_int_e/0 +pulse_int_r/0 +transport_path_delays \
+pulse_e/0 +pulse_r/0 r
Using NativeLink with the VCS or VCS MX Software
The NativeLink feature in the Quartus II software facilitates the seamless transfer of
information between the Quartus II software and EDA tools and allows you to run VCS
or VCS MX within the Quartus II software.
f
For more information, refer to the “Using the NativeLink Feature” section in the
Simulating Designs with EDA Tools chapter in volume 3 of the Quartus II Handbook.
Generating a Timing .vcd File for the PowerPlay Power Analyzer
To generate a timing Verilog Value Change Dump File (*.vcd) for PowerPlay, you must
first generate a VCD script in the Quartus II software, and then run the VCD script from
the VCS software. This timing .vcd file can then be used by PowerPlay for power
analysis.
To generate timing VCD scripts in the Quartus II software, perform the following steps:
1. In the Quartus II software, on the Assignments menu, click Settings. The Settings
dialog box appears.
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
3–14
Chapter 3: Synopsys VCS and VCS MX Support
Viewing a Waveform from a .vpd or .vcd File
2. In the Category list, under EDA Tool Settings, click Simulation. On the
Simulation page, in the Tool name list, select VCS and turn on the Generate
Value Change Dump (VCD) file script option.
3. To generate the VCD script file, perform a full compilation.
Perform the following steps to generate a timing .vcd file in the VCS software:
1. Before compiling and simulating your design, include the script in your testbench
file where the design under test (DUT) is instantiated:
include <revision_name>_dump_all_vcd_nodes.v r
1
Include the script within the testbench module block. If you include the
script outside of the testbench module block, syntax errors occur during
compilation.
2. Run the simulation using the VCS command as usual. Exit the VCS software when
the simulation is finished and the <revision_name>.vcd file is generated in the
simulation directory.
1
f
The .vcd file is not supported in the VCS MX software.
For more detailed information about using the timing .vcd file for power analysis,
refer to the PowerPlay Power Analysis chapter in volume 3 of the Quartus II Handbook.
Viewing a Waveform from a .vpd or .vcd File
A Virtual Panoramic Display (.vpd) file is automatically generated when your
simulation is finished. The .vpd file is not readable. It is used for generating the
waveform view through DVE. You can view your waveform result in DVE if you have
created a .vpd or .vcd file.
To view a waveform from a .vpd file through DVE, perform the following steps:
1. Type dve on a command line. The DVE dialog box appears.
2. On the File menu, click Open Database. The Open Database dialog box appears.
3. Browse to the directory that contains your .vpd file (for example, inter.vpd).
4. Double-click the .vpd file.
5. In the DVE dialog box, select the signals that you want to observe from the
Hierarchy.
6. On the Signal menu, click Add To Waves.
7. Click New Wave View. The waveform appears.
You cannot view a waveform from a .vcd file in DVE directly. The .vcd file must first
be converted to a .vpd file. To convert the file, perform the following steps:
1. Use the vcd2vpd command to convert the file. For example, type the following on
a command line:
vcd2vpd <example>.vcd <example>.vpd r
2. After you convert the .vcd file to a .vpd file, follow the procedures for viewing a
waveform from a .vpd file through DVE.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 3: Synopsys VCS and VCS MX Support
Scripting Support
3–15
You can also convert your .vpd file to a .vcd file by using the vpd2vcd command.
Scripting Support
You can run procedures and create settings described in this chapter in a Tcl script.
You can also run some procedures at a command prompt.
f
For more information about Tcl scripting, refer to the Tcl Scripting chapter in volume 2
of the Quartus II Handbook. For more information about command-line scripting, refer
to the Command-Line Scripting chapter in volume 2 of the Quartus II Handbook.
For detailed information about scripting command options, refer to the Qhelp utility.
To start the Qhelp utility, type the following command:
quartus_sh --qhelp r
Generating a Post-Synthesis Simulation Netlist for VCS
You can use the Quartus II software to generate a post-synthesis simulation netlist
with Tcl commands or with a command at a command prompt.
Tcl Commands
Type the following Tcl commands to generate a post-synthesis simulation netlist when
you compile your design or as part of a Tcl script that compiles your design:
set_global_assignment -name EDA_SIMULATION_TOOL "VCS" r
set_global_assignment –name EDA_GENERATE_FUNCTIONAL_NETLIST ON r
Command Prompt
Type the following command to generate a simulation output file for the VCS
software simulator; specify VHDL or Verilog HDL for the format:
quartus_eda <project name> --simulation=on --format=<format> \
--tool=vcs --functional r
Generating a Gate-Level Timing Simulation Netlist for VCS
You can use the Quartus II software to generate a gate-level timing simulation netlist
with Tcl commands or with a command at a command prompt.
Tcl Commands
Type the following Tcl command to generate a gate-level timing simulation netlist:
set_global_assignment -name EDA_SIMULATION_TOOL "VCS" r
Command Prompt
Type the following command to generate a simulation output file for the VCS
software simulator. Specify VHDL or Verilog HDL for the format.
quartus_eda <project name> --simulation=on --format=<format> --tool=vcs r
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
3–16
Chapter 3: Synopsys VCS and VCS MX Support
Conclusion
Conclusion
You can use the Synopsys VCS or VCS MX software in your Altera FPGA design flow
to easily and accurately perform functional simulations, post-synthesis simulations,
and gate-level functional timing simulations. The seamless integration of the
Quartus II software and VCS or VCS MX software make this simulation flow an ideal
method for fully verifying an FPGA design.
Document Revision History
Table 3–2 shows the revision history for this chapter.
Table 3–2. Document Revision History
Date
Version
July 2010
10.0.0
November 2009
March 2009
9.1.0
9.0.0
November 2008
8.1.0
Changes Made
■
Linked to Quartus II Help where appropriate
■
Added Stratix V simulation information
■
Minor text edits
■
Removed VirSim references
■
Removed Referenced Documents section
■
Removed NativeLink information and referenced new Simulating Designs with EDA
Tools chapter in volume 3 of the Quartus II Handbook
■
Added “RTL Functional Simulation for Stratix IV Devices” and “Gate-Level Timing
Simulation for Stratix IV Devices” sections
■
Minor text edits
■
Added support for Synopsys VCS MX software
■
Changed chapter title to “Synopsys VCS and VCS MX Support”
■
Major revision to “Compiling Libraries Using the EDA Simulation Library Compiler” on
page 4–2
■
Major revision to “RTL Functional Simulations” on page 4–2
■
Added Table 3–4 on page 3–10 and Table 3–5 on page 3–11
■
Added new section “Using DVE” on page 4–7
■
Added new section “Generating a Simulation Script from the EDA Netlist Writer” on
page 3–16
■
Added new section “Viewing a Waveform from a .vpd or .vcd File” on page 4–13
■
Added “Compile Libraries Using the EDA Simulation Library Compiler” on page 3–3
■
Added information about the --simlib_comp utility
■
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 10.0 Volume 3: Verification
© July 2010 Altera Corporation
4. Cadence NC-Sim Support
QII53003-10.0.0
This chapter describes the basic NC-Sim, NC-Verilog, and NC-VHDL functional,
post-synthesis, and gate-level timing simulations.
The Cadence Incisive verification platform includes NC-Sim, NC-Verilog, NC-VHDL,
Verilog HDL, and VHDL desktop simulators.
This chapter is a “getting started” guide to using the Cadence Incisive verification
platform in Altera® FPGA design flows. This chapter also describes the location of the
simulation libraries and how to automate simulations.
This chapter includes the following topics:
■
“Software Requirements”
■
“Simulation Flow Overview”
■
“Functional Simulation” on page 4–3
■
“Post-Synthesis Simulation” on page 4–7
■
“Gate-Level Timing Simulation” on page 4–8
■
“Simulating Designs that Include Transceivers” on page 4–10
■
“Using the NativeLink Feature with NC-Sim” on page 4–18
■
“Generating a Timing VCD File for the PowerPlay Power Analyzer” on page 4–18
■
“Viewing a Waveform from a .trn File” on page 4–19
■
“Scripting Support” on page 4–20
Software Requirements
To simulate your design using the NC-Sim software, you must first set up the Altera
libraries. These libraries are installed with the Quartus II software.
f
For more information about installing the software and directories created during the
Quartus II software installation, refer to the Altera Software Installation and Licensing
manual.
Simulation Flow Overview
The Incisive verification platform supports the following simulation flows:
© July 2010
■
Functional Simulation
■
Post-Synthesis Simulation
■
Gate-Level Timing Simulation
■
Using the NativeLink Feature with NC-Sim
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
4–2
Chapter 4: Cadence NC-Sim Support
Simulation Flow Overview
Functional simulation verifies the functionality of your design. When you perform a
functional simulation with Cadence Incisive simulators, you use your design files
(Verilog HDL or VHDL) and the models provided with the Quartus II software. These
Quartus II models are required if your design uses the library of parameterized
modules (LPM) functions or Altera-specific megafunctions. Refer to “Functional
Simulation” on page 4–3 for more information about how to perform this simulation.
A post-synthesis simulation verifies the functionality of a design after synthesis has
been performed. You can create a post-synthesis netlist (.vo or .vho) in the Quartus II
software and use this netlist to perform a post-synthesis simulation with the Incisive
simulator. Refer to “Post-Synthesis Simulation” on page 4–7 for more information
about how to perform this simulation.
After performing place-and-route, the Quartus II software generates a Verilog HDL
Output File (.vo) or VHDL Output File (.vho) and a Standard Delay Output file (.sdo)
for gate-level timing simulation. The netlist files map your design to
architecture-specific primitives. The .sdo file contains the delay information of each
architecture primitive and routing element specific to your design. Together, these
files provide an accurate simulation of your design with the selected Altera FPGA
architecture. Refer to “Gate-Level Timing Simulation” on page 4–8 for more
information about how to perform this simulation.
Operation Modes
You can use either the GUI mode or the command-line mode to simulate your design
in the NC simulators.
To start the Incisive simulators in GUI mode, type the following command at a
command prompt:
nclaunch r
To simulate in command-line mode, use the programs shown in Table 4–1.
Table 4–1. Command-Line Programs
Program
Function
ncvlog or
ncvhdl
NC-Verilog (ncvlog) compiles your Verilog HDL code into a Verilog Syntax Tree (.vst) file. ncvlog also performs
syntax and static semantics checks.
NC-VHDL (ncvhdl) compiles your VHDL code into a VHDL Syntax Tree (.ast) file. ncvhdl also performs syntax
and static semantics checks.
ncelab
NC-Elab (ncelab) elaborates the design. ncelab constructs the design hierarchy and establishes signal
connectivity. This program also generates a Signature File (.sig) and a Simulation SnapShot File (.sss).
ncsim
NC-Sim (ncsim) performs mixed-language simulation. This program is the simulation kernel that performs
event scheduling and executes the simulation code.
Quartus II Software and NC Simulation Flow Overview
This section provides an overview of the Quartus II software and Cadence NC
simulation flow. More detailed information is provided in “Functional Simulation” on
page 4–3, “Post-Synthesis Simulation” on page 4–7, and “Gate-Level Timing
Simulation” on page 4–8.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 4: Cadence NC-Sim Support
Functional Simulation
4–3
For high-speed simulation, you must select ps in the Resolution list for your
simulator resolutions (Design tab of the Start Simulation dialog box). If you choose
slower than ps, the high-speed simulation might fail.
Complete the following tasks:
1. Create user libraries.
Create a file that maps logical library names to their physical locations. These
library mappings include your working directory and any design-specific
libraries; for example, Altera LPM functions or megafunctions.
2. Compile source code and testbenches.
Compile your design files at the command-line using ncvlog (Verilog HDL files)
or ncvhdl (VHDL files) or, on the Tools menu, click Verilog Compiler or VHDL
Compiler in NCLaunch. During compilation, the NC software performs syntax
and static semantic checks. If no errors are found, compilation produces an
internal representation for each HDL design unit in the source files. By default,
these intermediate objects are stored in a single, packed, library database file in
your working directory.
3. Elaborate your design.
Before you can simulate your model, you must define the design hierarchy in a
process called “elaboration”. Use ncelab in command-line mode or, on the Tools
menu in NCLaunch, click Elaborator.
4. Add signals to your waveform.
Specify which signals to view in your waveform using a simulation history
manager (SHM) database.
5. Simulate your design.
Run the simulator with the ncsim program (command-line mode) or by clicking
Run in the SimVision Console window.
Compiling Libraries Using the EDA Simulation Library Compiler
The EDA Simulation Library Compiler compiles Verilog HDL and VHDL simulation
libraries for all Altera devices and supported third-party simulators. You can compile
all libraries required by functional and gate-level simulation with this tool.
f
For more information about this tool, refer to the “EDA Simulation Library Compiler”
section in the Simulating Designs with EDA Tools chapter in volume 3 of the Quartus II
Handbook.
Functional Simulation
The following sections provide detailed instructions for performing functional
simulation using the Quartus II software and the Cadence Incisive verification
platform tools.
For the Altera Behavioral Simulation Models, refer to Altera Functional Simulation
Libraries in Quartus II Help.
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
4–4
Chapter 4: Cadence NC-Sim Support
Functional Simulation
Creating Libraries
To create libraries, perform the following steps:
1. Create a directory for the work library and any other altera libraries you require by
typing the following command at a command prompt:
mkdir <library name> r
Examples:
mkdir worklib r
mkdir altera_mf r
2. Using a text editor, create a cds.lib file and add the following line to it:
DEFINE <library name> <physical directory path>
Examples:
DEFINE worklib ./worklib
DEFINE altera_mf ./altera_mf
f
For information about creating a cds.lib file in GUI mode, refer to Performing a
Functional Simulation with the NCSim Software in Quartus II Help.
For VHDL Designs
If you are targeting a Stratix V device, compile the following files in the
quartus/eda/sim_lib/cadence directory:
stratixv_atoms_ncrypt.v
stratixv_hssi_atoms_ncrypt.v
stratixv_pcie_hip_atoms_ncrypt.v
These files contain IEEE encrypted Verilog models suitable for VHDL/Verilog
co-simulation. You need a co-simulation license from Cadence to use these models in
VHDL.
1
Compile these encrypted Verilog files before you compile any VHDL files.
1
Compile stratixv_pcie_hip_atoms_ncrypt.v with the SystemVerilog option.
Also, compile the following files in the quartus/eda/sim_lib directory:
stratixv_atoms.vhd
stratixv_components.vhd
stratixv_hssi_components.vhd
stratixv_pcie_components.vhd
stratixv_hssi_atoms.vhd
stratixv_pcie_hip_atoms.vhd
1
The PCIe® files are required only if you are using the PCIe HIP.
For Verilog HDL Designs
If you are targeting a Stratix V device, compile the following files in the
<quartus/eda/sim_lib/cadence directory:
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 4: Cadence NC-Sim Support
Functional Simulation
4–5
stratixv_atoms_ncrypt.v
stratixv_hssi_atoms_ncrypt.v
stratixv_pcie_hip_atoms_ncrypt.v
These files contain IEEE encrypted Verilog models.
1
Compile stratixv_pcie_hip_atoms.v with the SystemVerilog option.
Also, compile the following files in the quartus/eda/sim_lib directory:
stratixv_atoms.v
stratixv_hssi_atoms.v
stratixv_pcie_hip_atoms.v
1
The PCIe files are required only if you are using the PCIe HIP.
Compiling Source Code
To compile from your source code from the command line, type one of the following
commands:
■
Verilog HDL:
ncvlog <options> -work <library name> <design files> r
■
VHDL:
ncvhdl <options> -work <library name> <design files> r
You must create a work library before compiling your design and testbench. If your
design uses LPM, Altera megafunctions, or Altera primitives, you must also compile
the Altera-provided functional models. The commands in Example 4–1 and
Example 4–2 show an example of each.
Example 4–1. Compile in Verilog HDL
ncvlog
ncvlog
ncvlog
ncvlog
ncvlog
-WORK
-WORK
-WORK
-WORK
-WORK
lpm 220model.v
altera_mf altera_mf.v
altera altera_primitives.v
altera altera_primitives.v
work toplevel.v testbench.v
Example 4–2. Compile in VHDL
ncvhdl
ncvhdl
ncvhdl
ncvhdl
ncvhdl
ncvhdl
ncvhdl
f
© July 2010
-V93
-V93
-V93
-V93
-V93
-V93
-V93
-WORK
-WORK
-WORK
-WORK
-WORK
-WORK
-WORK
lpm 220pack.vhd
lpm 220model.vhd
altera_mf altera_mf_components.vhd
altera_mf altera_mf.vhd
altera altera_primitives_components.vhd
altera altera_primitives.vhd
work toplevel.vhd testbench.vhd
For information about compiling in GUI mode, refer to Performing a Functional
Simulation with the NCSim Software in Quartus II Help.
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
4–6
Chapter 4: Cadence NC-Sim Support
Functional Simulation
Elaborating Your Design
Before you can simulate your design, you must define the design hierarchy in a
process called elaboration. The Incisive simulator elaborates your design with the
language-independent ncelab program. The ncelab program constructs a design
hierarchy based on the design’s instantiation and configuration information,
establishes signal connectivity, and computes initial values for all objects in the
design. The elaborated design hierarchy is stored in a simulation snapshot, which is
the representation of your design that the simulator uses to run the simulation. The
snapshot is stored in the library database file, along with the other intermediate
objects generated by the compiler and elaborator.
To elaborate your Verilog HDL or VHDL design from the command line, type the
following command:
ncelab [options][<library>.<testbench module name]
Example:
ncelab -access +rwc work.testbench_module
Adding the option -access +rwc allows signals to be viewed in the Waveform
window.
If your design includes high-speed signals, you might have to add the following pulse
reject options with the ncelab command:
ncelab -access +rwc work.testbench_module -PULSE_R 0 -PULSE_INT_R 0
f
For more information about the pulse reject options, refer to the SDF Annotate Guide
from Cadence.
f
For information about elaborating your design in GUI mode, refer to Performing a
Functional Simulation with the NCSim Software in Quartus II Help.
Simulating Your Design
After you have compiled and elaborated your design, you can simulate it using
ncsim. The ncsim program loads the file, or snapshot, generated by ncelab as its
primary input and then loads other intermediate objects referenced by the snapshot. If
you enable interactive debugging, ncsim can also load HDL source files and script
files. The simulation output is controlled by the model or debugger. The output can
include result files generated by the model, the SHM database, or the .vcd file.
To perform functional simulation of your Verilog HDL or VHDL design at the
command line, type the following command:
ncsim [options][<library>.<testbench module name>]
Example:
ncsim -gui work.testbench_module
Adding the option -gui opens the SimVision window for running your simulation.
f
For information about performing a functional simulation in GUI mode, refer to
Performing a Functional Simulation with the NCSim Software in Quartus II Help.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 4: Cadence NC-Sim Support
Post-Synthesis Simulation
4–7
Post-Synthesis Simulation
The following sections provide detailed instructions for performing post-synthesis
simulation with the Incisive platform software and output files and simulation files
from the Quartus II software.
1
f
You cannot perform post-synthesis or post-fit simulation if you are targeting the
Stratix V device family.
For a list of the gate-level simulation models, refer to Altera Post-Fit Libraries in
Quartus II Help.
Quartus II Simulation Output Files
After performing synthesis with either a third-party synthesis tool or with Quartus II
integrated synthesis, you must generate a simulation netlist for functional
simulations.
f
To generate a simulation netlist for functional simulation, refer to the “Generating
Post-Synthesis Netlist Files” section in the Simulating Designs with EDA Tools chapter
in volume 3 of the Quartus II Handbook.
Creating Libraries
Create the following libraries for your simulation:
■
Work library
■
Device family library targeting your design targets using the following files in the
<path to Quartus II installation>/eda/sim_lib directory:
■
<device_family>_atoms.v
■
<device_family>_atoms.vhd
■
<device_family>_components.vhd
Refer to “Creating Libraries” on page 4–4 for instructions about creating libraries.
Compiling Project Files and Libraries
Compile the project files and libraries into your work directory using the ncvlog,
ncvhdl programs, or the GUI. Include the following files:
■
Testbench file
■
The Quartus II software functional output netlist file (.vo file or .vho file)
■
Atom library file for the device family <device family>_atoms.<v|vhd>
■
For VHDL, <device family>_components.vhd
Refer to “Compiling Source Code” on page 4–5 for instructions about compiling.
Elaborating Your Design
Elaborate your design using the ncelab program as described in “Elaborating Your
Design” on page 4–6.
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
4–8
Chapter 4: Cadence NC-Sim Support
Gate-Level Timing Simulation
Simulating Your Design
Simulate your design using the ncsim program as described in “Simulating Your
Design” on page 4–6.
Gate-Level Timing Simulation
The following sections provide detailed instructions for performing a timing
simulation using the Quartus II output files, simulation libraries, and Cadence NC
tools.
1
You cannot perform post-synthesis or post-fit simulations if you are targeting the
Stratix V device family.
f
For a list of the gate-level simulation models, refer to Altera Post-Fit Libraries in
Quartus II Help.
f
For details about how to perform gate-level timing simulation using the Quartus II
software and the Cadence NC-Sim software, refer to Performing a Timing Simulation
with the NCSim Software in Quartus II Help.
Generating a Gate-Level Timing Simulation Netlist
To perform a gate-level timing simulation, your design should provide the NC-Sim
software with information about how the design was placed into device-specific
architectural blocks. The Quartus II software provides this information in the form of
a .vo file for Verilog HDL designs and a .vho file for VHDL designs. The
accompanying timing information is stored in the .sdo file, which annotates the delay
for the elements found in the .vo file or .vho file.
f
To generate the .vo or .vho file and the .sdo file, refer to the “Generating Gate-Level
Timing Simulation Netlist Files” section in the Simulating Designs with EDA Tools
chapter in volume 3 of the Quartus II Handbook.
Disabling Timing Violation on Registers
In certain situations, the timing violations can be ignored and you can disable the
timing violation on registers. For example, timing violations that occur in internal
synchronization registers used for asynchronous clock-domain crossing can be
ignored and disabled.
By default, the x_on_violation_option logic option is On, which means the
simulation shows “X” whenever a timing violation occurs. To disable showing the
timing violation on certain registers, you can set the x_on_violation_option logic
option to Off for those registers. The following command is the Quartus II Tcl
command to disable timing violation on registers.
set_instance_assignment -name X_ON_VIOLATION_OPTION OFF –to \
<register_name>
This Tcl command is also stored in the .qsf file.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 4: Cadence NC-Sim Support
Gate-Level Timing Simulation
4–9
Creating Libraries
Create the following libraries for your simulation:
■
Work library
■
Device family libraries targeting using the following files in the <path to Quartus II
installation>/eda/sim_lib directory:
■
<device_family>_atoms.v
■
<device_family>_atoms.vhd
■
<device_family>_components.vhd
For instructions about creating libraries, refer to “Creating Libraries” on page 4–4.
Compiling Project Files and Libraries
Compile the project files and libraries into your work directory with the ncvlog or
ncvhdl programs or the GUI. Include the following files:
■
Testbench file
■
The Quartus II software functional output netlist file (.vo file or .vho file)
■
Atom library file for the device family <device family>_atoms.<v|vhd>
■
For VHDL, <device family>_components.vhd
For instructions about compiling, refer to “Compiling Source Code” on page 4–5.
Elaborating Your Design
When performing elaboration with the Quartus II-generated Verilog HDL netlist file,
the .sdo file is read automatically. The ncelab executable recognizes the embedded
system task $sdf_annotate and automatically compiles and annotates the .sdo file
(runs ncsdfc automatically).
1
The .sdo file should be located in the same directory where you perform an
elaboration or simulation, because the $sdf_annotate task references the .sdo file
without using a full path. If you are starting an elaboration or simulation from a
different directory, you can either comment out the $sdf_annotate and annotate
the .sdo file with the GUI, or add the full path of the .sdo file.
Refer to “Elaborating Your Design” on page 4–6 for elaboration instructions.
VHDL netlist files do not contain system task calls to locate your .sdf file; therefore,
you must compile the Standard .sdo file manually. For information about compiling
the .sdo file, refer to “Compiling the .sdo File (VHDL Only) in Command-Line Mode”
and “Compiling the .sdo File (VHDL Only) in GUI Mode”.
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
4–10
Chapter 4: Cadence NC-Sim Support
Simulating Designs that Include Transceivers
Compiling the .sdo File (VHDL Only) in Command-Line Mode
To annotate the .sdo file timing data from the command line, perform the following
steps:
1. Compile the .sdo file using the ncsdfc program by typing the following command
at the command prompt:
ncsdfc <project name>_vhd.sdo –output <output name> r
The ncsdfc program generates an <output name>.sdf.X compiled .sdo file.
1
If you do not specify an output name, ncsdfc uses <project name>.sdo.X.
2. Specify the compiled .sdf file for the project by adding the following command to
an ASCII SDF command file for the project:
COMPILED_SDF_FILE = "<project name>.sdf.X" SCOPE = <instance path>
Example 4–3 shows an example of an SDF command file.
Example 4–3. SDF Command File
// SDF command file sdf_file
COMPILED_SDF_FILE = "lpm_ram_dp_test_vhd.sdo.X",
SCOPE = :tb,
MTM_CONTROL = "TYPICAL",
SCALE_FACTORS = "1.0:1.0:1.0",
SCALE_TYPE = "FROM_MTM";
After you compile the .sdf file, type the following command to elaborate the design:
ncelab worklib.<project name>:entity –SDF_CMD_FILE <SDF Command File> r
Compiling the .sdo File (VHDL Only) in GUI Mode
f
To compile the .sdo file in GUI mode, refer to Performing a Timing Simulation with the
NCSim Software in Quartus II Help.
Simulating Your Design
Simulate your design using the ncsim program as described in “Simulating Your
Design” on page 4–6.
f
For the design examples to run gate-level timing simulation, refer to the
Cadence NC-Sim Simulation Design Example web page.
Simulating Designs that Include Transceivers
If your design includes Arria®, Arria II, Cyclone IV, HardCopy IV, Stratix, Stratix II, or
Stratix IV transceivers, you must compile additional library files to perform functional
or gate-level timing simulations.
For high-speed simulation, you must select ps in the Resolution list for your
simulator resolutions (Design tab of the Start Simulation dialog box). If you choose
slower than ps, the high-speed simulation might fail.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 4: Cadence NC-Sim Support
Simulating Designs that Include Transceivers
f
4–11
If your design contains PCI Express® hard IP, refer to the “Simulate the Design”
section in the PCI Express Compiler User Guide.
Functional Simulation for Stratix GX Devices
To perform a functional simulation of your design that instantiates the ALTGXB
megafunction, enabling the gigabit transceiver block (GXB) on Stratix GX devices,
compile the stratixgx_mf model file into the altgxb library.
1
The stratixgx_mf model file references the lpm and sgate libraries. You must create
these libraries to perform a simulation.
Compiling Library Files for Functional Simulation in VHDL
To compile the libraries necessary for functional simulation of a VHDL design
targeting a Stratix GX device, type the commands shown in Example 4–4 at the
NC-Sim command prompt.
Example 4–4. Compile Libraries Commands for Functional Simulation in VHDL
ncvhdl -work lpm 220pack.vhd 220model.vhd
ncvhdl -work altera_mf altera_mf_components.vhd altera_mf.vhd
ncvhdl -work sgate sgate_pack.vhd sgate.vhd
ncvhdl -work altgxb stratixgx_mf.vhd stratixgx_mf_components.vhd
ncsim work.<my design>
Compiling Library Files for Functional Simulation in Verilog HDL
To compile the libraries necessary for a functional simulation of a Verilog HDL design
targeting a Stratix GX device, type the commands shown in Example 4–5 at the
NC-Sim command prompt.
Example 4–5. Compile Libraries Commands for Functional Simulation in Verilog HDL
ncvlog -work lpm 220model.v
ncvlog -work altera_mf altera_mf.v
ncvlog -work sgate sgate.v
ncvlog -work altgxb stratixgx_mf.v
ncsim work.<my design>
Gate-Level Timing Simulation for Stratix GX Devices
To perform a gate-level timing simulation of your design that includes a Stratix GX
transceiver, compile the stratixgx_atoms and stratixgx_hssi_atoms model files into
the stratixgx and stratixgx_gxb libraries, respectively.
1
You must create these libraries to perform a simulation because the
stratixgx_hssi_atoms model file references the lpm and sgate libraries.
Compiling Library Files for Gate-Level Timing Simulation in VHDL
To compile the libraries necessary for a timing simulation of a VHDL design targeting
a Stratix GX device, type the commands shown in Example 4–6 at the NC-Sim
command prompt.
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
4–12
Chapter 4: Cadence NC-Sim Support
Simulating Designs that Include Transceivers
Example 4–6. Compile Libraries Commands for Timing Simulation in VHDL
ncvhdl -work lpm 220pack.vhd 220model.vhd
ncvhdl -work altera_mf altera_mf_components.vhd altera_mf.vhd
ncvhdl -work sgate sgate_pack.vhd sgate.vhd
ncvhdl -work stratixgx stratixgx_atoms.vhd stratixgx_components.vhd
ncvhdl -work stratixgx_gxb stratixgx_hssi_atoms.vhd \
stratixgx_hssi_components.vhd
ncelab work.<my design> -TIMESCALE 1ps/1ps -PULSE_R 0 -PULSE_INT_R 0
Compiling Library Files for Gate-Level Timing Simulation in Verilog HDL
To compile the libraries necessary for a timing simulation of a Verilog HDL design
targeting a Stratix GX device, type the commands shown in Example 4–7 at the
NC-Sim command prompt.
Example 4–7. Compile Libraries Commands for Timing Simulation in Verilog HDL
ncvlog
ncvlog
ncvlog
ncvlog
ncvlog
ncelab
-work lpm 220model.v
-work altera_mf altera_mf.v
-work sgate sgate.v
-work stratixgx stratixgx_atoms.v
-work stratixgx_gxb stratixgx_hssi_atoms.v
work.<my design> -TIMESCALE 1ps/1ps -PULSE_R 0 -PULSE_INT_R 0
Functional Simulation for Stratix II GX Devices
Functional simulation of Stratix II GX devices is similar to functional simulation of
Arria GX devices. Example 4–9 on page 4–13 and “Compile Libraries Commands for
Functional Simulation in Verilog HDL” on page 4–13 show only the functional
simulation for designs that include transceivers in Stratix II GX devices. To simulate
transceivers in Arria GX devices, replace the stratixiigx_hssi model file with the
arriagx_hssi model file.
To perform a functional simulation of your design that instantiates the ALT2GXB
megafunction, edit your cds.lib file so all of the libraries point to the work library, and
compile the stratixiigx_hssi model file into the stratixiigx_hssi library. When
compiling the library files, you can safely ignore the following warning message:
"Multiple logical libraries mapped to a single location"
Example 4–8 shows the cds.lib file.
Example 4–8. cds.lib File
SOFTINCLUDE ${CDS_INST_DIR}/tools/inca/files/cdsvhdl.lib
SOFTINCLUDE ${CDS_INST_DIR}/tools/inca/files/cdsvlog.lib
DEFINE work ./ncsim_work
DEFINE stratixiigx_hssi ./ncsim_work
DEFINE stratixiigx ./ncsim_work
DEFINE lpm ./ncsim_work
DEFINE sgate ./ncsim_work
1
The stratixiigx_hssi_atoms model file references the lpm and sgate libraries. You
must create these libraries to perform a simulation.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 4: Cadence NC-Sim Support
Simulating Designs that Include Transceivers
4–13
Generate a functional simulation netlist by turning on Create a simulation library for
this design in the last page of the ALT2GXB MegaWizard Plug-In Manager. The
<alt2gxb entity name>.vho or <alt2gxb module name>.vo is generated in the current
project directory.
1
The ALT2GXB functional simulation library file generated by the Quartus II software
references stratixiigx_hssi WYSIWYG atoms.
Compiling Library Files for Functional Simulation in VHDL
To compile the libraries necessary for functional simulation of a VHDL design
targeting a Stratix II GX device, type the commands shown in Example 4–9 at the
NC-Sim command prompt.
Example 4–9. Compile Libraries Commands for Functional Simulation in VHDL
ncvhdl -work lpm 220pack.vhd 220model.vhd
ncvhdl -work altera_mf altera_mf_components.vhd altera_mf.vhd
ncvhdl -work sgate sgate_pack.vhd sgate.vhd
ncvhdl -work stratixiigx_hssi stratixiigx_hssi_components.vhd \
stratixiigx_hssi_atoms.vhd
ncvhdl -work work <alt2gxb entity name>.vho
ncelab work.<my design>
Compiling Library Files for Functional Simulation in Verilog HDL
To compile the libraries necessary for functional simulation of a Verilog HDL design
targeting a Stratix II GX device, type the commands shown in Example 4–10 at the
NC-Sim command prompt.
Example 4–10. Compile Libraries Commands for Functional Simulation in Verilog HDL
ncvlog
ncvlog
ncvlog
ncvlog
ncvlog
ncelab
-work lpm 220model.v
-work altera_mf altera_mf.v
-work sgate sgate.v
-work stratixiigx_hssi stratixiigx_hssi_atoms.v
-work work <alt2gxb module name>.vo
work.<my design>
Gate-Level Timing Simulation for Stratix II GX Devices
Stratix II GX functional simulation is similar to Arria GX functional simulation.
Example 4–11 on page 4–14 and Example 4–12 on page 4–14 show only the gate-level
timing simulation for designs that include transceivers in Stratix II GX. To simulate
transceivers in Arria GX, replace the stratixiigx_hssi model file with the arriagx_hssi
model file.
To perform a post-fit timing simulation of your design that includes the ALT2GXB
megafunction, edit your cds.lib file so that all the libraries point to the work library
and compile stratixiigx_atoms and stratixiigx_hssi_atoms into the
stratixiigx and stratixiigx_hssi libraries, respectively. When compiling the library
files, you can safely ignore the following warning message:
"Multiple logical libraries mapped to a single location"
For an example of a cds.lib file, refer to “Functional Simulation for Stratix II GX
Devices” on page 4–12.
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
4–14
Chapter 4: Cadence NC-Sim Support
Simulating Designs that Include Transceivers
1
The stratixiigx_hssi_atoms model file references the lpm and sgate libraries. You
must create these libraries to perform a simulation.
Compiling Library Files for Gate-Level Timing Simulation in VHDL
To compile the libraries necessary for timing simulation of a VHDL design targeting a
Stratix II GX device, type the commands shown in Example 4–11 at the NC-Sim
command prompt.
Example 4–11. Compile Libraries Commands for Timing Simulation in VHDL
ncvhdl -work lpm 220pack.vhd 220model.vhd
ncvhdl -work altera_mf altera_mf_components.vhd altera_mf.vhd
ncvhdl -work sgate sgate_pack.vhd sgate.vhd
ncvhdl -work stratixiigx stratixiigx_atoms.vhd \
stratixiigx_components.vhd
ncvhdl -work stratixiigx_hssi stratixiigx_hssi_components.vhd \
stratixiigx_hssi_atoms.vhd
ncvhdl -work work <alt2gxb>.vho
ncelab work.<my design> -TIMESCALE 1ps/1ps -PULSE_R 0 -PULSE_INT_R 0
Compiling Library Files for Gate-Level Timing Simulation in Verilog HDL
To compile the libraries necessary for timing simulation of a Verilog HDL design
targeting a Stratix II GX device, type the commands shown in Example 4–12 at the
NC-Sim command prompt.
Example 4–12. Compile Libraries Commands for Timing Simulation in Verilog HDL
ncvlog
ncvlog
ncvlog
ncvlog
ncvlog
ncelab
-work lpm 220model.v
-work altera_mf altera_mf.v
-work sgate sgate.v
-work stratixiigx stratixiigx_atoms.v
-work stratixiigx_hssi stratixiigx_hssi_atoms.v
work.<my design> -TIMESCALE 1ps/1ps -PULSE_R 0 -PULSE_INT_R 0
Functional Simulation for Stratix IV GX Devices
Functional simulation for Stratix IV devices is similar to functional simulation for
Arria II, Cyclone IV, and HardCopy IV devices. Example 4–14 shows only the
functional simulation for designs that include transceivers in Stratix IV devices. To
simulate transceivers in Arria II, Cyclone IV, and HardCopy IV devices, replace the
stratixiv_hssi model file with the arriaii_hssi, cycloneiv_hssi, and hardcopyiv_hssi
model files, respectively.
To perform a functional simulation of your design that instantiates the ALTGX
megafunction, edit your cds.lib file so that all of the libraries point to the work library,
and compile the stratixiv_hssi model file into the stratixiv_hssi library.
When compiling the library files, you can safely ignore the following warning
message:
"Multiple logical libraries mapped to a single location"
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 4: Cadence NC-Sim Support
Simulating Designs that Include Transceivers
4–15
Example 4–13 shows the cds.lib file.
Example 4–13. cds.lib File
SOFTINCLUDE ${CDS_INST_DIR}/tools/inca/files/cdsvhdl.lib
SOFTINCLUDE ${CDS_INST_DIR}/tools/inca/files/cdsvlog.lib
DEFINE work ./ncsim_work
DEFINE stratixiv_hssi ./ncsim_work
DEFINE stratixiv ./ncsim_work
DEFINE lpm ./ncsim_work
DEFINE sgate ./ncsim_work
The stratixiv_hssi_atoms model file references the lpm and sgate libraries. You must
create these libraries to perform a simulation.
Compiling Library Files for Functional Simulation in VHDL
To compile the libraries necessary for functional simulation of a VHDL design
targeting a Stratix IV device, type the commands shown in Example 4–14 at the
NC-Sim command prompt.
Example 4–14. Compile Libraries Commands for Functional Simulation in VHDL
ncvhdl -work lpm 220pack.vhd 220model.vhd
ncvhdl -work altera_mf altera_mf_components.vhd altera_mf.vhd
ncvhdl -work sgate sgate_pack.vhd sgate.vhd
ncvhdl -work stratixiv_hssi stratixiv_hssi_components.vhd \
stratixiv_hssi_atoms.vhd
ncvhdl -work work <altgx entity name>.vhd
ncelab work.<my design>
Compiling Library Files for Functional Simulation in Verilog HDL
To compile the libraries necessary for functional simulation of a Verilog HDL design
targeting a Stratix IV device, type the commands shown in Example 4–15 at the
NC-Sim command prompt.
Example 4–15. Compile Libraries Commands for Functional Simulation in Verilog HDL
ncvlog
ncvlog
ncvlog
ncvlog
ncvlog
ncelab
-work lpm 220model.v
-work altera_mf altera_mf.v
-work sgate sgate.v
-work stratixiv_hssi stratixiv_hssi_atoms.v
-work work <altgx module name>.v
work.<my design>
Gate-Level Timing Simulation for Stratix IV GX Devices
Stratix IV gate-level timing simulation is similar to Arria II gate-level timing
simulation.
Example 4–16 and Example 4–17 show only the gate-level timing simulation for
designs that include transceivers in Stratix IV devices. To simulate transceivers in
Arria II, Cyclone IV, and HardCopy IV devices, replace the stratixiv_hssi model file
with the arriaii_hssi, cycloneiv_hssi, and hardcopyiv_hssi model files, respectively.
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
4–16
Chapter 4: Cadence NC-Sim Support
Simulating Designs that Include Transceivers
To perform a post-fit timing simulation of your design that includes the ALTGX
megafunction, edit your cds.lib file so that all of the libraries point to the work library
and compile stratixiv_atoms and stratixiv_hssi_atoms into the stratixiv and
stratixiv_hssi libraries, respectively. When compiling the library files, you can safely
ignore the following warning message:
"Multiple logical libraries mapped to a single location"
For an example of a cds.lib file, refer to Example 4–13 on page 4–15.
The stratixiv_hssi_atoms model file references the lpm and sgate libraries. You must
create these libraries to perform a simulation.
Compiling Library Files for Gate-Level Timing Simulation in VHDL
To compile the libraries necessary for timing simulation of a VHDL design targeting a
Stratix IV device, type the commands shown in Example 4–16 at the NC-Sim
command prompt.
Example 4–16. Compile Libraries Commands for Timing Simulation in VHDL
ncvhdl -work lpm 220pack.vhd 220model.vhd
ncvhdl -work altera_mf altera_mf_components.vhd altera_mf.vhd
ncvhdl -work sgate sgate_pack.vhd sgate.vhd
ncvhdl -work stratixiv stratixiv_atoms.vhd \
stratixiv_components.vhd
ncvhdl -work stratixiv_hssi stratixiv_hssi_components.vhd \
stratixiv_hssi_atoms.vhd
ncvhdl -work work <altgx>.vho
ncsdfc <project name>_vhd.sdo
ncelab work.<my design> -TIMESCALE 1ps/1ps \
-SDF_CMD_FILE <SDF Command File> -PULSE_R 0 -PULSE_INT_R 0
Compiling Library Files for Gate-Level Timing Simulation in Verilog HDL
To compile the libraries necessary for timing simulation of a Verilog HDL design
targeting a Stratix IV device, type the commands shown in Example 4–17 at the
NC-Sim command prompt.
Example 4–17. Compile Libraries Commands for Timing Simulation in Verilog HDL
ncvlog
ncvlog
ncvlog
ncvlog
ncvlog
ncvlog
ncelab
-work lpm 220model.v
-work altera_mf altera_mf.v
-work sgate sgate.v
-work stratixiv stratixiv_atoms.v
-work stratixiv_hssi stratixiv_hssi_atoms.v
-work work <altgx>.vo
work.<my design> -TIMESCALE 1ps/1ps -PULSE_R 0 -PULSE_INT_R 0
Functional Simulation for Stratix V GX Devices
Functional simulation for Stratix V devices is similar to functional simulation for
Arria II, Cyclone IV, HardCopy IV, and Stratix IV devices. To simulate transceivers in
Arria II, Cyclone IV, HardCopy IV, and Stratix IV devices, you only have to replace the
stratixv_hssi model file with the arriaii_hssi, cycloneiv_hssi, hardcopyiv_hssi, and
stratiiv_hssi model files, respectively.
The stratixv_hssi_atoms model file references the lpm and sgate libraries. You must
compile these libraries to perform a simulation.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 4: Cadence NC-Sim Support
Simulating Designs that Include Transceivers
1
4–17
The transceiver module from the MegaWizard Plug-In Manager is created in
Interfaces/Transceiver PHY. Select Custom PHY.
Compiling Library Files for Functional Simulation
To compile the libraries necessary for functional simulation of a Verilog HDL or
VHDL design targeting a Stratix V device, type the following command at the VCS
command prompt:
Example 4–18 shows the cds.lib file.
Example 4–18. cds.lib File
SOFTINCLUDE ${CDS_INST_DIR}/tools/inca/files/cdsvhdl.lib
SOFTINCLUDE ${CDS_INST_DIR}/tools/inca/files/cdsvlog.lib
DEFINE work ./ncsim_work
DEFINE stratixv_hssi ./ncsim_work
DEFINE stratixv ./ncsim_work
DEFINE lpm ./ncsim_work
DEFINE sgate ./ncsim_work
The stratixv_hssi_atoms model file references the lpm and sgate libraries. You must
create these libraries to perform a simulation.
Compiling Library Files for Functional Simulation in VHDL
To compile the libraries necessary for functional simulation of a VHDL design
targeting a Stratix V device, type the commands shown in Example 4–19 at the
NC-Sim command prompt.
Example 4–19. Compile Libraries Commands for Functional Simulation in VHDL
ncvhdl -work lpm 220pack.vhd 220model.vhd
ncvhdl -work altera_mf altera_mf_components.vhd altera_mf.vhd
ncvhdl -work sgate sgate_pack.vhd sgate.vhd
ncvhdl -work stratixv_hssi stratixv_hssi_components.vhd \
ncvlog +v2k –work stratixv_hssi \
quartus/eda/sim_lib/cadence/stratixv_hssi_atoms_ncrypt.v
stratixv_hssi_atoms.vhd
ncvhdl -work work <my_design>.vhd
ncelab work.<my design>
Compiling Library Files for Functional Simulation in Verilog HDL
To compile the libraries necessary for functional simulation of a Verilog HDL design
targeting a Stratix V device, type the commands shown in Example 4–20 at the
NC-Sim command prompt.
Example 4–20. Compile Libraries Commands for Functional Simulation in Verilog HDL
ncvlog -work lpm 220model.v
ncvlog -work altera_mf altera_mf.v
ncvlog -work sgate sgate.v
ncvlog +v2k –work stratixv_hssi \
quartus/eda/sim_lib/cadence/stratixv_hssi_atoms_ncrypt.v
ncvlog -work stratixv_hssi stratixv_hssi_atoms.v
ncvlog -work work <my design>.v
ncelab work.<my design>
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
4–18
Chapter 4: Cadence NC-Sim Support
Using the NativeLink Feature with NC-Sim
Pulse Reject Delays
By default, the NC-Sim software filters out all pulses that are shorter than the
propagation delay between primitives. Setting the pulse reject delays options in the
NC-Sim software prevents the simulation tool from filtering out these pulses. Use the
following options to ensure that all signal pulses are seen in the simulation results.
-PULSE_R
Use this option when the pulses in your simulation are shorter than the delay within a
gate-level primitive. The argument is the percentage of delay for pulse reject limit for
the path.
-PULSE_INT_R
Use this option when the pulses in your simulation are shorter than the interconnect
delay between gate-level primitives. The argument is the percentage of delay for
pulse reject limit for the path.
1
The -PULSE_R and -PULSE_INT_R options are also used by default in the
NativeLink feature for gate-level timing simulation.
The following NC-Sim software command shows the command-line syntax to
perform a gate-level timing simulation with the device family library.
ncelab worklib.<project name>:entity –SDF_CMD_FILE <SDF Command File> \
-TIMESCALE 1ps/1ps -PULSE_R 0 -PULSE_INT_R 0
Using the NativeLink Feature with NC-Sim
The NativeLink feature in the Quartus II software facilitates the seamless transfer of
information between the Quartus II software and EDA tools and allows you to run
NC-Sim within the Quartus II software.
f
For more information, refer to the “Using the NativeLink Feature” section in the
Simulating Designs with EDA Tools chapter in volume 3 of the Quartus II Handbook.
Generating a Timing VCD File for the PowerPlay Power Analyzer
To generate a timing .vcd file for PowerPlay, you must first generate a VCD script in
the Quartus II software and run the VCD script from the NC-Sim software to generate
a timing .vcd file. This timing .vcd file can then be used by the PowerPlay Power
Analyzer for power analysis. The following instructions show you how to generate a
timing .vcd file.
Perform the following steps to generate timing VCD scripts in the Quartus II
software:
1. In the Quartus II software, on the Assignments menu, click Settings. The Settings
dialog box appears (Figure 4–1).
2. In the Category list, click the “+” icon to expand EDA Tool Settings.
3. Click Simulation.
4. In the Tool name list, click NC-Sim.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 4: Cadence NC-Sim Support
Viewing a Waveform from a .trn File
4–19
5. Turn on the Generate Value Change Dump (VCD) File Script option.
Figure 4–1. Simulation Settings Dialog Box
6. Click OK.
7. To generate the VCD script file, perform a full compilation.
Perform the following steps to generate a timing .vcd file in NC-Sim:
1. In the NC-Sim software, before simulating your design, source the
<revision_name>_dump_all_vcd_nodes.tcl script. To source the .tcl script, use the
–input switch while running the nssim command. For example:
ncsim –input <revision_name>_dump_all_vcd_nodes.tcl <my design>
2. Continue to run the simulation until it finishes. Exit ncsim and the
<revision_name>.vcd is generated in the simulation directory.
f
For more detailed information about using the timing .vcd file for power analysis,
refer to the PowerPlay Power Analysis chapter in volume 3 of the Quartus II Handbook.
Viewing a Waveform from a .trn File
A .trn file is automatically generated when your simulation is done. The .trn file is not
readable. It is used for generating the waveform view through SimVision.
To view a waveform from a .trn file through SimVision, perform the following steps:
1. Type simvision on a command line. The Design Browser dialog box appears.
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
4–20
Chapter 4: Cadence NC-Sim Support
Scripting Support
2. On the File menu, click Open Database. The Open File dialog box appears.
3. In the Directories field, browse to the directory that contains your .trn file.
4. Double-click the .trn file.
5. In the Design Browser dialog box, select the signals that you want to observe from
the Hierarchy.
6. Right-click the selected signals and click Send to Waveform Window.
1
You cannot view a waveform from a .vcd file in SimVision, and the .vcd file cannot be
converted to a .trn file.
Scripting Support
You can run procedures and make settings described in this chapter in a Tcl script.
You can also run some procedures at a command prompt.
f
For detailed information about scripting command options, refer to the Quartus II
Command-Line and Tcl API Help browser.
To run the Help browser, type the following command at the command prompt:
quartus_sh --qhelp r
f
For more information, refer to About Quartus II Scripting in Quartus II Help.
f
For more information about Tcl scripting, refer to the Tcl Scripting chapter in volume 2
of the Quartus II Handbook. For information about all settings and constraints in the
Quartus II software, refer to the Quartus II Settings File Manual. For more information
about command-line scripting, refer to the Command-Line Scripting chapter in
volume 2 of the Quartus II Handbook.
Generating NC-Sim Simulation Output Files
You can generate .vo files and .sdo simulation output files with Tcl commands or at a
command prompt.
For more information about generating .vo simulation output files and .sdo file
simulation output files, refer to “Quartus II Simulation Output Files” on page 4–7.
Tcl Commands
The following three assignments cause a Verilog HDL netlist to be written out when
you run the Quartus II netlist writer.
set_global_assignment -name EDA_OUTPUT_DATA_FORMAT VERILOG -section_id eda_simulation
set_global_assignment -name EDA_TIME_SCALE "1 ps" -section_id eda_simulation
set_global_assignment -name EDA_SIMULATION_TOOL "NC-Verilog (Verilog)"
The netlist has a 1 ps timing resolution for the NC-Sim simulation software.
Type the following Tcl command to run the Quartus II Netlist Writer:
execute_module -tool eda
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 4: Cadence NC-Sim Support
Conclusion
4–21
Command Prompt
Type the following command to generate a simulation output file for the Cadence
NC-Sim software simulator. Specify Verilog HDL or VHDL for the format.
quartus_eda <project name> --simulation --format=<verilog|vhdl> --tool=ncsim r
Conclusion
The Cadence NC family of simulators work within an Altera FPGA design flow to
perform functional, post-synthesis, and gate-level timing simulation, easily and
accurately.
Altera provides functional models of LPM and Altera-specific megafunctions that you
can compile with your testbench or design. For timing simulation, use the atom netlist
file generated by Quartus II compilation.
The seamless integration of the Quartus II software and Cadence NC tools make this
simulation flow an ideal method for fully verifying an FPGA design.
Document Revision History
Table 4–2 shows the revision history for this chapter.
Table 4–2. Document Revision History (Part 1 of 2)
Date
Version
July 2010
10.0.0
November 2009
March 2009
© July 2010
9.1.0
9.0.0
Altera Corporation
Changes Made
■
Linked to Help where appropriate
■
Minor text edits
■
Removed Referenced Documents section
■
Removed NativeLink information and referenced new Simulating Designs with EDA
Tools chapter in volume 3 of the Quartus II Handbook
■
Added “RTL Functional Simulation for Stratix IV Devices” and “Gate-Level Timing
Simulation for Stratix IV Devices” sections
■
Minor text edits
■
Removed “Compile Libraries Using the Altera Simulation Library Compiler”
■
Added “Compile Libraries Using the EDA Simulation Library Compiler” on page 4–5
■
Added “Generate Simulation Script from EDA Netlist Writer” on page 4–35
■
Added “Viewing a Waveform from a .trn File” on page 4–36
■
Minor editorial updates
Quartus II Handbook Version 10.0 Volume 3: Verification
4–22
Chapter 4: Cadence NC-Sim Support
Document Revision History
Table 4–2. Document Revision History (Part 2 of 2)
Date
Version
November 2008
8.1.0
May 2008
8.0.0.0
Changes Made
■
Added “Compile Libraries Using the Altera Simulation Library Compiler” on page 4–5.
■
Added information about the --simlib_comp utility.
■
Minor editorial updates.
■
Updated entire chapter using 8½” × 11” chapter template.
■
Updated Table 4–1.
■
Updated Figure 4–1.
■
Updated “Compilation in Command-Line Mode” on page 4–9.
■
Updated “Generating a Timing Netlist with Different Timing Models” on page 4–18.
■
Added “Disable Timing Violation on Registers” on page 4–20.
■
Updated “Simulating Designs that Include Transceivers” on page 4–23.
■
Updated “Performing a Gate Level Simulation Using NativeLink” on page 4–30.
■
Added “Generating a Timing VCD File for PowerPlay” on page 4–33.
■
Added hyperlinks to referenced documents throughout the chapter.
■
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 10.0 Volume 3: Verification
© July 2010 Altera Corporation
5. Aldec Active-HDL and
Riviera-PRO Support
QII53023-10.0.0
This chapter describes how to use the Active-HDL and Riviera-PRO software to
simulate designs that target Altera® FPGAs. This chapter provides step-by-step
instructions about how to perform functional simulations, post-synthesis simulations,
and gate-level timing simulations for Verilog HDL or VHDL designs.
This chapter includes the following topics:
■
“Software Requirements”
■
“Using Active-HDL or Riviera-PRO Software in Quartus II Design Flows”
■
“Simulation Libraries” on page 5–2
■
“Performing Simulation Using the Active-HDL Software (GUI Mode)” on
page 5–3
■
“Performing Simulation Using the Riviera-PRO Software (GUI Mode)” on
page 5–5
■
“Performing Simulation Using the Active-HDL or Riviera-PRO Software
(Command-Line Mode)” on page 5–6
■
“Compiling System Verilog Files” on page 5–10
■
“Simulating Designs that Include Transceivers” on page 5–10
■
“Using the NativeLink Feature in Active-HDL or Riviera-PRO Software” on
page 5–17
■
“Generating .vcd Files for the PowerPlay Power Analyzer” on page 5–17
■
“Scripting Support” on page 5–18
Software Requirements
To simulate your design using the Active-HDL or Riviera-PRO software, you must
first set up the Altera libraries. These libraries are installed with the Quartus II
software.
f
For more information about installing the software and directories created during the
Quartus II software installation, refer to the Altera Software Installation and Licensing
manual.
Using Active-HDL or Riviera-PRO Software in Quartus II Design Flows
You can perform the following types of simulations using the Active-HDL
or Riviera-PRO software:
© July 2010
■
Functional simulation
■
Post-synthesis simulation
■
Gate-level timing simulation
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
5–2
Chapter 5: Aldec Active-HDL and Riviera-PRO Support
Simulation Libraries
Simulation Libraries
Simulation model libraries are required to run a simulation whether you are running
a functional simulation, post-synthesis simulation, or gate-level timing simulation. In
general, running a functional simulation requires the functional simulation model
libraries and running a post-synthesis or gate-level timing simulation requires the
gate-level timing simulation model libraries. You must compile the necessary library
files before you can run the simulation.
However, there are a few exceptions where you are also required to compile gate-level
timing simulation library files to perform functional simulation. For example, some of
Altera megafunctions require gate-level libraries to perform a functional simulation in
third-party simulators.
1
For each megafunction that you are using, refer to the last page in the Altera
MegaWizard™ Plug-In Manager, which lists the simulation library files required to
perform a functional simulation for that megafunction.
The transceiver megafunction (for example, ALTGX) also requires the gate-level
libraries to perform functional simulation.
For detailed, step-by-step instructions about how to simulate the transceiver
megafunction, refer to “Simulating Designs that Include Transceivers” on page 5–10.
Simulation Library Files in the Quartus II Software
In Active-HDL or Riviera-PRO software, you must compile the necessary libraries to
perform functional, post-synthesis functional, or gate-level timing simulation. You
can refer to these library files for any particular simulation model that you are looking
for.
f
For a list of all functional simulation library files in the Quartus II directory, refer to
Altera Functional Simulation Libraries in Quartus II Help. For a list of all gate-level
timing simulation and post-fit library files in the Quartus II directory, refer to Altera
Post-Fit Libraries in Quartus II Help.
Disabling Timing Violation on Registers
In certain situations, the timing violation can be ignored and you can disable the
timing violation on registers; for example, timing violations that occur in internal
synchronization registers used for asynchronous clock-domain crossing.
By default, the x_on_violation_option logic option is On, which means the
simulation shows “x” whenever a timing violation occurs. To disable showing the
timing violation on certain registers, set the x_on_violation_option logic option to
Off on those registers. The following command is an example of the QSF file:
set_instance_assignment -name X_ON_VIOLATION_OPTION OFF –to <register_name>
Compiling Libraries Using the EDA Simulation Library Compiler
The EDA Simulation Library Compiler is used to compile Verilog HDL and VHDL
simulation libraries for all Altera devices and supported third-party simulators. You
can use this tool to compile all libraries required by and gate-level timing simulation.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 5: Aldec Active-HDL and Riviera-PRO Support
Performing Simulation Using the Active-HDL Software (GUI Mode)
5–3
1
The altera_mf_components.vhd and altera_mf.vhd model files should be compiled
into the altera_mf library. The 220pack.vhd and 220model.vhd model files should be
compiled into the lpm library.
f
For more information about this tool, refer to the “EDA Simulation Library Compiler”
section in the Simulating Designs with EDA Tools chapter in volume 3 of the Quartus II
Handbook.
Performing Simulation Using the Active-HDL Software (GUI Mode)
Perform simulation of Verilog HDL or VHDL designs with Active-HDL software at
various levels to verify designs from different aspects. There are three types of
simulation:
■
Functional simulation
■
Post-synthesis simulation
■
Gate-level timing simulation
Simulation helps you verify your designs and debug them against any errors the
designs may have. The following sections provide step-by-step instructions to
perform the simulation through the GUI.
For high-speed simulation, you must select ps in the Resolution list for your
simulator resolutions. If you choose slower than ps, the high-speed simulation may
fail.
Workspace creation is the mandatory first step to start working in the Active-HDL
GUI. You must create a new workspace to add the simulation model files, design files,
and testbench file before you can compile them.
Simulating VHDL Designs
When you simulate VHDL designs using the Active-HDL GUI, you do not have to
remember the commands to compile the libraries or load and simulate the VHDL
design files. You can use the Active-HDL GUI to perform the functional simulation,
post-synthesis simulation, and gate-level timing simulation.
Performing Functional Simulation
Functional simulation is typically performed to verify the syntax of the code and to
check the functionality of the design.
f
For detailed information about how to perform functional simulation in the
Active-HDL software for VHDL designs, refer to Performing a Simulation of a VHDL
Design with the Active-HDL Software in Quartus II Help.
If you are targeting a Stratix V device, compile the following files in the
quartus/eda/sim_lib/aldec directory:
stratixv_atoms_ncrypt.v
stratixv_hssi_atoms_ncrypt.v
stratixv_pcie_hip_atoms_ncrypt.v
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
5–4
Chapter 5: Aldec Active-HDL and Riviera-PRO Support
Performing Simulation Using the Active-HDL Software (GUI Mode)
These files contain IEEE encrypted Verilog models suitable for VHDL/Verilog
co-simulation. You need a co-simulation license from Aldec to use these models in
VHDL.
1
Compile these encrypted Verilog files before you compile any VHDL files.
1
Compile stratixv_pcie_hip_atoms_ncrypt.v with the SystemVerilog option.
Also, compile the following files in the quartus/eda/sim_lib directory:
stratixv_atoms.vhd
stratixv_components.vhd
stratixv_hssi_components.vhd
stratixv_pcie_hip_components.vhd
stratixv_hssi_atoms.vhd
stratixv_pcie_hip_atoms.vhd
1
The PCIe® files are required only if you are using the PCIe HIP.
Simulating Verilog HDL Designs
When you simulate Verilog HDL designs using the Active-HDL GUI, you do not have
to remember the commands to compile the libraries or load and simulate the Verilog
HDL design files. You can use the Active-HDL GUI to perform functional simulation,
post-synthesis simulation, and gate-level timing simulation.
Performing Functional Simulation
Functional simulation is performed to verify the syntax of the code and to check the
functionality of the design.
f
For detailed information about how to perform functional simulation in the
Active-HDL software for Verilog HDL designs, refer to Performing a Simulation of a
Verilog HDL Design with the Active-HDL Software in Quartus II Help.
If you are targeting a Stratix V device, compile the following files in the
quartus/eda/sim_lib/aldec directory:
stratixv_atoms_ncrypt.v
stratixv_hssi_atoms_ncrypt.v
stratixv_pcie_hip_atoms_ncrypt.v
These files contain IEEE encrypted Verilog models suitable for VHDL/Verilog
co-simulation.
1
Compile these encrypted Verilog files before you compile any VHDL files.
1
Compile stratixv_pcie_hip_atoms_ncrypt.v with the SystemVerilog option.
Also, compile the following files in the quartus/eda/sim_lib directory:
stratixv_atoms.v
stratixv_hssi_atoms.v
stratixv_pcie_hip_atoms.v
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 5: Aldec Active-HDL and Riviera-PRO Support
Performing Simulation Using the Riviera-PRO Software (GUI Mode)
5–5
1
Compile stratixv_pcie_hip_atoms.v with the SystemVerilog option.
1
The PCIe® files are required only if you are using the PCIe HIP.
Performing Simulation Using the Riviera-PRO Software (GUI Mode)
You can use the Riviera-PRO software to perform the following types of simulation:
f
■
Functional simulation
■
Post-synthesis simulation
■
Gate-level timing simulation
For detailed information about how to perform functional simulation with
the Riviera-PRO software, refer to Performing an RTL Functional Simulation with the
Riviera-PRO Software in Quartus II Help. For detailed information about how to
perform post-synthesis simulation with the Riviera-PRO software, refer to Performing
a Post-Synthesis Simulation with the Riviera-PRO Software in Quartus II Help. For
detailed information about how to perform gate-level timing simulation with the
Riviera-PRO software, refer to Performing a Gate-Level Simulation with the Riviera-PRO
Software in Quartus II Help.
If you are performing a functional simulation in Verilog HDL and targeting a Stratix V
device, compile the following files in the quartus/eda/sim_lib/aldec directory:
stratixv_atoms_ncrypt.v
stratixv_hssi_atoms_ncrypt.v
stratixv_pcie_hip_atoms_ncrypt.v
These files contain IEEE encrypted Verilog models suitable for VHDL/Verilog
co-simulation.
1
Compile these encrypted Verilog files before you compile any VHDL files.
1
Compile stratixv_pcie_hip_atoms_ncrypt.v with the SystemVerilog option.
Also, compile the following files in the quartus/eda/sim_lib directory:
stratixv_atoms.v
stratixv_hssi_atoms.v
stratixv_pcie_hip_atoms.v
1
Compile stratixv_pcie_hip_atoms.v with the SystemVerilog option.
1
The PCIe® files are required only if you are using the PCIe HIP.
If you are performing a functional simulation in VHDL and targeting a Stratix V
device, compile the following files in the quartus/eda/sim_lib/aldec directory:
stratixv_atoms_ncrypt.v
stratixv_hssi_atoms_ncrypt.v
stratixv_pcie_hip_atoms_ncrypt.v
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
5–6
Chapter 5: Aldec Active-HDL and Riviera-PRO Support
Performing Simulation Using the Active-HDL or Riviera-PRO Software
These files contain IEEE encrypted Verilog models suitable for VHDL/Verilog
co-simulation. You need a co-simulation license from Aldec to use these models in
VHDL.
1
Compile these encrypted Verilog files before you compile any VHDL files.
1
Compile stratixv_pcie_hip_atoms_ncrypt.v with the SystemVerilog option.
Also, compile the following files in the quartus/eda/sim_lib directory:
stratixv_atoms.vhd
stratixv_components.vhd
stratixv_hssi_components.vhd
stratixv_pcie_hip_components.vhd
stratixv_hssi_atoms.vhd
stratixv_pcie_hip_atoms.vhd
1
The PCIe® files are required only if you are using the PCIe HIP.
Performing Simulation Using the Active-HDL or Riviera-PRO Software
(Command-Line Mode)
Perform simulation of Verilog HDL or VHDL designs with Active-HDL software at
various levels to verify designs from different aspects. There are three categories of
simulation:
■
Functional simulation
■
Post-synthesis simulation
■
Gate-level simulation
Simulation helps you verify your design and debug it against any possible errors in the
design.
For high-speed simulation, you must select ps in the Resolution list for your simulator
resolutions. If you choose slower than ps, the high-speed simulation may fail.
In command-line mode, standalone commands, such as vlib, vcom, and vsim, are
executed in the system shell (for example, cygwin). These standalone commands can
be grouped into script files (tcl, perl, windows batch) that are run from the system
shell.
Before running Active-HDL or Riviera-PRO from the command line, ensure that the
Active-HDL/bin or Riviera-PRO/bin directory is located in PATH environment
variables.
Simulating Verilog HDL Designs Using the Active-HDL or Riviera-PRO Software
If you are running the simulation commands from the Active-HDL GUI console, you
must first create the workspace. Type the following commands to create and open the
workspace:
createdesign DELAY_TEST C:/DELAY_TEST/simulation/activehdl r
opendesign -a DELAY_TEST.adf r
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 5: Aldec Active-HDL and Riviera-PRO Support
Performing Simulation Using the Active-HDL or Riviera-PRO Software (Command-Line Mode)
5–7
If you are running Riviera-PRO, you can skip the step above.
Performing Functional Simulation
Use the following commands to perform a functional simulation for Verilog HDL
designs with one of the libraries (lib1) listed in Altera Functional Simulation Libraries in
Quartus II Help:
# Create and compile Altera libraries
vlib <lib1> r
vlog -v2k -dbg -work <lib1> <lib1.v> r
vlib <lib2> r
vlog -v2k -dbg -work <lib2> <lib2.v> r
# Create work library and compile design files and testbench file
vlib work r
vlog -v2k -dbg -work work <design_file1.v> <design file2.v> <testbench \
file.v> r
# Load Design
vsim +access +r -t 1ps -L work -L <lib1> -L <lib2> work.<testbench module \
name> r
#add signals at waveform and run
add wave * r
run r
Example
vlib verilog_libs/lpm_ver
vlog -v2k -dbg -work lpm_ver c:/altera/91/quartus/eda/sim_lib/220model.v
vlib verilog_libs/altera_mf_ver
vlog -v2k -dbg -work altera_mf_ver
c:/altera/91/quartus/eda/sim_lib/altera_mf.v
vlib work
vlog -v2k -dbg -work work C:/project/adder.v C:/project/adder.vt
vsim +access +r -t 1ps -L work -L lpm_ver -L altera_mf_ver
work.adder_vlg_vec_tst
add wave *
Performing Post-Synthesis Simulation
Before you run post-synthesis simulation, generate post-synthesis simulation netlist
files. Refer to the “Generating Post-Synthesis Simulation Netlist Files” section in the
Simulating Designs with EDA Tools chapter in volume 3 of the Quartus II Handbook.
1
You cannot perform post-synthesis or post-fit simulation if you are targeting the
Stratix V device family.
Use the following commands to perform a post-synthesis simulation for Verilog HDL
designs with one of the libraries (lib1) listed in Altera Post-Fit Libraries in Quartus II
Help:
# Create and compile Altera libraries
vlib <lib1> r
vlog -v2k -dbg -work <lib1> <lib1.v> r
vlib <lib2> r
vlog -v2k -dbg -work <lib2> <lib2.v> r
# Create work library and compile EDA output netlist files and testbench file
vlib work r
vlog -v2k -dbg -work work <EDA_output_netlist.vo> <testbench file.v> r
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
5–8
Chapter 5: Aldec Active-HDL and Riviera-PRO Support
Performing Simulation Using the Active-HDL or Riviera-PRO Software
# Load Design
vsim +access +r -t 1ps +transport_int_delays +transport_path_delays -L work \
-L <lib1> -L <lib2> work.<testbench module name> r
#add signals at waveform and run
add wave * r
run r
Example
vlib verilog_libs/lpm_ver
vlog -v2k -dbg -work lpm_ver c:/altera/91/quartus/eda/sim_lib/220model.v
vlib verilog_libs/altera_ver
vlog -v2k -dbg -work altera_ver
c:/altera/91/quartus/eda/sim_lib/altera_primitives.v
vlib verilog_libs/stratixiv_ver
vlog -v2k -dbg -work stratixiv_ver
c:/altera/91/quartus/eda/sim_lib/stratixiv_atoms.v
vlib work
vlog -v2k -dbg -work work C:/project/simulation/activehdl/adder.vo
C:/project/adder.vt
vsim +access +r -t 1ps +transport_int_delays +transport_path_delays -L work
-L lpm_ver -L altera_mf_ver work.adder_vlg_vec_tst
add wave *
run
Performing Gate-Level Timing Simulation
The steps for gate-level timing simulation are almost same as the steps for
post-synthesis simulation. The only difference is that the SDO file must be
back-annotated for gate level-timing simulation.
For Verilog HDL designs, the back-annotating process is done within the
EDA_output_netlist.vo script. Therefore, you are not required to back-annotate the
SDO file again.
1
You cannot perform post-synthesis or post-fit simulation if you are targeting the
Stratix V device family.
Simulating VHDL Designs Using the Active-HDL or Riviera-PRO Software
If you are running the simulation commands from the Active-HDL GUI console, you
first create the workspace. The following commands create and open the workspace:
createdesign <workspace name> <your design path> r
opendesign -a <workspace name>.adf r
If you are running Riviera-PRO, you can skip the step above.
Performing Functional Simulation
Use the following commands to perform a functional simulation for VHDL designs
with one of the libraries (lib1) listed in Altera Functional Simulation Libraries in
Quartus II Help:
# Create and compile Altera libraries
vlib <lib1> r
vcom -strict93 -dbg -work <lib1> <lib1_component/pack.vhd> <lib1.vhd> r
vlib <lib1> r
vcom -strict93 -dbg -work <lib2> <lib2_component/pack.vhd> <lib2.vhd> r
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 5: Aldec Active-HDL and Riviera-PRO Support
Performing Simulation Using the Active-HDL or Riviera-PRO Software (Command-Line Mode)
5–9
# Create work library and compile design files and testbench file
vlib work r
vcom - strict93 -dbg -work work <design_file1.vhd> <design file2.vhd> \
<testbench file.vhd> r
# Load Design
vsim +access +r -t 1ps -L work -L <lib1> -L <lib2> work.<testbench module \
name> r
#add signals at waveform and run
add wave * r
run r
Example
vlib vhdl_libs/lpm
vcom -strict93 -dbg -work lpm c:/altera/91/quartus/eda/sim_lib/220pack.vhd
vcom -strict93 -dbg -work lpm c:/altera/91/quartus/eda/sim_lib/220model.vhd
vlib vhdl_libs/altera_mf
vcom -strict93 -dbg -work altera_mf
c:/altera/91/quartus/eda/sim_lib/altera_mf_components.vhd
vcom -strict93 -dbg -work altera_mf
c:/altera/91/quartus/eda/sim_lib/altera_mf.vhd
vlib work
vcom -strict93 -dbg -work work C:/project/adder.vhd C:/project/adder.vht
vsim +access +r -t 1ps -L adder -L work -L lpm -L altera_mf
work.adder_vhd_vec_tst
#add signals at waveform and run
add wave *
run
Performing Post-Synthesis Simulation
Before you run post-synthesis simulation, generate post-synthesis simulation netlist
files. Refer to the “Generating Post-Synthesis Simulation Netlist Files” section in the
Simulating Designs with EDA Tools chapter in volume 3 of the Quartus II Handbook.
1
You cannot perform post-synthesis or post-fit simulation if you are targeting the
Stratix V device family.
Use the following commands to perform a functional simulation for VHDL designs
with one of the libraries (lib1) listed in Altera Post-Fit Libraries in Quartus II Help:
# Create and compile Altera libraries
vlib <lib1> r
vcom -strict93 -dbg -work <lib1> <lib1_component/pack.vhd> <lib1.vhd> r
vlib <lib1> r
vcom -strict93 -dbg -work <lib2> <lib2_component/pack.vhd> <lib2.vhd> r
# Create work library and compile EDA output netlist files and testbench file
vlib work r
vcom - strict93 -dbg -work work <EDA output netlist.vho> <testbench \
file.vhd> r
# Load Design
vsim +access+r -t 1ps +transport_int_delays +transport_path_delays -L work
\ -L <lib1> -L <lib2> work.<testbench module name> r
#add signals at waveform and run
add wave * r
run r
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
5–10
Chapter 5: Aldec Active-HDL and Riviera-PRO Support
Compiling System Verilog Files
Example
vlib vhdl_libs/lpm
vcom -strict93 -dbg -work lpm c:/altera/91/quartus/eda/sim_lib/220pack.vhd
vcom -strict93 -dbg -work lpm c:/altera/91/quartus/eda/sim_lib/220model.vhd
vlib vhdl_libs/altera
vcom -strict93 -dbg -work altera
c:/altera/91/quartus/eda/sim_lib/altera_primitives_components.vhd
vcom -strict93 -dbg -work altera
c:/altera/91/quartus/eda/sim_lib/altera_primitives.vhd
vlib work
vcom -strict93 -dbg -work work C:/project/simulation/activehdl/adder.vho
C:/project/adder.vht
vsim +access +r -t 1ps +transport_int_delays +transport_path_delays -L adder
-L work -L lpm -L altera_mf work.adder_vhd_vec_tst
add wave *
run
Performing Gate-Level Timing Simulation
The steps for gate-level timing simulation are almost same as the steps for
post-synthesis simulation. The only difference is that the SDO file must be
back-annotated for gate level-timing simulation.
1
You cannot perform post-synthesis or post-fit simulation if you are targeting the
Stratix V device family.
For VHDL designs, the back-annotating process is done by adding the –sdftyp
option.
Example
vsim +access +r -t 1ps +transport_int_delays +transport_path_delays
-sdftyp <instance path to design>= <path to SDO file> -L adder -L work
-L lpm -L altera_mf work.adder_vhd_vec_tst
Compiling System Verilog Files
If your design includes multiple System Verilog files, you must compile the System
Verilog files together with a single alog command.
If you have Verilog files and System Verilog files in your design, it is recommended
that you compile the Verilog files, and then compile only the System Verilog files in
the single alog command.
Simulating Designs that Include Transceivers
If your design includes Arria®, Arria II, Cyclone IV, HardCopy IV, Stratix, Stratix II, or
Stratix IV transceivers, you must compile additional library files to perform functional
or gate-level timing simulations. The following example shows how to perform
simulation on designs that include Stratix GX and Stratix II GX transceivers.
For high-speed simulation, you must select ps in the Resolution list for your
simulator resolutions (Design tab of the Start Simulation dialog box). If you choose
slower than ps, the high-speed simulation may fail.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 5: Aldec Active-HDL and Riviera-PRO Support
Simulating Designs that Include Transceivers
5–11
Performing simulation with transceivers in Arria GX or Stratix II GX is very similar.
The only requirement is to replace the stratixiigx_atoms and stratixiigx_hssi_atoms
model files with the arriagx_atoms and arriagx_hssi_atoms model files, respectively.
f
If your design contains PCI Express® hard IP, refer to the “Simulate the Design”
section in the PCI Express Compiler User Guide.
Functional Simulation for Stratix II GX Devices
Functional simulation for Stratix II GX devices is similar to functional simulation for
Arria GX devices. The following example shows only the functional simulation for
designs that include transceivers in Stratix II GX devices. To simulate transceivers in
Arria GX devices, replace the stratixiigx_hssi model file with the arriagx_hssi model
file.
To perform an functional simulation of your design that instantiates the ALT2GXB
megafunction, which enables the gigabit transceiver blocks on Stratix II GX devices,
you must generate a functional simulation netlist and compile the stratixiigx_hssi
model file into the stratixiigx_hssi library.
1
The stratixgx_hssi_atoms model file references the lpm and sgate libraries; you must
create these libraries to perform a simulation.
To run the functional simulation, you must generate a functional simulation netlist by
turning on Generate Simulation Model in the Simulation Libraries tab of the
ALT2GXB MegaWizard Plug-In Manager.
The <alt2gxb entity name>.vho or <alt2gxb module name>.vo is generated in the current
project directory.
The ALT2GXB functional simulation library file generated by the Quartus II software
references stratixiigx_hssi WYSIWYG atoms.
Performing Functional Simulation in VHDL
Type the commands in Example 5–1 to compile and simulate the design.
Example 5–1.
vcom -work lpm 220pack.vhd 220model.vhd
vcom -work altera_mf altera_mf_components.vhd altera_mf.vhd
vcom -work sgate sgate_pack.vhd sgate.vhd
vcom -work stratixiigx_hssi stratixiigx_hssi_components.vhd \
stratixiigx_hssi_atoms.vhd
vcom -work work <alt2gxb entity name>.vho
vcom -work work <my design>.vhd <my testbench>.vhd
vsim -L lpm -L altera_mf -L sgate -L stratixgx_hssi work.<my testbench>
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
5–12
Chapter 5: Aldec Active-HDL and Riviera-PRO Support
Simulating Designs that Include Transceivers
Performing Functional Simulation in Verilog HDL
Type the commands in Example 5–2 to compile and simulate the design.
Example 5–2.
vlog -work lpm_ver 220model.v
vlog -work altera_mf_ver altera_mf.v
vlog -work sgate_ver sgate.v
vlog -work stratixiigx_hssi_ver stratixiigx_hssi_atoms.v
vlog -work work <alt2gxb module name>.vo
vlog -work work <my design>.v <my testbench>.v
vsim -L lpm_ver -L altera_mf_ver -L sgate_ver -L stratixgx_hssi \
work.<my testbench>
Gate-Level Timing Simulation for Stratix II GX Devices
To perform a gate-level timing simulation of your design that includes a Stratix II GX
transceiver, you must compile stratixiigx_atoms and stratixiigx_hssi_atoms into the
stratixiigx and stratixiigx_hssi libraries, respectively.
Performing Gate-Level Timing Simulation in VHDL
Type the commands in Example 5–3 to compile and simulate the design.
Example 5–3.
vcom -work lpm 220pack.vhd 220model.vhd
vcom -work altera_mf altera_mf_components.vhd altera_mf.vhd
vcom -work sgate sgate_pack.vhd sgate.vhd
vcom -work stratixiigx stratixiigx_atoms.vhd stratixiigx_components.vhd
vcom -work stratixiigx_hssi stratixiigx_hssi_components.vhd stratixiigx_hssi_atoms.vhd
vcom -work work <my design>.vho <my testbench>.vhd
vsim -L lpm -L altera_mf -L sgate -L stratixiigx -L stratixiigx_hssi \
work.<my testbench> -t ps -sdftyp <design instance>=<path to SDO file>.sdo \
+transport_int_delays +transport_path_delays
Performing Gate-Level Timing Simulation in Verilog HDL
Type the commands in Example 5–4 to compile and simulate the design.
Example 5–4.
vlog -work lpm_ver 220model.v
vlog -work altera_mf_ver altera_mf.v
vlog -work sgate_ver sgate.v
vlog -work stratixiigx_ver stratixiigx_atoms.v
vlog -work stratixiigx_hssi_ver stratixiigx_hssi_atoms.v
vlog -work work <my design>.vo <my testbench>.v
vsim -L lpm -L altera_mf_ver -L sgate_ver -L stratixiigx_ver -L stratixiigx_hssi_ver \
work.<my testbench> -t ps +transport_int_delays +transport_path_delays
Functional Simulation for Stratix GX Devices
To perform a functional simulation of your design that instantiates the ALTGXB
megafunction, which enables the gigabit transceiver block on Stratix GX devices,
compile the stratixgx_mf model file into the altgxb library.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 5: Aldec Active-HDL and Riviera-PRO Support
Simulating Designs that Include Transceivers
1
5–13
The stratixgx_mf model file references the lpm and sgate libraries. You must create
these libraries to perform a simulation.
Performing Functional Simulation in VHDL
Type the commands in Example 5–5 to compile and simulate the design.
Example 5–5.
vcom
vcom
vcom
vcom
vcom
vsim
-work altera_mf altera_mf_components.vhd altera_mf.vhd
-work lpm 220pack.vhd 220model.vhd
-work sgate sgate_pack.vhd sgate.vhd
-work altgxb stratixgx_mf.vhd stratixgx_mf_components.vhd
-work work<altgxb entity name>.vhd
-L lpm -L altera_mf -L sgate -L altgxb work.<my testbench>
Performing Functional Simulation in Verilog HDL
Type the commands in Example 5–6 to compile and simulate the design.
Example 5–6.
vlib
vlib
vlib
vlib
vlib
vlog
vlog
vlog
vlog
vlog
vsim
work
lpm_ver
altera_mf_ver
sgate_ver
altgxb_ver
-work lpm_ver 220model.v
-work altera_mf_ver altera_mf.v
-work sgate_ver sgate.v
-work altgxb_ver stratixgx_mf.v
-work work <altgxb module name>.v
-L lpm_ver -L altera_mf_ver -L sgate_ver -L altgxb_ver work.<my testbench>
Gate-Level Timing Simulation for Stratix GX Devices
Perform a gate-level timing simulation of your design that includes a Stratix GX
transceiver by compiling the stratixgx_atoms and stratixgx_hssi_atoms model files
into the stratixgx and stratixgx_gxb libraries, respectively.
Performing Gate-Level Timing Simulation in VHDL
Type the commands in Example 5–7 to compile and simulate the design.
Example 5–7.
vcom -work lpm 220pack.vhd 220model.vhd
vcom -work altera_mf altera_mf_components.vhd altera_mf.vhd
vcom -work sgate sgate_pack.vhd sgate.vhd
vcom -work stratixgx stratixgx_atoms.vhd stratixgx_components.vhd
vcom -work stratixgx_gxb stratixgx_hssi_atoms.vhd \
stratixgx_hssi_components.vhd
vcom -work work <my design>.vho <my testbench>.vhd
vsim -L lpm -L altera_mf -L sgate -L stratixgx -L stratixgx_gxb work. \
<my testbench> -t ps -sdftyp <design instance>=<path to SDO file>.sdo \
+transport_int_delays +transport_path_delays
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
5–14
Chapter 5: Aldec Active-HDL and Riviera-PRO Support
Simulating Designs that Include Transceivers
Performing Gate-Level Timing Simulation in Verilog HDL
Type the commands in Example 5–8 to compile and simulate the design.
Example 5–8.
vlog -work lpm_ver 220model.v
vlog -work altera_mf_ver altera_mf.v
vlog -work sgate_ver sgate.v
vlog -work stratixgx_ver stratixgx_atoms.v
vlog -work stratixgx_gxb_ver stratixgx_hssi_atoms.v
vlog -work work <my design>.vo <my testbench>.v
vsim -L lpm_ver -L altera_mf_ver -L sgate_ver -L stratixgx_ver -L stratixgx_gxb_ver \
work.<my testbench> -t ps +transport_int_delays +transport_path_delaysr
Functional Simulation for Stratix IV GX Devices
Functional simulation for Stratix IV devices is similar to functional simulation for Arria II,
Cyclone IV, and HardCopy IV devices.
The following example shows only the functional simulation for designs that include
transceivers in Stratix IV devices. To simulate transceivers in Arria II, Cyclone IV, and
HardCopy IV devices, replace the stratixiv_hssi model file with the arriaii_hssi,
cycloneiv_hssi, and hardcopyiv_hssi model files, respectively.
To perform a functional simulation of your design that instantiates the ALTGX
megafunction, which enables the gigabit transceiver blocks on Stratix IV devices, you must
generate a functional simulation netlist and compile the stratixiv_hssi model file into the
stratixiv_hssi library.
1
The stratixiv_hssi model file references the lpm and sgate libraries. You must create these
libraries to perform a simulation.
Performing Functional Simulation in VHDL
Type the commands in Example 5–9 to compile and simulate the design.
Example 5–9.
vcom -work altera_mf altera_mf_components.vhd altera_mf.vhd
vcom -work lpm 220pack.vhd 220model.vhd
vcom -work sgate sgate_pack.vhd sgate.vhd
vcom -work stratixiv_hssi stratixiv_hssi.vhd\
stratixiv_hssi_components.vhd
vcom -work work <altgxb entity name>.vhd
vsim -L lpm -L altera_mf -L sgate -L stratixiv_hssi work.<my testbench>
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 5: Aldec Active-HDL and Riviera-PRO Support
Simulating Designs that Include Transceivers
5–15
Performing Functional Simulation in Verilog HDL
Type the commands in Example 5–10 to compile and simulate the design.
Example 5–10.
vlib work
vlib lpm_ver
vlib altera_mf_ver
vlib sgate_ver
vlib stratixiv_hssi_ver
vlog -work lpm_ver 220model.v
vlog -work altera_mf_ver altera_mf.v
vlog -work sgate_ver sgate.v
vlog -work stratixiv_hssi_ver stratixiv_hssi_.v
vlog -work work <altgxb module name>.v
vsim -L lpm_ver -L altera_mf_ver -L sgate_ver \
-L stratixiv_hssi_ver work.<my testbench>
Gate-Level Timing Simulation for Stratix IV GX Devices
Perform a gate-level timing simulation of your design that includes a Stratix IV
transceiver by compiling the stratixiv_atoms and stratixiv_hssi_atoms model files
into the stratixiv and stratixiv_hssi libraries, respectively.
Performing Gate-Level Timing Simulation in VHDL
Type the commands in Example 5–11 to compile and simulate the design.
Example 5–11.
vcom -work lpm 220pack.vhd 220model.vhd
vcom -work altera_mf altera_mf_components.vhd altera_mf.vhd
vcom -work sgate sgate_pack.vhd sgate.vhd
vcom -work stratixiv stratixiv_atoms.vhd stratixiv_components.vhd
vcom -work stratixiv_hssi stratixiv_hssi_atoms.vhd \
stratixiv_hssi_components.vhd
vcom -work work <my design>.vho <my testbench>.vhd
vsim -L lpm -L altera_mf -L sgate -L stratixiv -L stratixiv_hssi\
work.<my testbench> -t ps\
-sdftyp <design instance>=<path to SDO file>.sdo \
+transport_int_delays +transport_path_delays
Performing Gate-Level Timing Simulation in Verilog HDL
Type the commands in Example 5–12 to compile and simulate the design.
Example 5–12.
vlog -work lpm_ver 220model.v
vlog -work altera_mf_ver altera_mf.v
vlog -work sgate_ver sgate.v
vlog -work stratixiv_ver stratixiv_atoms.v
vlog -work stratixiv_hssi_ver stratixiv_hssi_atoms.v
vlog -work work <my design>.vo <my testbench>.v
vsim -L lpm_ver -L altera_mf_ver -L sgate_ver -L stratixiv_ver -L
stratixiv_hssi_ver \
work.<my testbench> -t ps +transport_int_delays +transport_path_delays
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
5–16
Chapter 5: Aldec Active-HDL and Riviera-PRO Support
Simulating Designs that Include Transceivers
Functional Simulation for Stratix V GX Devices
Functional simulation for Stratix V devices is similar to functional simulation for
Arria II, Cyclone IV, HardCopy IV, and Stratix IVdevices.
The following example shows only the functional simulation for designs that include
transceivers in Stratix V devices. To simulate transceivers in Arria II, Cyclone IV,
HardCopy IV, and Stratix V devices, replace the stratixv_hssi model file with the
arriaii_hssi, cycloneiv_hssi, hardcopyiv_hssi, and stratixiv_hssi model files,
respectively.
1
The transceiver module from the MegaWizard Plug-In Manager is created in
Interfaces/Transceiver PHY. Select Custom PHY.
Performing Functional Simulation in VHDL
Type the commands in Example 5–13 to compile and simulate the design.
Example 5–13.
vcom -work altera_mf altera_mf_components.vhd altera_mf.vhd
vcom -work lpm 220pack.vhd 220model.vhd
vcom -work sgate sgate_pack.vhd sgate.vhd
vlog +v2k –work stratixv_hssi \
quartus/eda/sim_lib/aldec/stratixv_hssi_atoms_ncrypt.v
vcom -work stratixv_hssi stratixiv_hssi.vhd \
stratixiv_hssi_components.vhd
vcom -work work <my design>.vhd
vsim -L lpm -L altera_mf -L sgate -L stratixv_hssi work.<my testbench>
Performing Functional Simulation in Verilog HDL
Type the commands in Example 5–14 to compile and simulate the design.
Example 5–14.
vlib work
vlib lpm_ver
vlib altera_mf_ver
vlib sgate_ver
vlib stratixv_hssi_ver
vlog -work lpm_ver 220model.v
vlog -work altera_mf_ver altera_mf.v
vlog -work sgate_ver sgate.v
vlog +v2k –work stratixv_hssi \
quartus/eda/sim_lib/aldec/stratixv_hssi_atoms_ncrypt.v
vlog -work stratixv_hssi_ver stratixiv_hssi_.v
vlog -work work <my design>.v
vsim -L lpm_ver -L altera_mf_ver -L sgate_ver \
-L stratixv_hssi_ver work.<my testbench>
1
The stratixv_hssi model file references the lpm and sgate libraries. You must create
these libraries to perform a simulation.
1
In addition to the top-level variant wrapper, <variant>.v, you also get a simulation
files subdirectory, <variant>_sim/. All Verilog (.v) and SystemVerilog (.sv) files in the
simulation directory must also be compiled into the simulation project.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 5: Aldec Active-HDL and Riviera-PRO Support
Using the NativeLink Feature in Active-HDL or Riviera-PRO Software
5–17
Transport Delays
By default, the Active-HDL or Riviera-PRO software filters out all pulses that are
shorter than the propagation delay between primitives. Turning on the transport delay
options in the Active-HDL or Riviera-PRO software prevents the simulation tool from
filtering out these pulses. Use the following options to ensure that all signal pulses are
visible in the simulation results:
■
+transport_path_delays
Use this option when the pulses in your simulation may be shorter than the delay
within a gate-level primitive.
■
+transport_int_delays
Use this option when the pulses in your simulation may be shorter than the
interconnect delay between gate-level primitives.
1
f
The +transport_path_delays and +transport_int_delays options are also used by
default in the NativeLink feature for gate-level timing simulation.
For more information about either of these options, refer to the Active-HDL online
documentation installed with the Active-HDL software.
Example 5–15 shows an Active-HDL software command in command-line syntax to
perform a gate-level timing simulation with the device family library.
Example 5–15.
vsim -t 1ps -L stratixii -sdftyp /i1=filtref_vhd.sdo \
work.filtref_vhd_vec_tst +transport_int_delays +transport_path_delays
Using the NativeLink Feature in Active-HDL or Riviera-PRO Software
The NativeLink feature in the Quartus II software facilitates the seamless transfer of
information between the Quartus II software and EDA tools and allows you to run the
Active-HDL or Riviera-PRO software within the Quartus II software.
f
For more information, refer to the “Using the NativeLink Feature” section in the
Simulating Designs with EDA Tools chapter in volume 3 of the Quartus II Handbook.
Generating .vcd Files for the PowerPlay Power Analyzer
To generate a Value Change Dump File (.vcd) for the PowerPlay power analyzer, you
must first generate a VCD script in the Quartus II software and run the VCD script from
the Active-HDL software to generate a VCD file. This VCD file can then be used by
PowerPlay for power analysis. The following instructions show you how to generate a
VCD file.
Perform the following steps to generate VCD Scripts in the Quartus II software:
1. In the Quartus II software, on the Assignments menu, click Settings. The Settings
dialog box appears.
2. In the Category list, select Simulator Settings.
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
5–18
Chapter 5: Aldec Active-HDL and Riviera-PRO Support
Scripting Support
3. On the Simulator Settings page, in the Tool name list, select Active-HDL and turn
on the Generate Value Change Dump File Script option.
4. To generate the VCD Script file, perform a full compilation.
Perform the following steps to generate a VCD file in the Active-HDL software:
1. In the Active-HDL software, before simulating your design, source the
<revision_name>_dump_all_vcd_nodes.tcl script. To source the TCL script, run the
following command before running the vsim command:
source <revision_name>_dump_all_vcd_nodes.tcl r
2. Continue to run the simulation until the simulation is completed. Exit the
Active-HDL software. If you do not exit the software, the Active-HDL software
may end the writing process of the VCD files improperly, resulting in a corrupted
VCD file.
f
For more details about using the VCD file for power analysis, refer to the PowerPlay
Power Analysis chapter in volume 3 of the Quartus II Handbook.
Scripting Support
You can run procedures and create settings described in this chapter in a Tcl script.
You can also run some procedures at the command-line prompt.
f
For more information about Tcl scripting, refer to the Tcl Scripting chapter in volume 2
of the Quartus II Handbook.
f
For more information about command-line scripting, refer to the Command-Line
Scripting chapter in volume 2 of the Quartus II Handbook.
f
For detailed information about scripting command options, refer to the Qhelp
command line and Tcl API help browser.
To start the Qhelp help browser, type the following command:
quartus_sh -qhelp r
Generating a Post-Synthesis Simulation Netlist for Active-HDL or Riviera-PRO
You can use the Quartus II software to generate a post-synthesis simulation netlist
with Tcl commands or with a command at the command-line prompt. The following
examples assume you are selecting Active-HDL or Riviera-PRO (Verilog HDL output
from the Quartus II software).
Tcl Commands
Use the following Tcl commands to set the output format to Verilog HDL, the
simulation tool to Active-HDL or Riviera-PRO for Verilog HDL, and to generate a
functional netlist:
set_global_assignment-name EDA_SIMULATION_TOOL "Active-HDL(Verilog)" r
set_global_assignment-name EDA_GENERATE_FUNCTIONAL_NETLIST ON r
or
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 5: Aldec Active-HDL and Riviera-PRO Support
Conclusion
5–19
set_global_assignment-name EDA_SIMULATION_TOOL "Riviera-PRO (Verilog)" r
set_global_assignment-name EDA_GENERATE_FUNCTIONAL_NETLIST ON r
Command Line
Use the following command to generate a simulation output file for the Active-HDL or
Riviera-PRO software. Specify VHDL or Verilog HDL for the format:
quartus_eda <project name> --simulation=on --format=<format> \
--tool=activehdl --functional r
or
quartus_eda <project name> --simulation=on --format=<format> \
--tool=rivierapro --functional r
Generating a Gate-Level Timing Simulation Netlist for Active-HDL or Riviera-PRO
You can use the Quartus II software to generate a gate-level timing simulation netlist
with Tcl commands or with a command at the command prompt.
Tcl Commands
Use one of the following Tcl commands:
set_global_assignment -name EDA_SIMULATION_TOOL "Active-HDL (Verilog)" r
set_global_assignment -name EDA_SIMULATION_TOOL "Active-HDL (VHDL)" r
or
set_global_assignment -name EDA_SIMULATION_TOOL "Riviera-PRO (Verilog)" r
set_global_assignment -name EDA_SIMULATION_TOOL "Riviera-PRO (VHDL)" r
Command Line
Generate a simulation output file for the Active-HDL or Riviera-PRO software by
specifying VHDL or Verilog HDL for the format by typing the following command at
the command prompt:
quartus_eda <project name> --simulation=on --format=<format> \
--tool=activehdl r
or
quartus_eda <project name> --simulation=on --format=<format> \
--tool=rivierapro r
Conclusion
Using the Active-HDL or Riviera-PRO simulation software within the Altera FPGA
design flow allows you to easily and accurately perform functional simulations,
post-synthesis simulations, and gate-level timing simulations on your designs. Proper
verification of designs at the functional, post-synthesis, and post place-and-route stages
using the Active-HDL or Riviera-PRO software helps ensure your design functions
correctly and, ultimately, a quick time-to-market.
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
5–20
Chapter 5: Aldec Active-HDL and Riviera-PRO Support
Document Revision History
Document Revision History
Table 5–1 shows the revision history for this chapter.
Table 5–1. Document Revision History
Date
Version
July 2010
10.0.0
November 2009
March 2009
9.1.0
9.0.0
November 2008
May 2008
8.1.0
8.0.0
Changes Made
■
Linked to Quartus II Help
■
Revised simulation procedures
■
Added Stratix V simulation information
■
Added Riviera-PRO support
■
Minor text edits
■
Removed Referenced Documents section
■
Updated Table 6–1
■
Removed Simulation Library tables and EDA Simulation Library Compiler sections and
referenced new Simulating Designs with EDA Tools chapter
■
Added “RTL Functional Simulation for Stratix IV Devices” and “Gate-Level Timing
Simulation for Stratix IV Devices” sections
■
Minor text edits
■
Removed “Compile Libraries Using the Altera Simulation Library Compiler”
■
Added “Compile Libraries Using the EDA Simulation Library Compiler” on page 5–10
■
Added “Generate Simulation Script from EDA Netlist Writer” on page 5–51
■
Minor editorial updates
Added the following sections:
■
“Compile Libraries Using the Altera Simulation Library Compiler” on page 5–10
■
Added steps to the procedure “Performing an RTL Simulation Using NativeLink” on
page 5–45 for using the Altera Simulation Library Compilation
■
Added steps to the procedure “Performing a Gate-Level Timing Simulation Using
NativeLink” on page 5–47 for using the Altera Simulation Library Compilation
■
Minor editorial updates
■
Updated entire chapter using 8½” × 11” chapter template
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.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
6. Simulating Altera IP in Third-Party
Simulation Tools
QII53014-10.0.1
This chapter describes the process for instantiating the IP megafunctions in your
design and simulating their functional simulation models in Altera-supported,
third-party simulation tools.
The capacity and complexity of Altera® FPGAs continues to increase as the need for
intellectual property (IP) becomes increasingly critical. Using IP megafunctions
reduces overall design and verification time, allowing you to focus on design
customization. Altera and the Altera Megafunction Partners Program (AMPPSM) offer
a broad portfolio of IP megafunctions optimized for Altera FPGAs. Through
parameterization, these reusable IP blocks can be customized to meet your design
requirements.
Even when the IP source code is encrypted or otherwise restricted, Altera’s
Quartus® II software allows you to easily simulate designs that contain Altera IP. With
the Quartus II software, you can custom configure IP designs, then generate a VHDL
or Verilog HDL functional simulation model to use with your choice of simulation
tools.
In this chapter, IP megafunctions refer to Altera megafunctions, IP MegaCore®
functions, and IP AMPP megafunctions.
Altera IP megafunctions support both Verilog and VHDL simulation. The manner in
which dual-language simulation is supported for specific megafunctions might differ.
Simulation models may be provided as:
■
Plain text VHDL
■
Plain text Verilog
■
IP Functioal Simulation (IPFS) models in both VHDL and Verilog
■
IEEE 1364-2005 encrypted Verilog
When IEEE 1364-2005 encrypted Verilog models are provided, there is a separate
model for each Altera-supported simulator. You need a simulator that is capable of
VHDL/Verilog co-simulation if you want to simulate the model in a VHDL design.
Some AMPP megafunctions might also use IPFS models for functional simulation.
© August 2010
1
An IPFS model is a cycle-accurate VHDL or Verilog HDL model produced by the
Quartus II software. The model allows for fast functional simulation of IP using
industry-standard VHDL and Verilog HDL simulators.
c
Use IPFS models for simulation only. Do not use them for synthesis or any other
purpose. Using these models for synthesis results in a nonfunctional design.
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
6–2
Chapter 6: Simulating Altera IP in Third-Party Simulation Tools
IP Functional Simulation Flow
This chapter discusses the following topics:
■
“IP Functional Simulation Flow”
■
“Instantiate the IP in Your Design” on page 6–4
■
“Perform Functional Simulation” on page 6–4
■
“Design Language Examples” on page 6–6
IP Functional Simulation Flow
The IP megafunction’s MegaWizard™ interface allows you to quickly and easily view
documentation, specify parameters, generate a simulation model, and output the files
necessary to integrate a parameterized IP megafunction into your design. Within the
Quartus II software, you can use the MegaWizard Plug-In Manager to select and
parameterize your choice of IP megafunctions. The Quartus II software generates an
IP megafunction’s variation file that is included in your Quartus II project. For IP
megafunctions that use IPFS models, the Quartus II software can also generate a
Verilog HDL Output File (.vo) or VHDL Output File (.vho) that contains an IPFS
model after you have parameterized the megafunction. IPFS models are written to the
Quartus II project directory.
Most Altera megafunctions and IP MegaCore functions support functional simulation
in Verilog HDL and VHDL for all Altera-supported third-party simulators.
Simulation libraries are required to simulate IP megafunctions.
f
For a list of the RTL functional simulation library files in the Quartus II project
directory, refer to Altera Functional Simulation Libraries in Quartus II Help.
f
For a list of the gate-level timing simulation library files in the Quartus II project
directory, refer to Altera Post-Fit Libraries in Quartus II Help.
Figure 6–1 shows a typical simulation flow for Altera IP with third-party simulators.
Quartus II Handbook Version 10.0 Volume 3: Verification
© August 2010 Altera Corporation
Chapter 6: Simulating Altera IP in Third-Party Simulation Tools
IP Functional Simulation Flow
6–3
Figure 6–1. IPFS Model Design Flow
Parameterize IP Megafunction
Generate Simulation Model
and Variation File
Quartus II Design Environment
Instantiate IP in your Design
Simulation
Libraries
Perform Simulation in an
Altera-Supported VHDL/Verilog HDL
Simulator
Verilog HDL and VHDL IPFS Models
Some IP megafunctions use IPFS models for functional simulation. The IPFS models
in Verilog HDL or VHDL format differ from the low-level synthesized netlist in
Verilog HDL or VHDL format generated by the Quartus II software for post-synthesis
or post place-and-route simulations. The IPFS models generated by the Quartus II
software are much faster than the low-level post-synthesis or post place-and-route
netlists of your design because they are mapped to higher-level primitives such as
adders, multipliers, and multiplexers. These IPFS models can be simulated together
with the rest of your design in any Altera-supported simulator. Altera recommends
that you generate IPFS models in the same hardware language as the IP
megafunction’s variation file hardware language.
Simulator-independent IPFS primitives are located in the quartus/eda/sim_lib
directory.
For Stratix V transceiver devices, IEEE 1364-2005 encrypted simulator-dependent RTL
models are located in the following directories:
quartus/eda/sim_lib/mentor
quartus/eda/sim_lib/synopsys
quartus/eda/sim_lib/aldec
quartus/eda/sim_lib/cadence
1
© August 2010
Generating an IPFS model for Altera MegaCore functions does not require a license.
However, generating an IPFS model for AMPP megafunctions may require a license.
For more information about licensing requirements, contact the IP megafunction
vendor.
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
6–4
Chapter 6: Simulating Altera IP in Third-Party Simulation Tools
Instantiate the IP in Your Design
1
If you want to simulate an IEEE 1364-2005 encrypted model in a VHDL design, you
will need a simulator that supports VHDL/Verilog co-simulation.
f
For details about how to parameterize and generate an IP, refer to the applicable IP
user guide.
Instantiate the IP in Your Design
For each IP megafunction in your design, you must instantiate the corresponding
entity or module in your design. Each IP megafunction entity or module name is
defined in its Quartus II-generated megafunction variation file.
For information about instantiating IP megafunctions, refer to the Megafunction
Overview User Guide.
f
For information about synthesis and compilation with the Quartus II software, refer
to the applicable chapters in Volume 1: Design Synthesis of the Quartus II Handbook.
Perform Functional Simulation
To perform functional simulation, in addition to adding your design files and
testbench files, you also have to add the IP megafunction’s variation file and other
appropriate IP simulation files and model libraries to your simulation project. If the IP
megafunction you are simulating requires an IPFS model, add the IPFS model to your
simulation project. Your simulation project also requires Altera-supplied libraries for
successful simulation.
f
The IP that uses the transceiver requires the Altera transceiver libraries for simulation.
Refer to Altera Functional Simulation Libraries in Quartus II Help.
f
The PCI Express (PCIe) hard IP core in a Stratix IV device requires the PCIe libraries
for simulation. Refer to Altera Functional Simulation Libraries in Quartus II Help.
The Quartus II software contains all the libraries required for setting up and running a
successful simulation of Altera IP. If the IP megafunction you are using supports the
Quartus II NativeLink feature, it is easy to use the NativeLink feature to set up your
simulation. However, you can also simulate Altera IP directly with third-party
simulators. Refer to the applicable IP megafunction user guide to determine whether
the NativeLink feature is supported.
Simulating Altera IP Using the Quartus II NativeLink Feature
The Quartus II NativeLink feature eases the tasks of setting up and running a
simulation. The NativeLink feature lets you launch the third-party simulator to
perform simulation from within the Quartus II software. The NativeLink feature
automates the compilation and simulation of testbenches.
Before running the simulation, you must open your Quartus II project and perform
Analysis and Elaboration, as described in the following section.
Quartus II Handbook Version 10.0 Volume 3: Verification
© August 2010 Altera Corporation
Chapter 6: Simulating Altera IP in Third-Party Simulation Tools
Perform Functional Simulation
6–5
Perform Analysis and Elaboration on Your Design
To perform Analysis and Elaboration on your design, on the Quartus II Processing
menu, point to Start, then click Start Analysis & Elaboration.
If you are using the Quartus II NativeLink feature and your Quartus II project
contains IP megafunctions that require IPFS models for simulation, you do not have
to manually add the IPFS models to the Quartus II project for these IP megafunctions.
When the Quartus II NativeLink feature launches the third-party simulator tool and
starts the simulation, it automatically adds the IPFS model files required for
simulation if they are present in the Quartus II project directory.
You can now continue the simulation process using the NativeLink feature.
Run Simulation Using the Quartus II NativeLink Feature
f
For detailed information about using the NativeLink feature to simulate Altera IP,
refer to the Simulating Designs with EDA Tools chapter in volume 3 of the Quartus II
Handbook.
Simulating Altera IP Without the Quartus II NativeLink Feature
You can also simulate Altera IP directly with third-party simulators. If your design
instantiates an IP megafunction, add its variation file to your simulation project. If the
IP megafunction requires IPFS model files, do not add the megafunction’s variation
file to your simulation project. Instead, add its IPFS model files (either Verilog HDL or
VHDL) to your simulation project. The IPFS model generated by the Quartus II
software instantiates high-level primitives such as adders, multipliers, and
multiplexers, as well as the library of parameterized modules (LPM) functions and
Altera megafunctions.
To properly compile, load, and simulate the IP megafunctions, you must first compile
the following libraries in your simulation tool:
■
sgate—includes the definition of the high-level primitives (needed for IPFS
models)
■
altera_mf—includes the definition of Altera megafunctions
■
altera_primitives—includes the definition of Altera primitives
■
220model—includes the definition of LPM functions
■
Altera transceiver—includes the definition of all Altera transceiver
megafunctions. If you use the transceiver block, you must compile these libraries,
which are device dependent.
■
PCIe—includes the definition of PCI Express hard IP megafunctions for Arria II,
Cyclone IV, HardCopy IV, Stratix IV, and Stratix V devices. If you use IP with the
PCI Express hard IP for Stratix IV devices, you must compile these libraries.
You can use these library files with any Altera-supported simulation tool. If you are
using the ModelSim-Altera software, the libraries are precompiled and mapped, and
no compilation is required.
© August 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
6–6
Chapter 6: Simulating Altera IP in Third-Party Simulation Tools
Design Language Examples
Using the EDA Simulation Library Compiler
You can also compile these libraries with the EDA Simulation Library Compiler. The
benefit of using this tool is that all of the required libraries are automatically compiled
for your simulation use.
f
For more information about the EDA Simulation Library Compiler, refer to the section
“EDA Simulation Library Compiler” in the Simulating Designs with EDA Tools chapter
in volume 3 of the Quartus II Handbook.
Design Language Examples
The following design language examples explain how to simulate IP megafunctions
directly with third-party simulator tools. These design examples describe simulation
with ModelSim SE software.
Verilog HDL Example: Simulating the IPFS Model in the ModelSim SE Software
The following example shows the process of simulating a Verilog HDL-based
megafunction. The example assumes that the megafunction variation and the IPFS
model are generated.
1. To create a ModelSim project, perform the following steps:
a. In the ModelSim software, on the File menu, point to New and click Project.
The Create Project dialog box appears.
b. Specify the name of your simulation project.
c. Specify the desired location for your simulation project.
d. Specify the default library name and click OK.
e. Add relevant files to your simulation project:
■
Your design files.
■
The IPFS model generated by the Quartus II software. (If you are using the
ModelSim-Altera software, skip to step 5.)
1
f
If you are using the EDA Simulation Library Compiler, skip to step 3.
■
The sgate.v, 220model.v, and altera_mf.v library files.
■
The transceiver library files in Verilog HDL, if you use IP with transceivers.
Transceiver libraries are family specific.
■
The PCIe library files in Verilog HDL, if you use IP with the PCIe hard core
for Arria II, Cyclone IV, HardCopy IV, Stratix IV, and Stratix V devices.
For a list of the RTL functional simulation library files in the Quartus II directory, refer
to Altera Functional Simulation Libraries in Quartus II Help.
Quartus II Handbook Version 10.0 Volume 3: Verification
© August 2010 Altera Corporation
Chapter 6: Simulating Altera IP in Third-Party Simulation Tools
Design Language Examples
6–7
2. To create the required simulation libraries, type the following commands at the
ModelSim prompt:
vlib sgate r
vlib lpm r
vlib altera_mf r
vlib <family>_hssi r
(If you use transceivers)
vlib <family>_pcie_hip r
(If you use PCI Express hard IP)
3. Map to the required simulation libraries by typing the following commands at the
ModelSim prompt:
vmap sgate sgate r
vmap lpm lpm r
vmap altera_mf altera_mf r
vmap <family>_hssi <family>_hssi r
(If you use transceivers)
vmap <family>_pcie_hip <family>_pcie_hip r
1
(If you use PCI Express hard IP)
If you are using the EDA Simulation Library Compiler, skip to step 5.
4. Compile the HDL into libraries by typing the following commands at the
ModelSim prompt:
vlog -work altera_mf altera_mf.v r
vlog -work sgate sgate.v r
vlog -work lpm 220model.v r
vlog -work <family>_hssi <family>_hssi_atoms.v r
(If you use transceivers)
vlog -work <family>_pcie_hip <family>_pcie_hip_atoms.v r
(If you use PCI
Express hard IP)
vlog -work <family>_hssi <Quartus_installation_directory> \
/eda/sim_lib/mentor/stratixv_hssi_atoms.v r
(For Stratix V devices)
vlog -work <family>_pcie_hip <Quartus_installation_directory> \
(For Stratix V devices)
/eda/sim_lib/mentor/stratixv_pcie_hip_atoms.v r
5. Compile the IPFS model by typing the following command at the ModelSim
prompt:
vlog -work work <my_IP>.vo r
6. Compile the RTL by typing the following command at the ModelSim prompt:
vlog -work work <my_design>.v r
7. Compile the testbench by typing the following command at the ModelSim
prompt:
vlog -work work <my_testbench>.v r
8. Load the testbench by typing the following command at the ModelSim prompt:
vsim -L altera_mf -L lpm -L sgate -L <family>_pcie_hip \
work.<my_testbench> r
© August 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
6–8
Chapter 6: Simulating Altera IP in Third-Party Simulation Tools
Design Language Examples
VHDL Example: Simulating the IPFS Model in the ModelSim SE Software
The following example shows how to perform a functional simulation of a
VHDL-based, megafunction IPFS model. The example assumes that the megafunction
variation and the IPFS model are generated.
1
If you want to simulate an IEEE 1364-2005 encrypted model in a VHDL design, you
need a simulator that supports VHDL/Verilog co-simulation.
1. Create a ModelSim project by performing the following steps:
a. In the ModelSim software, on the File menu, point to New and click Project.
The Create Project dialog box appears.
b. Specify the name for your simulation project.
c. Specify the desired location for your simulation project.
d. Specify the default library name and click OK.
e. Add the relevant files to your simulation project:
■
Your design files
■
The IPFS model generated by the Quartus II software (if you are using the
ModelSim-Altera software, skip to step 5)
■
The sgate.vhd, sgate_pack.vhd, 220model.vhd, 220pack.vhd,
altera_mf.vhd, and altera_mf_components.vhd library files
■
The transceiver library files in VHDL, if you use IP with transceivers.
Transceiver libraries are family specific.
The PCIe library files in VHDL, if you use IP with the PCI Express hard IP
for Stratix V, Stratix IV, HardCopy IV, Arria II, and Cyclone IV devices.
■
f
For a list of the RTL functional simulation library files in the Quartus II directory, refer
to Altera Functional Simulation Libraries in Quartus II Help.
2. Create the required simulation libraries by typing the following commands at the
ModelSim prompt:
vlib sgate r
vlib lpm r
vlib altera_mf r
vlib <family>_hssi r
(If you use transceivers)
vlib <family>_pcie_hip r
(If you use PCI Express hard IP)
3. Map to the required simulation libraries by typing the following commands at the
ModelSim prompt:
vmap sgate sgate r
vmap lpm lpm r
vmap altera_mf altera_mf r
vmap <family>_hssi <family>_hssi r
(If you use transceivers)
vmap <family>_pcie_hip <family>_pcie_hip r
Quartus II Handbook Version 10.0 Volume 3: Verification
(If you use PCI Express hard IP)
© August 2010 Altera Corporation
Chapter 6: Simulating Altera IP in Third-Party Simulation Tools
Conclusion
6–9
4. Compile the HDL into libraries by typing the following commands at the
ModelSim prompt:
vlog -work <family>_hssi <Quartus_installation_directory> \
/eda/sim_lib/mentor/<family>_hssi_atoms.v r
(For Stratix V devices)
vlog -work <family>_pcie_hip <Quartus_installation_directory> \
(For Stratix V devices)
/eda/sim_lib/mentor/<family>_pcie_hip_atoms.v r
vcom -work altera_mf -93 -explicit altera_mf_components.vhd r
vcom -work altera_mf -93 -explicit altera_mf.vhd r
vcom -work lpm -93 -explicit 220pack.vhd r
vcom -work lpm -93 -explicit 220model.vhd r
vcom -work sgate -93 -explicit sgate_pack.vhd r
vcom -work sgate -93 -explicit sgate.vhd r
vcom -work <family>_hssi -93 -explicit <family>_hssi_atoms.vhd r
(If you use transceivers)
vcom -work <family>_hssi -93 -explicit <family>_hssi_components.vhd r
vcom -work <family>_pcie_hip -93 <family>_pcie_hip_atoms.vhd r
(If you use PCI Express hard IP)
vcom -work <family>_pcie_hip -93 <family>_pcie_hip_components.vhd r
5. Compile the IPFS model by typing the following command at the ModelSim
prompt:
vcom -work work -93 -explicit <output_netlist>.vho r
6. Compile the RTL by typing the following command at the ModelSim prompt:
vcom -work work -93 -explicit <RTL>.vhd r
7. Compile the testbench by typing the following command at the ModelSim prompt:
vcom -work work -93 -explicit <my_testbench>.vhd r
8. Load the testbench by typing the following command at the ModelSim prompt:
vsim work.my_testbench r
Conclusion
The Quartus II software enables you to simulate IP megafunctions with third-party
tools either directly or using its NativeLink feature. Using the Quartus II software, you
can also generate IPFS models for supported megafunctions that enhance and simplify
design verification. Using an IPFS model is transparent, requiring only the addition of
different files in which to synthesize and simulate projects.
© August 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
6–10
Chapter 6: Simulating Altera IP in Third-Party Simulation Tools
Document Revision History
Document Revision History
Table 6–1 shows the revision history for this chapter.
Table 6–1. Document Revision History
Date
Version
Changes Made
August 2010
10.0.1
Corrected links
July 2010
10.0.0
■
Linked Altera Functional Simulation Libraries and Altera Post-Fit Libraries to Quartus II
Help
■
Updated to add directories and information about simulator-dependent IPFS model
simulation files
■
Removed Referenced Documents section
■
Removed most NativeLink information
■
Added references to new chapter Simulating Designs with EDA Tools and Megafunction
Overview User Guide
■
Minor text edits
November 2009
9.1.0
March 2009
9.0.0
Removed figures.
November 2008
8.1.0
Changed to 8-1/2 x 11 page size. No change to content.
May 2008
8.0.0
■
Updated “Introduction.”
■
Updated “Simulating Altera IP without the Quartus II NativeLink Feature.”
■
Updated “Verilog HDL Example: Simulating the IPFS Model in the ModelSim Software.”
■
Updated “VHDL Example: Simulating the IPFS Model in the ModelSim Software.”
■
Updated Figure 6–2.
■
Updated Table 6–1.
■
Updated Table 6–2.
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 10.0 Volume 3: Verification
© August 2010 Altera Corporation
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 7, 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 8, 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 9, 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 10, Quartus II Classic Timing Analyzer
This chapter describes the Qurtus II Classic Timing Analyzer. Tcl commands are
presented throughout this chapter to describe the alternative methods for making
timing analysis assignments.
■
Chapter 11, 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.
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
II–2
Quartus II Handbook Version 10.0 Volume 3: Verification
Section II: Timing Analysis
© July 2010 Altera Corporation
7. The Quartus II TimeQuest
Timing Analyzer
QII53018-10.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 timing analyzer’s GUI or command-line interface to constrain, analyze,
and report results for all timing paths in your design.
Before running the TimeQuest timing analyzer, you must specify initial timing
constraints that describe the clock characteristics, timing exceptions, and signal
transition arrival and required times. You can specify timing constraints in the
Synopsys Design Constraints (.sdc) file format using the GUI or command-line
interface. The Quartus II Fitter optimizes the placement of logic to meet your
constraints.
During timing analysis, the TimeQuest timing 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 slack in the Report pane and in the
Console pane. If the TimeQuest timing analyzer reports any timing violations, you
can customize the reporting to view precise timing information about specific paths,
and then constrain those paths to correct the violations. When your design is free of
timing violations, you can be confident that the logic will operate as intended in the
target device.
This chapter contains the following sections:
© July 2010
■
“Getting Started with the TimeQuest Timing Analyzer” on page 7–2
■
“Running the TimeQuest Timing Analyzer” on page 7–3
■
“Timing Analysis Overview” on page 7–5
■
“The Timing Netlist” on page 7–8
■
“Clock Specification” on page 7–23
■
“Collections” on page 7–20
■
“I/O Specifications” on page 7–35
■
“Timing Exceptions” on page 7–39
■
“Constraint and Exception Removal” on page 7–43
■
“Timing Reports” on page 7–43
■
“Other Features” on page 7–57
■
“Conclusion” on page 7–63
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
7–2
Chapter 7: The Quartus II TimeQuest Timing Analyzer
Getting Started with the TimeQuest Timing Analyzer
Getting Started with the TimeQuest Timing Analyzer
The TimeQuest timing analyzer caters to the needs of the most basic to the most
advanced designs for FPGAs.
This section provides a brief overview of the TimeQuest timing analyzer, including
the necessary steps to properly constrain a design, perform a full place-and-route, and
perform reporting on the design. Figure 7–1 shows the recommended design flow
steps to maximize and leverage the benefits the TimeQuest timing analyzer. Details
about each step are provided after the figure.
Figure 7–1. 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
■
Create Quartus II Project and Specify Design Files—In this step you specify the
target FPGA, any EDA tools used in the design cycle, and all design files.
You can also modify existing design files for design optimization and add
additional design files. For example, you can add HDL files or schematics to the
project.
■
Perform Initial Compilation—In this step you create an initial design database
before you specify timing constraints for your design. 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 for the initial compilation is faster than creating a
post-fit database. A post-map database is sufficient for the initial database.
Creating a post-fit database is recommended only if you previously created and
specified an .sdc file for the project. A post-map database is sufficient for the initial
compilation.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 7: The Quartus II TimeQuest Timing Analyzer
Running the TimeQuest Timing Analyzer
■
7–3
Specify Timing Requirements—In this step you specify timing requirements to
guide the Fitter as it places and routes your design.
You must enter all timing constraints and exceptions in an .sdc file. This file must
be included as part of the project. To add this file to your project, on the Project
menu, click Add/Remove Files in Project and add the .sdc file in the Files dialog
box.
■
Perform Compilation—In this step you compile your design. When compilation is
complete, the TimeQuest timing analyzer generates summary clock setup and
clock hold, recovery, and removal reports for all defined clocks in the design.
■
Verify Timing—In this step, you verify timing in your design with the TimeQuest
timing analyzer.
Running the TimeQuest Timing Analyzer
You can run the TimeQuest timing analyzer in one of the following ways:
■
Directly from the Quartus II GUI
■
As a stand-alone GUI application
■
At a system command prompt
This section describes each of the modes, and the behavior of the TimeQuest timing
analyzer.
Running the TimeQuest Timing Analyzer from the Quartus II GUI
To run the TimeQuest timing analyzer from the Quartus II software, on the Tools
menu, click TimeQuest Timing Analyzer. When you launch the TimeQuest timing
analyzer from the Quartus II software, the current project is open by default.
The TimeQuest timing analyzer is available after you have created a post-fit or
post-map database for the current project. After a database is created, you can create a
timing netlist based on that database. You can only create a post-fit timing netlist in
the TimeQuest timing analyzer if you have created a post-fit database for your project.
Use the TimeQuest timing analyzer Wizard to enter basic, initial constraints for your
design, if none already exist. The wizard allows you to create clock, tSU, tH, tCO, and tPD
constraints and save those constraints in an SDC file. To start the wizard, on the
Assignments menu click TimeQuest Timing Analyzer Wizard.
f
© July 2010
For complete information about the TimeQuest timing analyzer GUI, refer to About the
TimeQuest Timing Analyzer in Quartus II help.
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
7–4
Chapter 7: The Quartus II TimeQuest Timing Analyzer
Running the TimeQuest Timing Analyzer
Running the TimeQuest Timing Analyzer as a Stand-Alone Application
To run the TimeQuest timing analyzer as a stand-alone GUI application, type the
following command at the command prompt:
quartus_staw r
In stand-alone mode, you can perform static analysis on any project that contains
either a post-map or post-fit database. To open a project, double-click Open Project in
the Tasks pane.
Running the quartus_sta Executable at a System Command Prompt
Use the command-line executable, quartus_sta, for easy integration with scripted
design flows. Table 7–1 provides a summary of the options available in the
command-line mode.
Table 7–1. 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>.
--do_report_timing
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
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
Synopsys Design Constraints File format.
--sdc=<SDC file>
Specifies the .sdc file to read.
--report_script=<script> Specifies a custom report script to be called.
--speed=<value>
Specifies the device speed grade to be used for timing analysis.
--tq2hc
Generate temporary files to convert the TimeQuest Timing Analyzer .sdc file(s) to a
PrimeTime .sdc file that can be used by the HardCopy Design Center (HCDC).
--tq2pt
Generates temporary files to convert the TimeQuest Timing Analyzer .sdc file(s) to a
PrimeTime .sdc file.
-f <argument file>
Specifies a file containing additional command-line arguments.
-c <revision name> |
--rev=<revision_name>
Specifies which revision and its associated Quartus II Settings File (.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 analysis by using the off value.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 7: The Quartus II TimeQuest Timing Analyzer
Timing Analysis Overview
7–5
Table 7–1. Summary of Command Line Options (Part 2 of 2)
Command Line Option
Description
--voltage=<value_in_mV>
Specifies the device voltage (mV) to be used in timing analysis.
--temperature=
<value_in_C>
Specifies the device temperature (C) to be used in timing analysis.
--parallel
[=<num_processors>]
Specifies the number of computer processors to use on a multi-processor system.
--64bit
Enables 64-bit version of the executable.
To run the TimeQuest timing analyzer in command-line mode, type the following
command at the command prompt:
quartus_sta <options> r
The TimeQuest timing analyzer also includes the Tcl packages ::quartus::sta,
::quartus::sdc, and ::quartus::sta_ext for constraining and analyzing
designs from Tcl scripts, or for use interactively with the -s and --tcl_eval options
for quartus_sta.
f
For more information about using Tcl commands to constrain and analyze your
design, refer to API functions for Tcl in Quartus II Help. For a demonstration of
interactive timing analysis, refer to the TimeQuest Quick Start Tutorial.
Timing Analysis Overview
This section provides an overview of TimeQuest timing analyzer concepts.
Understanding these concepts allows you to take advantage of the powerful timing
analysis features available in the TimeQuest timing analyzer.
The TimeQuest timing analyzer follows the flow shown in Figure 7–2 when it
analyzes your design, including the most commonly used Tcl commands for each
step.
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
7–6
Chapter 7: The Quartus II TimeQuest Timing Analyzer
Timing Analysis Overview
Figure 7–2. 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
The following sections describe each of the steps shown in Figure 7–2.
Open the Project
Open the project in the Quartus II software or the stand-alone GUI version. In a fully
scripted timing analysis flow, the project must be opened at the start of the process
with the project_open command.
Create a Timing Netlist
After you perform a full compilation, create either a post-map or post-fit timing netlist
based on the fully annotated database from the post-fit results.
To create the timing netlist with Tcl, double-click Create Timing Netlist in the Tasks
pane, or use the following Tcl command:
create_timing_netlist r
Constrain the Design
After you create a timing netlist, add constraints either interactively or from an .sdc
file. To read the .sdc file for the current revision of your project, double-click Read
SDC File in the Tasks pane. To read the .sdc file interactively or from a script, use the
following Tcl command:
read_sdc r
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 7: The Quartus II TimeQuest Timing Analyzer
Timing Analysis Overview
7–7
For more information about reading .sdc files in the TimeQuest timing analyzer, refer
to “Synopsys Design Constraints File Precedence” on page 7–23.
Update Timing Netlist
You must update the timing netlist after you apply timing constraints. The TimeQuest
timing analyzer applies all constraints to the netlist for verification and removes any
invalid or false paths in the design from verification.
To update the timing netlist, double-click Update Timing Netlist in the Tasks pane, or
use the following command:
update_timing_netlist r
Generate Timing Reports
You can generate timing reports for all critical paths in your design. The Tasks pane
contains the commonly used reporting commands. Individual or custom reports can
be generated for your design.
For more information about reporting, refer to the section “Timing Reports” on
page 7–43.
As you verify timing, you may encounter failures along critical paths. If this occurs,
you 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. This iterative process allows you to resolve your timing violations
in the design.
Table 7–2 describes TimeQuest timing analyzer terminology.
Table 7–2. TimeQuest Timing Analyzer Terms
Terminology
Definition
nodes
Most basic timing netlist unit. Use to represent ports, pins, and registers.
keepers
Ports or registers. (1)
cells
Look-up table (LUT), registers, digital signal processing (DSP) blocks,
TriMatrix memory, IOE, 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 7–2:
(1) Pins can indirectly refer to keepers. For example, when the value in the -from field of a constraint is a clock pin
to a dedicated memory. In this case, the clock pin refers to a collection of registers.
(2) For Stratix® devices and other early device families, the LUT and registers are contained in logic elements (LE) and
act as cells for these device families.
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
7–8
Chapter 7: The Quartus II TimeQuest Timing Analyzer
The Timing Netlist
The Timing Netlist
The TimeQuest timing analyzer requires a timing netlist before it can perform a
timing analysis on any design. For example, for the design shown in Figure 7–3, the
TimeQuest timing analyzer generates a netlist equivalent to the one shown in
Figure 7–4.
Figure 7–3. Sample Design
reg1
data1
and_inst
reg3
reg2
data2
clk
Figure 7–4. The TimeQuest Timing Analyzer Timing Netlist
Cells
Cell
data1
combout
datain
reg1
Cell
regout
clk
and_inst
combout
datac
Pin
data2
reg2
reg3
data_out
datain
datad
regout
Port
Pin
clk
clk~clkctrl
inclk0
outclk
Figure 7–4 shows various cells, pins, nets, and ports. The following sample cell names
are included:
■
reg1
■
reg2
■
and_inst
The following sample pins names are included:
■
data1|combout
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 7: The Quartus II TimeQuest Timing Analyzer
The Timing Netlist
7–9
■
reg1|regout
■
and_inst|combout
The following net names are included:
■
data1~combout
■
reg1
■
and_inst
The following port names are included:
■
data1
■
clk
■
data_out
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 following list shows some of the commonly analyzed paths that are
described in this section:
■
Edge paths—the connections from ports-to-pins, from pins-to-pins, and from
pins-to-ports.
■
Clock paths—the edges from device ports or internally generated clock pins to the
clock pin of a register.
■
Data paths—the edges 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—the edges from a port or sequential element to the
asynchronous set or clear pin of a sequential element.
Figure 7–5 shows some of these commonly analyzed path types.
Figure 7–5. Path Types
D
Q
Clock Path
clk
D
Q
Data Path
CLRN
CLRN
Asynchronous Clear Path
rst
After the TimeQuest timing analyzer identifies the path type, it can report data and
clock arrival times at register pins. The TimeQuest timing 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-out (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 for the internal registers in the FPGA.
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
7–10
Chapter 7: The Quartus II TimeQuest Timing Analyzer
The Timing Netlist
The TimeQuest timing analyzer calculates clock arrival time by adding the delay from
the clock source to the clock pin of the destination register. Figure 7–6 shows a data
arrival path and a clock arrival path. The TimeQuest timing analyzer calculates 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 for the internal registers in
the FPGA.
Figure 7–6. Data Arrival and Clock Arrival
D
Q
D
Q
Data Arrival
Clock Arrival
In addition to identifying various paths in a design, the TimeQuest timing 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 performing this analysis.
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.
Figure 7–7 shows a single-cycle system that uses consecutive clock edges to transfer
and capture data, a register-to-register path, and the corresponding launch and latch
edges timing diagram. In this example, the launch edge sends the data out of register
reg1 at 0 ns, and register reg2 latch edge captures the data at 5 ns.
Figure 7–7. 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
The TimeQuest timing analyzer validates clock setup and hold requirements relative
to the launch and latch edges.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 7: The Quartus II TimeQuest Timing Analyzer
The Timing Netlist
7–11
Clock Analysis
A comprehensive static timing analysis includes analysis of register-to-register, I/O,
and asynchronous reset paths. The TimeQuest timing analyzer uses data required
times, data arrival times, and clock arrival times to verify circuit performance and
detect possible timing violations. The TimeQuest timing 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.
Clock Setup Check
To perform a clock setup check, the TimeQuest timing 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 timing analyzer
uses the closest previous clock edge at the source register as the launch edge. In
Figure 7–8, two setup relationships are defined and are labeled 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 7–8. Setup Check
Source Clock
Setup A
Setup B
Destination Clock
0 ns
8 ns
16 ns
24 ns
32 ns
The TimeQuest timing 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. The TimeQuest timing analyzer
determines clock setup slack, as shown in Equation 7–1, for internal
register-to-register paths.
Equation 7–1.
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 = Clock Arrival Time – t SU – Setup Uncertainty
Clock Arrival Time = Latch Edge + Clock Network Delay to Destination Register
If the data path is from an input port to a internal register, the TimeQuest timing
analyzer uses the equations shown in Equation 7–2 to calculate setup slack.
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
7–12
Chapter 7: The Quartus II TimeQuest Timing Analyzer
The Timing Netlist
Equation 7–2.
Clock Setup Slack = Data Required Time – Data Arrival Time
Data Arrival Time = Launch Edge + Clock Network Delay +
Input Maximum Delay + Pin-to-Register Delay
Data Required Time = Latch Edge + Clock Network Delay to Destination Register – t SU
If the data path is an internal register to an output port, the TimeQuest timing
analyzer uses the equations shown in Equation 7–3 to calculate the setup slack.
Equation 7–3.
Clock Setup Slack = Data Required Time – Data Arrival Time
Data Arrival Time = Launch Edge + Clock Network Delay to Source Register +
t CO + Register-to-Pin Delay
Data Required Time = Latch Edge + Clock Network Delay – Output Maximum Delay of Pin
Clock Hold Check
To perform a clock hold check, the TimeQuest timing analyzer determines a hold
relationship for each possible setup relationship that exists for all source and
destination register pairs. The TimeQuest timing analyzer checks all adjacent clock
edges from all setup relationships to determine the hold relationships. The TimeQuest
timing 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. Figure 7–9 shows two
setup relationships labeled setup A and setup B. The first hold check is labeled hold
check A1 and hold check B1 for setup A and setup B, respectively. The second hold
check is labeled hold check A2 and hold check B2 for setup A and setup B,
respectively.
Figure 7–9. Hold Checks
Source Clock
Hold
Check A1
Setup A
Hold Setup B
Hold
Check B1
Check A2
Hold
Check B2
Destination Clock
0 ns
8 ns
16 ns
24 ns
32 ns
From the possible hold relationships, the TimeQuest timing analyzer selects the hold
relationship that is the most restrictive. The hold relationship with the smallest
difference between the latch and launch edges, i.e., launch – latch, is selected because
this determines the minimum allowable delay for the register-to-register path. For
Figure 7–9, the hold relationship selected is hold check A2.
The TimeQuest timing analyzer determines clock hold slack as shown in
Equation 7–4.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 7: The Quartus II TimeQuest Timing Analyzer
The Timing Netlist
7–13
Equation 7–4.
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 = Clock Arrival Time + t H + Hold Uncertainty
Clock Arrival Time = Latch Edge + Clock Network Delay to Destination Register
If the data path is from an input port to an internal register, the TimeQuest timing
analyzer uses the equations shown in Equation 7–5 to calculate the hold slack.
Equation 7–5.
Clock Hold Slack Time = 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
If the data path is an internal register to an output port, the TimeQuest timing
analyzer uses the equations shown in Equation 7–6 to calculate the hold slack.
Equation 7–6.
Clock Hold Slack Time = 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
Recovery time is the minimum length of time for the de-assertion 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. If the asynchronous
control signal is registered, the TimeQuest timing analyzer uses Equation 7–7 to
calculate recovery slack.
Equation 7–7.
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
If the asynchronous control is not registered, the TimeQuest timing analyzer uses the
equations shown in Equation 7–8 to calculate recovery slack.
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
7–14
Chapter 7: The Quartus II TimeQuest Timing Analyzer
The Timing Netlist
Equation 7–8.
Recovery Slack Time = Data Required Time – Data Arrival Time
Data Arrival Time = Launch Edge + Clock Network Delay + Maximum Input 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 port (device I/O), you must make an Input
Maximum Delay assignment to the asynchronous reset port for the TimeQuest timing
analyzer to perform recovery analysis on that path.
Removal time is the minimum length of time the de-assertion of an asynchronous
control signal must be stable after the active clock edge. The TimeQuest timing
analyzer removal slack calculation is similar to the clock hold slack calculation, but it
applies asynchronous control signals. If the asynchronous control is registered, the
TimeQuest timing analyzer uses the equations shown in Equation 7–9 to calculate the
removal slack time.
Equation 7–9.
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
If the asynchronous control is not registered, the TimeQuest timing analyzer uses the
equations shown in Equation 7–10 to calculate the removal slack time.
Equation 7–10.
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 specify the Input
Minimum Delay constraint to the asynchronous reset pin for the TimeQuest timing
analyzer to perform removal analysis on this path.
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 7–10 shows an example of a multicycle
path between a multiplier’s input registers and output register where the destination
latches data on every other clock edge.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 7: The Quartus II TimeQuest Timing Analyzer
The Timing Netlist
7–15
Figure 7–10. Example Diagram of a Multicycle Path
D
D
Q
Q
ENA
D
D
Q
ENA
Q
ENA
2 Cycles
Figure 7–11 shows a register-to-register path.
Figure 7–11. Register-to-Register Path
reg
data_in
D
reg
Q
D
Q
data_out
src_clk
dst_clk
Figure 7–12 shows 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 7–12. Default Setup and Hold Timing Diagram
setup
hold
0
10
20
30
The default setup and hold relationships can be modified with the
set_multicycle_path command to accommodate the system requirements.
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
7–16
Chapter 7: The Quartus II TimeQuest Timing Analyzer
The Timing Netlist
Table 7–3 shows the commands used to modify either the launch or latch edge times
that the TimeQuest timing analyzer uses to determine a setup relationship or hold
relationship.
Table 7–3. 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
Figure 7–13 shows the timing diagram after a multicycle setup of two has been
applied. The command moves the latch edge time to 10 ns from the default 5 ns.
Figure 7–13. Modified Setup Diagram
new setup
default setup
0
10
20
30
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 (synchronization
register chain or synchronizer) in the destination clock domain to resynchronize the
data signals to the new clock domain.
The mean time between failure (MTBF) is an estimate of the average time between
instances of failure due to metastability.
The TimeQuest timing analyzer analyzes the robustness of the design for
metastability and can calculate the MTBF for synchronization register chains in the
design. 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.
Refer to “report_metastability” on page 7–46 for information about how to enable
metastability analysis and report metastability in the TimeQuest timing analyzer.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 7: The Quartus II TimeQuest Timing Analyzer
The Timing Netlist
f
7–17
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.
Common Clock Path Pessimism
Common clock path pessimism (CCPP) removal accounts for the minimum and
maximum delay variation associated with common clock paths during a static timing
analysis. CCPP removal accounts for this variation by adding the difference between
the maximum and minimum delay value of the common clock path to the appropriate
slack equation.
The minimum and maximum delay variation might arise 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, the analysis uses both the maximum
delay and the minimum delay to model the common clock path. This 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 7–14 shows a typical register-to-register path with the maximum and
minimum delay values shown.
Figure 7–14. 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 CCPP removal value; in this case, CCPP equals
0.5 ns. The CCPP removal value is then added to the appropriate slack equation.
Therefore, if the setup slack for the register-to-register in Figure 7–14 equals 0.7 ns
without CCPP removal, the slack would be 1.2 ns with CCPP removal.
CCPP is also used when determining 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.
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
7–18
Chapter 7: The Quartus II TimeQuest Timing Analyzer
The Timing Netlist
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 required minimum pulse width time is subtracted from the actual
minimum pulse width time. The actual minimum pulse width time is determined by
the clock requirement specified for the clock that feeds the clock port of the register.
The required minimum pulse width time is determined by the maximum rise,
minimum rise, maximum fall, and minimum fall times. Figure 7–15 shows a diagram
of the required minimum pulse width time for both the high pulse and low pulse.
Figure 7–15. Required Minimum Pulse Width
Minimum and
Maximum Rise
Rise Arrival Times
Minimum and
Maximum
Fall Arrival Times
High Pulse
Width
Low Pulse
Width
0.8
0.5
0.9
0.7
0.8
0.5
With CCPP, 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 7–15, 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).
Refer to “report_min_pulse_width” on page 7–47 for more information about
reporting CCPP in the TimeQuest timing analyzer.
You must use the Enable common clock path pessimism removal option to account
for CCPP in the Fitter and timing analysis. This option defaults to ON for Stratix III,
Cyclone III, and newer device families.
To access this option, perform the following steps:
1. On the Assignments menu, click Settings. The Settings dialog box appears.
2. In the Category list, next to Timing Analysis Settings, click the “+” icon to expand
the menu. Click TimeQuest Timing Analyzer.
3. Turn on Enable common clock path pessimism removal.
4. Click OK.
1
CCPP is supported for Stratix III, Cyclone III, and newer devices.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 7: The Quartus II TimeQuest Timing Analyzer
The Timing Netlist
7–19
Clock-As-Data
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, as FPGA
designs become more complex, such as using source-synchronous interfaces, this
simplified view is no longer sufficient.
The connection between port clk_in and port clk_out can be treated either as a
clock path or 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. In the
design shown in Figure 7–16, the path from port clk_in to port clk_out is both a
clock and a data path.
Figure 7–16. Simplified Source Synchronous Output
D
Q
reg_data
clk_in
clk_out
With clock-as-data analysis, the TimeQuest timing analyzer provides a more accurate
analysis of the path based on the user constraints. For the clock path analysis, any
phase shift associated with the PLL is taken into consideration. For the data path, any
phase shift associated with the PLL is taken into consideration instead of being
ignored.
The clock-as-data analysis also applies to internally generated clock dividers similar
to Figure 7–17.
Figure 7–17. Clock Divider (Note 1)
D
D
Q
Q
Launch Clock (1/2 T)
Data Arrival Time
Latch Clock (T)
Note to Figure 7–17:
(1) 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.
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
7–20
Chapter 7: The Quartus II TimeQuest Timing Analyzer
Collections
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.
Collections
The TimeQuest timing 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 timing analyzer.
Table 7–4 describes the collection commands supported by the TimeQuest timing
analyzer.
Table 7–4. 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.
Table 7–5 describes Altera SDC extension collection commands.
Table 7–5. Altera SDC Extension Collection Commands
Command
Description
get_fanouts <filter>
Returns a collection of fan-out nodes starting from <filter>.
get_keepers <filter>
Returns a collection of keeper nodes (non-combinational nodes) in the design.
get_nodes <filter>
Returns a collection of nodes in the design. The get_nodes collection cannot be
used when specifying constraints or exceptions.
get_partitions <filter>
Returns a collection of partitions matching the <filter>.
get_registers <filter>
Returns a collection of registers in the design.
get_fanins <filter>
Returns a collection of fan-in nodes starting from <filter>.
get_assignment_groups
<filter>
Returns either a collection of keepers, ports, or registers that have been saved to
the Quartus Settings File (.qsf) with the Assignment (Time) Groups option.
remove_clock <clock list> Removes the list of clocks specified by <clock list>.
1
Avoid use of the get_keepers command if your design targets the HardCopy series
of devices or you plan to migrate the design to the HardCopy series of devices.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 7: The Quartus II TimeQuest Timing Analyzer
Collections
f
7–21
For more information about collections, refer to API functions for Tcl in Quartus II help.
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, an additional
command would be required, which is [get_pins dst*].
To overcome this limitation the add_to_collection and
remove_from_collection commands are available. The add_to_collection
command allows you to add additional items to an existing collection. Example 7–1
shows the add_to_collection command and arguments.
Example 7–1. add_to_collection Command
add_to_collection <first collection> <second collection>
The remove_from_collection command allows you to remove items from an
existing collection. Example 7–2 shows the remove_from_collection command
and arguments.
Example 7–2. remove_from_collection Command
remove_from_collection <first collection> <second collection>
Example 7–3 shows examples of how to add elements to collections.
Example 7–3. 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 append only registers with name b*
# not all keepers
set regs_union [add_to_collection $regs1 b*]
f
© July 2010
Refer to add_to_collection and remove_from_collection in Quartus II Help
for full syntax information, options, and example usage.
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
7–22
Chapter 7: The Quartus II TimeQuest Timing Analyzer
SDC Constraint Files
SDC Constraint Files
The TimeQuest timing analyzer stores all timing constraints in an .sdc file. You can
create an .sdc file with different constraints for place-and-route and for timing
analysis. The .sdc file should contain only SDC commands. Commands to manipulate
the timing netlist or control the compilation flow should be run as part of a separate
Tcl script.
The Quartus II software does not automatically create or update .sdc files. Use the
write_sdc command, or, in the TimeQuest timing analyzer, on the Constraints
menu, click Write SDC File to write your constraints to an .sdc file.
Example 7–4 shows the write_sdc command and arguments.
Example 7–4. write_sdc Command
write_sdc [-expand] [-history] [<file_name>]
1
f
The constraints in the .sdc file are order-sensitive. A constraint must first be declared
before any references are made to that constraint. For example, if a generated clock
references a base clock with a name clk, the base clock constraint must be declared
before the generated clock constraint.
Refer to write_sdc in Quartus II Help for full syntax information, options, and
example usage.
Fitter and Timing Analysis with SDC Files
You can specify the same or different .sdc files for the Quartus II Fitter for
place-and-route, and the TimeQuest timing analyzer for static timing analysis. Using
different .sdc files allows you to have one set of constraints for place-and-route and
another set of constraints for final timing sign-off in the TimeQuest timing analyzer.
Specifying SDC Files for Place-and-Route
To specify an .sdc file for the Fitter, you must add the .sdc file to your Quartus II
project. To add the file to your project, use the following command in the Tcl console:
set_global_assignment -name SDC_FILE <SDC file name> r
Or, in the Quartus II software GUI, on the Project menu, click Add/Remove Files in
Project.
The Fitter optimizes your design based on the requirements in the .sdc files in your
project.
The results shown in the timing analysis report located in the Compilation Report are
based on the .sdc files added to the project.
1
You must specify the TimeQuest timing analyzer as the default timing analyzer to
make the Fitter read the .sdc file.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 7: The Quartus II TimeQuest Timing Analyzer
Clock Specification
7–23
Specifying SDC Files for Static Timing Analysis
You can specify your timing requirements manually or you can read a previously
created .sdc file. To manually enter your timing requirements, you can use constraint
entry dialog boxes or SDC commands. If you have an .sdc file that contains your
timing requirements, use this file to apply your timing requirements. To specify the
.sdc file for timing analysis in the TimeQuest timing analyzer, use the following
command:
read_sdc [<SDC file name>] r
If you use the TimeQuest GUI to apply the .sdc file for timing analysis, in the
TimeQuest timing analyzer, on the Constraints menu, click Read SDC File.
Synopsys Design Constraints File Precedence
The Quartus II Fitter and the TimeQuest timing analyzer reads the .sdc files from the
files list in the .qsf file in the order they are listed, from top to bottom.
The Quartus II software searches for an .sdc file, as shown in Figure 7–18.
Figure 7–18. Synopsys Design Constraints File Order of Precedence
Is the SDC File specified in the
.qsf file?
Yes
No
Does the .sdf file
<current revision>.sdc
exist?
Yes
No
Manually create .sdf file <current revision>.sdc
based on the current Quartus Settings File (1)
Compilation Flow
Note to Figure 7–18:
(1) This occurs only in the TimeQuest timing analyzer and not during compilation in the Quartus II software. The
TimeQuest timing analyzer has the ability to automate the conversion of the QSF timing assignments to SDC if no
.sdc file exists when the TimeQuest timing analyzer is opened.
1
If you type the read_sdc command at the command line without any arguments, the
precedence order shown in Figure 7–18 is followed.
Clock Specification
The specification of all clocks and any associated clock characteristics in your design
is essential for accurate static timing analysis results. The TimeQuest timing analyzer
supports many SDC commands that accommodate various clocking schemes and any
clock characteristics.
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
7–24
Chapter 7: The Quartus II TimeQuest Timing Analyzer
Clock Specification
Use the create_clock command to create a clock at any register, port, or pin. You
can create each clock with unique characteristics. Example 7–5 shows the
create_clock command and arguments.
Example 7–5. create_clock Command
create_clock
-period <period value>
[-name <clock name>]
[-waveform <edge list>]
[-add]
<targets>
Example 7–6 shows how to create a 10 ns clock with a 50% duty cycle, where the first
rising edge occurs at 0 ns applied to port clk.
Example 7–6. 100MHz Clock Creation
create_clock -period 10 -waveform { 0 5 } clk
Example 7–7 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 7–7. 100MHz Shifted by 90 Degrees Clock Creation
create_clock -period 10 -waveform { 2.5 7.5 } clk_sys
Clocks defined with the create_clock command have a default source latency
value of zero. The TimeQuest timing analyzer automatically computes the clock’s
network latency for non-virtual clocks.
f
Refer to create_clock in Quartus II Help for full syntax information, options, and
example usage.
Generated Clocks
The TimeQuest timing 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 the output of these circuits as generated clocks. This
definition allows the TimeQuest timing analyzer to analyze these clocks and account
for any network latency associated with them.
Use the create_generated_clock command to create generated clocks.
Example 7–8 shows the create_generated_clock command and the available
options.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 7: The Quartus II TimeQuest Timing Analyzer
Clock Specification
7–25
Example 7–8. create_generated_clock Command
create_generated_clock
[-name <clock name>]
-source <master pin>
[-edges <edge list>]
[-edge_shift <shift list>]
[-divide_by <factor>]
[-multiply_by <factor>]
[-duty_cycle <percent>]
[-add]
[-invert]
[-master_clock <clock>]
[-phase <phase>]
[-offset <offset>]
<targets>
Source latencies are based on clock network delays from the master clock (not
necessarily the master pin). You can use the set_clock_latency -source
command to override source latency.
Figure 7–19 shows how to create an inverted generated clock based on a 10 ns clock.
Figure 7–19. Generating an Inverted Clock
create_clock -period 10 [get_ports clk]
create_generated_clock -divide_by 1 -invert -source [get_registers clk] \
[get_registers gen|clkreg]
Edges
1
2
3
4
5
6
7
8
clk
gen|clkreg
Time
0
10
20
30
Figure 7–20 shows how to modify the generated clock using the -edges and
-edge_shift options.
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
7–26
Chapter 7: The Quartus II TimeQuest Timing Analyzer
Clock Specification
Figure 7–20. Edges and Edge Shifting a Generated Clock
create_clock -period 10 -waveform { 0 5} [get_ports clk]
# Creates a divide-by-t clock
create_generated_clock -source [get_ports clk] -edges {1 3 5 } [get_registers \
clkdivA|clkreg]
# Creates a divide-by-2 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 7–21 shows the effect of the -multiply_by option on the generated clock.
Figure 7–21. Multiplying a Generated Clock
create_clock -period 10 -waveform { 0 5 } [get_ports clk]
# Creates a multiply-by-2 clock
create_generated_clock -source [get_ports clk] -multiply_by 2 [get_registers \
clkmult|clkreg]
clk
clkmult|clkreg
Time
f
0
10
20
30
Refer to create_generated_clock in Quartus II Help for full syntax information,
options, and example usage.
Virtual Clocks
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.
Use the create_clock command to create virtual clocks, with no value specified for
the source option.
1
You can use virtual clocks for set_input_delay and set_output_delay
constraints.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 7: The Quartus II TimeQuest Timing Analyzer
Clock Specification
7–27
Figure 7–22 shows an example where a virtual clock is required for the TimeQuest
timing analyzer to properly analyze the relationship between the external register and
those in the design. Because the oscillator labeled virt_clk does not interact with
the Altera device, but acts as the clock source for the external register, the clock
virt_clk must be declared. Example 7–9 shows the command 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.
Figure 7–22. Virtual Clock Board Topology
Altera FPGA
External Device
datain
reg_a
reg_b
dataout
system_clk
virt_clk
After you create the virtual clock, you can perform register-to-register analysis
between the register in the Altera device and the register in the external device.
Example 7–9. Virtual Clock Example 1
#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]
Multi-Frequency Clocks
Certain designs have more than one clock source feeding a single clock port in the
design. The additional clock may act as a low-power clock, with a lower frequency
than the primary clock. To analyze this type of design, the create_clock command
supports the -add option that allows you to add more than one clock to a clock node.
Example 7–10 shows the command 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 timing
analyzer uses both clocks when it performs timing analysis.
Example 7–10. Multi-Frequency 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
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
7–28
Chapter 7: The Quartus II TimeQuest Timing Analyzer
Clock Specification
Automatic Clock Detection
To create clocks for all clock nodes in your design automatically, use the
derive_clocks command. The derive_clocks command is equivalent to using
create_clock for each register or port feeding the clock pin of a register. This
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.
Example 7–11 shows the derive_clocks command and options.
Example 7–11. derive_clocks Command
derive_clocks
[-period <period value>]
[-waveform <edge list>]
Use the derive_pll_clocks command, instead of the derive_clocks command,
to create clocks for PLL outputs.
Using the derive_clocks command for final timing sign-off is not recommended.
You should create clocks for all clock sources using the create_clock and
create_generated_clock commands.
f
Refer to derive_clocks in Quartus II Help for full syntax information, options, and
example usage.
Derive PLL Clocks
PLLs are used for clock management and synthesis in Altera devices. You can
customize the clocks generated from the outputs of the PLL based on design
requirements. Because a clock should be created for all clock nodes, all outputs of the
PLL should have an associated clock.
You can manually create a clock for each output of the PLL with the
create_generated_clock command, or you can use the derive_pll_clocks
command, which automatically searches the timing netlist and creates generated
clocks for all PLL outputs according to the settings specified for each PLL output.
Use the derive_pll_clocks command to automatically create a clock for each
output of the PLL. Example 7–12 shows the derive_pll_clocks command and
options.
Example 7–12. derive_pll_clocks Command
derive_pll_clocks
[-create_base_clocks]
[-use_net_name]
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. Before or
after the derive_pll_clocks command has been issued, you must manually create
a base clock for the input clock port of the PLL. If a clock is not defined for the input
clock node of the PLL, no clocks are reported for the PLL outputs. Instead, the
TimeQuest timing analyzer issues a warning message similar to Example 7–13 when
the timing netlist is updated.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 7: The Quartus II TimeQuest Timing Analyzer
Clock Specification
7–29
Example 7–13. Warning Message
Warning: The master clock for this clock assignment could not be
derived.
Clock: <name of PLL output clock pin name> was not created.
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 file, which allows
the derive_pll_clocks command to automatically detect any changes to the PLL.
With the derive_pll_clocks command in your .sdc file, each time the file is read,
the appropriate create_generated_clocks command for the PLL output clock
pin is generated. If you use the write_sdc -expand command after the
derive_pll_clock command, the new .sdc file 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 file. You must manually update the
create_generated_clock commands in the new .sdc file written by the
derive_pll_clocks command to reflect the changes to the PLL.
1
The derive_pll_clocks constraint will also constrain any LVDS transmitters or
LVDS receivers in the design by adding the appropriate multicycle constraints to
account for any deserialization factors.
For example, Figure 7–23 shows a simple PLL design with a register-to-register path.
Figure 7–23. Simple PLL Design
dataout
reg_1
pll_inclk
reg_2
pll_inst
Use the derive_pll_clocks command to automatically constrain the PLL. When
this command is issued for the design shown in Figure 7–23, the messages shown in
Example 7–14 are generated.
Example 7–14. derive_pll_clocks Generated 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:
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
7–30
Chapter 7: The Quartus II TimeQuest Timing Analyzer
Clock Specification
The node name pll_inst|altpll_component|pll|inclk[0] used for the
source option refers to the input clock pin of the PLL. In addition, the name of the
output clock of the PLL is the name of 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]). In this case, you should cut the
primary and secondary output clocks using the set_clock_groups command with
the -exclusive option.
Before you can generate any reports for this design, you must create a base clock for
the PLL input clock port. Use the following command or one similar:
create_clock -period 5 [get_ports pll_inclk]
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.
f
Refer to derive_pll_clocks in Quartus II Help for full syntax information,
options, and example usage.
Default Clock Constraints
If there are no clock constraints in the design, to provide a complete clock analysis, the
TimeQuest timing analyzer, by default, automatically creates clocks for all detected
clock nodes in your design that have not been constrained. The TimeQuest timing
analyzer creates a base clock with a 1 GHz requirement to unconstrained clock nodes,
using the following command:
derive_clocks -period 1
1
Individual clock constraints (for example, create_clock and
create_generated_clock) should be made for all clocks in the design. This
results in a thorough and realistic analysis of the design’s timing requirements. Avoid
using derive_clocks for final timing sign-off.
The default clock constraint is only applied when the TimeQuest timing analyzer
detects that all synchronous elements have no clocks associated with them. For
example, if a design contains two clocks and only one clock has constraints, the
default clock constraint is not applied. However, if both clocks have not been
constrained, the default clock constraint is applied.
Clock Groups
Many clocks can exist in a design; however, not all of the clocks interact with one
another, and certain clock interactions are not possible.
Use the set_clock_groups command to specify clocks that are exclusive or
asynchronous. Example 7–15 shows the set_clock_groups command and options.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 7: The Quartus II TimeQuest Timing Analyzer
Clock Specification
7–31
Example 7–15. set_clock_groups Command
set_clock_groups
[-asynchronous | -exclusive]
-group <clock name>
[-group <clock name>]
[-group <clock name>] ...
f
Refer to set_clock_groups in Quartus II Help for full syntax information, options,
and example usage.
The exclusive option is used to declare when two clocks are mutually exclusive to
each other and cannot coexist in the design at the same time. This can happen 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, two
clocks should be created on the port with the create_clock command, then use
set_clock_groups -exclusive to declare that they cannot coexist in the design
at the same time.
This eliminates any clock transfers that may be derived between the 25-MHz clock
and the 50-MHz clock. Example 7–16 shows the constraints for this.
Example 7–16. Exclusive Option
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 timing analyzer cuts the
timing paths between clocks for each of the separate -groups groups.
The asynchronous option is used to group related and unrelated clocks. With the
asynchronous option, clocks that are contained in groups are considered
asynchronous to each other. Any clocks within each group are considered
synchronous to each other.
For example, suppose you have three clocks: clk_A, clk_B, and clk_C. The clocks
clk_A and clk_B are related to each other, but clock clk_C operates completely
asynchronous with clk_A or clk_B. Example 7–17 makes clk_A and clk_B related
in the same group and unrelated with the second group which contains clk_C.
Example 7–17. Asynchronous Option Example 1
set_clock_groups -asynchronous -group {clk_A clk_B} -group {clk_C}
Example 7–18 shows an alternative method of specifying the same constraint as
Example 7–17.
Example 7–18. Asynchronous Option Example 2
set_clock_groups -asynchronous -group {clk_C}
This makes clk_C unrelated with every other clock in the design because clk_C is
the only group in the constraint.
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
7–32
Chapter 7: The Quartus II TimeQuest Timing Analyzer
Clock Specification
1
The TimeQuest timing analyzer assumes all clocks are related by default, unless
constrained otherwise.
Example 7–19 shows a set_clock_groups command and the equivalent
set_false_path commands.
Example 7–19. set_clock_groups
# Clocks A and C are never active when clocks B and D are active
set_clock_groups -exclusive -group {A C} -group {B D}
# Equivalent specification using
set_false_path -from [get_clocks
set_false_path -from [get_clocks
set_false_path -from [get_clocks
set_false_path -from [get_clocks
set_false_path -from [get_clocks
set_false_path -from [get_clocks
set_false_path -from [get_clocks
set_false_path -from [get_clocks
false paths
A] -to [get_clocks
A] -to [get_clocks
C] -to [get_clocks
C] -to [get_clocks
B] -to [get_clocks
B] -to [get_clocks
D] -to [get_clocks
D] -to [get_clocks
B]
D]
B]
D]
A]
C]
A]
C]
Clock Effect Characteristics
The create_clock and create_generated_clock commands create ideal clocks
that do not account for any board effects. This section describes how to account for
clock effect characteristics with clock latency and clock uncertainty.
Clock Latency
There are two forms of clock latency: source and network. 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 (or clock propagation delay)
at a register’s clock pin is the sum of the source and network latencies in the clock
path.
1
The set_clock_latency command supports only source latency. The -source
option must be specified when using the command.
Use the set_clock_latency command to specify source latency to any clock ports
in the design. Example 7–20 shows the set_clock_latency command and options.
Example 7–20. set_clock_latency Command
set_clock_latency
-source
[-clock <clock_list>]
[-rise | -fall]
[-late | -early]
<delay>
<targets>
f
Refer to set_clock_latency in Quartus II Help for full syntax information,
options, and example usage.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 7: The Quartus II TimeQuest Timing Analyzer
Clock Specification
7–33
The TimeQuest timing analyzer automatically computes network latencies; therefore,
the set_clock_latency command specifies only source latencies.
Clock Uncertainty
The set_clock_uncertainty command specifies clock uncertainty or skew for
clocks or clock-to-clock transfers. You can specify the uncertainty separately for setup
and hold. You can specify separate rising and falling clock transitions. The TimeQuest
timing 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.
Use the set_clock_uncertainty command to specify any clock uncertainty to the
clock port. Example 7–21 shows the set_clock_uncertainty command and
options.
Example 7–21. set_clock_uncertainty Command and Options
set_clock_uncertainty
[-rise_from <rise from clock> | -fall_from <fall from clock> |
-from <from clock>]
[-rise_to <rise to clock> | -fall_to <fall to clock> | -to <to clock>]
[-setup | -hold]
<value>
-add
f
Refer to set_clock_uncertainty in Quartus II Help for full syntax information,
options, and example usage.
Use the derive_clock_uncertainty command to automatically apply
inter-clock, intra-clock, and I/O interface uncertainties. Both setup and hold
uncertainties are calculated for each clock-to-clock transfer. Example 7–22 shows the
derive_clock_uncertainty command and options.
Example 7–22. derive_clock_uncertainty Command
derive_clock_uncertainty
[-overwrite]
[-add]
f
Refer to derive_clock_uncertainty in Quartus II Help for full syntax
information, options, and example usage.
The TimeQuest timing analyzer automatically applies clock uncertainties to
clock-to-clock transfers in the design.
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 set_clock_uncertainty
is applied between clka and clkb, the derive_clock_uncertainty values for
the clock transfer is ignored by default. The set_clock_uncertainty constraint
has priority over the derive_clock_uncertainty constraint.
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
7–34
Chapter 7: The Quartus II TimeQuest Timing Analyzer
Clock Specification
The clock uncertainty value that would have been used, however, is still reported for
informational purposes. You can use the -overwrite command to overwrite
previous clock uncertainty assignments, or remove them manually with the
remove_clock_uncertainty command. You can also use the -add option to add clock
uncertainty determined by the derive_clock_uncertainty command to any previously
defined clock uncertainty value.
Intra-Clock Transfers
Intra-clock transfers occur when the register-to-register transfer happens in the core of
the FPGA and source and destination clocks come from the same PLL output pin or
clock port. An example of an intra-clock transfer is shown in Figure 7–24.
Figure 7–24. Intra-Clock Transfer
Source Register
data_in
D
Destination Register
Q
D
Q
clk0
data_out
PLL
Inter-Clock Transfers
Inter-clock transfers occur when a register-to-register transfer happens in the core of
the FPGA and source and destination clocks come from a different PLL output pin or
clock port. An example of an inter-clock transfer is shown in Figure 7–25.
Figure 7–25. Inter-Clock Transfer
Source Register
data_in
D
Q
Destination Register
D
Q
data_out
clk0
clk_in
PLL
I/O Interface Clock Transfers
I/O interface clock transfers occur when data transfers from an I/O port to the core of
the FPGA (input) or from the core of the FPGA to the I/O port (output). An example
of an I/O interface clock transfer is shown in Figure 7–26.
Figure 7–26. I/O Interface-Clock Transfer
reg1
data_in
D
Q
data_out
clk_in
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 7: The Quartus II TimeQuest Timing Analyzer
I/O Specifications
7–35
For 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. The virtual clock is required to prevent the
derive_clock_uncertainty command from applying clock uncertainties for
either intra- or inter-clock transfers on an I/O interface clock transfer when the
set_input_delay or set_output_delay commands reference a clock port or
PLL output. If a virtual clock is not referenced in the set_input_delay or
set_output_delay commands, the derive_clock_uncertainty command
calculates intra- or inter-clock uncertainty value for the I/O interface.
Create the virtual clock with the same properties as the original clock that is driving
the I/O port. For example, Figure 7–27 shows a typical input I/O interface with the
clock specifications.
Figure 7–27. I/O Interface Specifications
External Device
Altera FPGA
data_in
D
Q
D
reg1
Q
reg1
clk_in
100 MHz
Example 7–23 shows the SDC commands to constrain the I/O interface shown in
Figure 7–27.
Example 7–23. 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]
I/O Specifications
The TimeQuest timing analyzer supports the Synopsys Design Constraint format for
constraining timing for the ports in your design. These constraints allow the
TimeQuest timing 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.
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
7–36
Chapter 7: The Quartus II TimeQuest Timing Analyzer
I/O Specifications
Input and Output Delay
Use input and output delay constraints to specify any external device or board timing
parameters. When you apply these constraints, the TimeQuest timing analyzer
performs static timing analysis on the entire system.
Set Input Delay
The set_input_delay constraint specifies the data arrival time at a port (a device
I/O) with respect to a given clock. Figure 7–28 shows an input delay path.
Figure 7–28. Set Input Delay
External Device
Altera Device
Oscillator
Use the set_input_delay command to specify input delay constraints to ports in
the design. Example 7–24 shows the set_input_delay command and options.
Example 7–24. set_input_delay Command
set_input_delay
-clock <clock name>
[-clock_fall]
[-rise | -fall]
[-max | -min]
[-add_delay]
[-reference_pin <target>]
[-source_latency_included]
<delay value>
<targets>
f
Refer to set_input_delay in Quartus II Help for full syntax information, options,
and example usage.
A warning message appears if you specify only a -max or -min value for the input
delay value. The input minimum delay default value is equal to the input maximum
delay; the input maximum delay default value is equal to the input minimum delay, if
only one is specified. Similarly, a warning message appears if you specify only a
-rise or -fall value for the delay value, and the delay defaults in the same manner
as the input minimum and input maximum delays.
The maximum value is used for setup checks; the minimum value is used for hold
checks.
By default, a set of input delays (min/max, rise/fall) 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 removes any
previously set input delays, unless you specify the -add_delay option. When you
specify the -add_delay option, the worst-case values are used.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 7: The Quartus II TimeQuest Timing Analyzer
I/O Specifications
7–37
The -rise and -fall options are mutually exclusive, as are the -min and -max
options.
Set Output Delay
The set_output_delay command specifies the data required time at a port (the
device pin) with respect to a given clock.
Use the set_output_delay command to specify output delay constraints to ports
in the design. Figure 7–29 shows an output delay path.
Figure 7–29. Output Delay
Altera Device
External Device
Oscillator
Example 7–25 shows the set_output_delay command and options.
Example 7–25. set_output_delay Command
set_output_delay
-clock <clock name>
[-clock_fall]
[-rise | -fall]
[-max | -min]
[-add_delay]
[-reference_pin <target>]
<delay value>
<targets>
f
Refer to set_output_delay in Quartus II Help for full syntax information, options,
and example usage.
A warning message appears if you specify only a -max or -min value for the output
delay value. The output minimum delay default value is the output maximum delay;
the output maximum delay default value is the output minimum delay, if only one is
specified.
The maximum value is used for setup checks; the minimum value is used for hold
checks.
By default, a set of output delays (min/max, rise/fall) is allowed for only one clock,
-clock_fall, port combination. Specifying an output delay on the same port for a
different clock or -clock_fall removes any previously set output delays, unless
you specify the -add_delay option. When you specify the -add_delay option, the
worst-case values are used.
The -rise and -fall options are mutually exclusive, as are the -min and -max
options.
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
7–38
Chapter 7: The Quartus II TimeQuest Timing Analyzer
Delay and Skew Specifications
Delay and Skew Specifications
The TimeQuest timing analyzer supports the ability to specify and report maximum,
minimum, and skew delays between a source and destination points.
set_net_delay
Use the set_net_delay command in conjunction with the report_net_delay
command to report the net delays and perform minimum or maximum analysis
across nets. Example 7–26 shows the set_net_delay command and options.
The set_net_delay and report_net_delay commands can be used when
verifying timing-critical delays for high-speed interfaces.
Example 7–26. set_net_delay Command
set_net_delay
-from <names>
[-max]
[-to <names>]
[-min]
<delay>
f
Refer to set_net_delay in Quartus II Help for full syntax information, options, and
example usage.
When the -min option is specified, the slack is calculated with the minimum edge
delay. When the -max option is specified, the slack is calculated with the maximum
edge delay. When the -skew option is specified, the slack is calculated across all the
valid edges that satisfy the -from and -to filters.
set_max_skew
Use the set_max_skew command to specify the maximum path-based skew
requirements for registers and ports in the design. Example 7–27 shows the
set_max_skew command and options.
Example 7–27. set_max_skew
set_max_skew
[-exclude <Tcl list>]
[-from <names>]
[-include <Tcl list>]
[-to <names>]
<skew>
f
Refer to set_max_skew in Quartus II Help for full syntax information, options, and
example usage.
By default, the set_max_skew command excludes set_input_delay and
set_output_delay. When this constraint is used, the results of max skew analysis
are reported with the command report_max_skew.
1
Avoid use of the set_max_skew command if your design targets the HardCopy
series of devices or you plan to migrate the design to the HardCopy series of devices.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 7: The Quartus II TimeQuest Timing Analyzer
Timing Exceptions
7–39
Timing Exceptions
Timing exceptions modify the default analysis performed by the TimeQuest timing
analyzer. This section describes the following available timing exceptions:
■
“False Path”
■
“Minimum Delay” on page 7–39
■
“Maximum Delay” on page 7–40
■
“Multicycle Path” on page 7–41
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
last assignments overwrite (or partially overwrite) earlier assignments.
False Path
False paths are paths that can be ignored during timing analysis.
Use the set_false_path command to specify false paths in the design.
Example 7–28 shows the set_false_path command and options.
Example 7–28. set_false_path Command
set_false_path
[-fall_from <clocks> | -rise_from <clocks> | -from <names>]
[-fall_to <clocks> | -rise_to <clocks> | -to <names>]
[-hold]
[-setup]
[-through <names>]
<delay>
f
Refer to set_false_path in Quartus II Help for full syntax information, options,
and example usage.
When the objects are timing nodes, the false path only applies to the path between the
two nodes. When an object is a clock, the false path applies to all paths where the
source node (-from) or destination node (-to) is clocked by the clock.
Minimum Delay
Use the set_min_delay command to specify an absolute minimum delay for a
given path. Example 7–29 shows the set_min_delay command and options.
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
7–40
Chapter 7: The Quartus II TimeQuest Timing Analyzer
Timing Exceptions
Example 7–29. set_min_delay Command
set_min_delay
[-fall_from <clocks> | -rise_from <clocks> | -from <names>]
[-fall_to <clocks> | -rise_to <clocks> | -to <names>]
[-through <names>]
<delay>
f
Refer to set_min_delay in Quartus II Help for full syntax information, options, and
example usage.
If the source or destination node is clocked, the clock paths are taken into account,
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 delay check.
When the objects are timing nodes, the minimum delay applies only to the path
between the two nodes. When an object is a clock, the minimum delay applies to all
paths where the source node (-from) or destination node (-to) is clocked by the
clock.
You can apply the set_min_delay command exception to an output port that does
not use a set_output_delay constraint. In this case, the setup summary and hold
summary report the slack for these paths. Because there is no clock associated with
the output port, no clock is reported for these paths and the Clock column is empty. In
this case, you cannot report timing for these paths.
1
To report timing using clock filters for output paths with the set_min_delay
command, you can use the set_output_delay command for the output port with a
value of 0. You can use an existing clock from the design or a virtual clock as the clock
reference in the set_output_delay command.
Maximum Delay
Use the set_max_delay command to specify an absolute maximum delay for a
given path. Example 7–30 shows the set_max_delay command and options.
Example 7–30. set_max_delay Command
set_max_delay
[-fall_from <clocks> | -rise_from <clocks> | -from <names>]
[-fall_to <clocks> | -rise_to <clocks> | -to <names>]
[-through <names>]
<delay>
f
Refer to set_max_delay in Quartus II Help for full syntax information, options, and
example usage.
If the source or destination node is clocked, the clock paths are taken into account,
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 maximum delay check.
When the objects are timing nodes, the maximum delay only applies to the path
between the two nodes. When an object is a clock, the maximum delay applies to all
paths where the source node (-from) or destination node (-to) is clocked by the
clock.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 7: The Quartus II TimeQuest Timing Analyzer
Timing Exceptions
7–41
You can apply the set_max_delay command exception to an output port that does
not use a set_output_delay constraint. In this case, the setup summary and hold
summary report the slack for these paths. Because there is no clock associated with
the output port, no clock is reported for these paths and the Clock column is empty. In
this case, you cannot report timing for these paths.
1
To report timing using clock filters for output paths with the set_max_delay
command, you can use the set_output_delay command for the output port with a
value of 0. You can use an existing clock from the design or a virtual clock as the clock
reference in the set_output_delay command.
Multicycle Path
By default, the TimeQuest timing 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.
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.
Use the set_multicycle_path command to specify the multicycle constraints in
the design. Example 7–31 shows the set_multicycle_path command and options.
Example 7–31. set_multicycle_path Command
set_multicycle_path
[-end]
[-fall_from <clocks> | -rise_from <clocks> | -from <names>]
[-fall_to <clocks> | -rise_to <clocks> | -to <names>]
[-hold]
[-setup]
[-start]
[-through <names>]
<path multiplier>
f
Refer to set_multicycle_path in Quartus II Help for full syntax information,
options, and example usage.
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.
For example usage of the set_multicycle_hold command, refer to “Multicycle
Path” on page 7–41.
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
7–42
Chapter 7: The Quartus II TimeQuest Timing Analyzer
Timing Exceptions
Delay Annotation
The TimeQuest timing analyzer provides two commands that allow you to modify the
default delay values used during timing analysis. The two commands are
set_annotated_delay and set_timing_derate. Use the
set_annotated_delay command to annotate the cell delay between two or more
pins/nodes on a cell, or the interconnect delay between two or more pins on the same
net, in the current design. The annotated delay can be specified for specific transition
edges: rise-rise, fall-rise, rise-fall, and fall-fall, and can also set different minimum and
maximum values.
1
If no transition is specified, the given delay is assigned to all four values. Options
-max and -min allow users to specify maximum or minimum delay.
Example 7–32 shows the set_annotated_delay command and options.
Example 7–32. set_annotated_delay Command
set_annotated_delay
[-cell|-net]
[-from <names>]
[-max|-min]
[-operating_conditions <operating_conditions>]
[-rr|-fr|-rf|-ff]
[-to <names>]
<delay>
f
Refer to set_annotated_delay in Quartus II Help for full syntax information,
options, and example usage.
With the -operating_conditions option, different operating conditions can be
specified in a single .sdc file, removing the requirement of having multiple .sdc files
that specify different operating conditions.
The delay annotation is deferred until the next time update_timing_netlist is
called. To remove annotated delays, use the remove_annotated_delay command.
Use the set_timing_derate command to specify global derating factors for the
current design. The maximum and minimum delays of all timing arcs in the design
are multiplied by the specified derating factors using the -late and -early options
respectively.
1
Only positive derate factors are allowed. If neither the -cell_delay nor
-ic_delay option is used, the derating factors apply to both cell and interconnect
delays.
Specifying a derate value of less than 1.0 for the -late option or a derate value of
greater than 1.0 for the -early option reduces delay pessimism, which might
incorrectly lead to optimistic results from timing analysis.
The effect of the set_timing_derate command is deferred until the next time
update_timing_netlist is called. To reset derate factors to original values, use
the reset_timing_derate command.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 7: The Quartus II TimeQuest Timing Analyzer
Constraint and Exception Removal
7–43
Example 7–33. set_timing_derate Command and Options
set_timing_derate
[-cell_delay]
[-early]
[-ic_delay]
[-operating_conditions <operating_conditions>]
[<cells>]
[<derate_value>]
f
Refer to set_timing_derate in Quartus II Help for full syntax information,
options, and example usage.
Constraint and Exception Removal
When using the TimeQuest timing analyzer interactively, it is sometimes necessary to
remove a constraint or exception. In cases where constraints and exceptions either
become outdated or have been erroneously entered, the TimeQuest timing analyzer
provides a convenient way to remove them.
Table 7–6 lists commands that allow you to remove constraints and exceptions from a
design.
Table 7–6. Constraint and Exception Removal
Command
Description
remove_clock [-all] [<clock list>]
Removes any clocks specified by <clock list> that have been
previously created. The -all option removes all declared clocks.
remove_clock_groups -all
Removes all clock groups previously created. Specific clock
groups cannot be removed.
remove_clock_latency -source
<targets>
Removes the clock latency constraint from the clock specified by
<targets>.
remove_clock_uncertainty -from
<from clock> -to <to clock>
Removes the clock uncertainty constraint from <from clock> to
<to clock>.
remove_input_delay <targets>
Removes the input delay constraint from <targets>.
remove_output_delay <targets>
Removes the output delay constraint from <targets>.
remove_annotated_delay -all
Removes any annotated delay specified with the
set_annotated_delay command.
reset_design
Removes all constraints and exceptions in the design.
reset_timing_derate
Resets all timing derating factors to default values.
Timing Reports
The TimeQuest timing analyzer provides real-time static timing analysis result
reports. Reports are generated only when requested. You can customize which report
to display specific timing information, excluding those fields not required.
This section describes various report generation commands supported by the
TimeQuest timing analyzer.
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
7–44
Chapter 7: The Quartus II TimeQuest Timing Analyzer
Timing Reports
report_timing
Use the report_timing command to generate a setup, hold, recovery, or removal
report. Example 7–34 shows the report_timing command and options.
Example 7–34. report_timing Command
report_timing
[-append]
[-detail <summary|path_only|path_and_clock|full_path>]
[-fall_to_clock <names>|-rise_to_clock <names>]
[-to <names>|-to_clock <names>]
[-rise_from <names>|-fall_from <names>]
[-rise_to <names>|-fall_to <names>]
[-rise_through <names>|-fall_through <names>]
[-false_path]
[-file <name>]
[-from <names>]
[-from_clock <names>|-rise_from_clock <names>|-fall_from_clock <names>]
[-less_than_slack <slack limit>]
[-npaths <number>]
[-nworst <number>]
[-pairs_only]
[-panel_name <name>]
[-setup|-hold|-recovery|-removal]
[-show_routing]
[-stdout]
[-through <names>]
f
Refer to report_timing in Quartus II Help for full syntax information, options, and
example usage.
The report_timing command generates a report of the specified analysis type—
either setup, hold, recovery, or removal. Each of the column descriptions are
described in the Table 7–7.
Table 7–7. Timing Report Data
Column Name
Description
Total
Shows the accumulated time delay.
Incr
Shows the increment in delay.
RF
Shows the input and output transition of the element; this can be one of the
following: R, F, RR, RF, FR, FF.
Type
Shows the node type; refer to Table 7–8 of a description of the various node types.
Fanout
Shows the number of fan-outs of the element.
Location
Shows the location of the element in the FPGA.
Element
Shows the name of the element.
Table 7–8 provides a description of the possible node type in the report_timing
reports.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 7: The Quartus II TimeQuest Timing Analyzer
Timing Reports
7–45
Table 7–8. Type Description
Type Name
Description
CELL
Indicates the element is either a register or a combinational element in the FPGA; the
CELL can be a register in the ALM, memory blocks, DSP blocks, or I/O block.
COMP
Indicates the PLL clock network compensation delay.
IC
Indicates the element is an interconnect delay.
utco
Indicates the element’s micro clock-to-out time.
utsu
Indicates the element’s micro setup time.
uth
Indicates the element’s micro hold time.
iext
Indicates the element’s external input delay time.
oext
Indicates the element’s external output delay time.
LOOP
Indicates a lumped delay bypassing combinational loops.
RE
Indicates a specified routing delay.
report_exceptions
Use the report_exceptions command to generate a report that details the slack of
all paths that have the timing exceptions set_false_path, set_multicycle,
set_min_delay, or set_max_delay applied to them.
The report_exceptions command can be used to determine if all exceptions have
been applied to the applicable paths in the design.
Example 7–35 shows the report_exceptions command and options.
Example 7–35. report_exceptions Command
report_exceptions
[-append]
[-detail <summary|path_summary|path_only|path_and_clock|full_path>]
[-fall_from_clock <names>]
[-fall_to_clock <names>]
[-file <name>]
[-from <names>]
[-from_clock <names>]
[-hold]
[-less_than_slack <slack limit>]
[-npaths <number>]
[-nworst <number>]
[-pairs_only]
[-panel_name <name>]
[-recovery]
[-removal]
[-rise_from_clock <names>]
[-rise_to_clock <names>]
[-setup]
[-stdout]
[-through <names>]
[-to <names>]
[-to_clock <names>]
f
© July 2010
Refer to report_exceptions in Quartus II Help for full syntax information,
options, and example usage.
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
7–46
Chapter 7: The Quartus II TimeQuest Timing Analyzer
Timing Reports
report_metastability
Use the report_metastability command to generate a report that lists the
synchronization register chains for asynchronous transfers in your design, and details
the MTBF for synchronization register chains.
To enable metastability analysis, you must set the Synchronizer Identification option
to identify the synchronization register chains in the design. You can use automatic
identification to generate a list of possible synchronizers in the metastability report,
but MTBF is not reported for automatically-identified synchronizers.
The TimeQuest timing analyzer can analyze metastability MTBF only if a
synchronization chain meets its timing requirements. Therefore, it is important for
your design to be correctly constrained to get an accurate MTBF report. In addition,
automatic synchronizer identification uses timing constraints to automatically detect
the signal transfers between circuitry in unrelated or asynchronous clock domains, so
clock domains must be related correctly with the timing constraints.
f
For details about metastability analysis and reporting, refer to the Managing
Metastability with the Quartus II Software chapter in volume 1 of the Quartus II
Handbook. This chapter describes how to use the Synchronizer Identification option,
explains how TimeQuest timing constraints affect synchronizer chain identification
and the reported MTBF, and provides details about the information reported with the
report_metastability command.
Example 7–36. report_metastability command
report_metastabiity
[-append]
[-file <name>]
[-panel_name <name>]
[-stdout]
f
Refer to report_metastability in Quartus II Help for full syntax information,
options, and example usage.
report_clock_transfers
Use the report_clock_transfers command to generate a report that details all
clock-to-clock transfers in the design. A clock-to-clock transfer is reported if a path
exists between two registers that are clocked by two different clocks. Information such
as the number of destinations and sources is also reported.
Use the report_clock_transfers command to generate a setup, hold, recovery,
or removal report.
Example 7–37 shows the report_clock_transfers command and options.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 7: The Quartus II TimeQuest Timing Analyzer
Timing Reports
7–47
Example 7–37. report_clock_transfers Command
report_clock_transfers
[-append]
[-file <name>]
[-hold]
[-setup]
[-stdout]
[-recovery]
[-removal]
[-panel_name <name>]
f
Refer to report_clock_transfers in Quartus II Help for full syntax information,
options, and example usage.
report_clocks
Use the report_clocks command to generate a report that details all clocks in the
design. The report contains information such as type, period, waveform (rise and fall),
and targets for all clocks in the design.
Example 7–38 shows the report_clocks command and options.
Example 7–38. report_clocks Command
report_clocks
[-append]
[-desc]
[-file <name>]
[-stdout]
[-panel_name <name>]
f
Refer to report_clocks in Quartus II Help for full syntax information, options, and
example usage.
report_min_pulse_width
The report_min_pulse_width command checks that a clock high or low pulse is
sustained long enough to be recognized as an actual change in the clock signal. A
failed minimum pulse width check indicates that the register may not recognize the
clock transition. Use the report_min_pulse_width command to generate a report
that details the minimum pulse width for all clocks in the design. The report contains
information for high and low pulses for all clocks in the design.
The report_min_pulse_width command also reports minimum period checks for
RAM and DSP, as well as I/O edge rate limits for input and output clock ports. For
output ports, the port must either have a clock (or generated clock) assigned to it or
used as the -reference_pin for input/output delays.
The report_min_pulse_width command checks the I/O edge rate limits, but does
not always perform the check for output clock ports. For the
report_min_pulse_width command to check the I/O edge rate limits for output
clock ports, the output clock port must fall into one of the following categories:
■
Have a clock or generated clock constraint assigned to it
or
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
7–48
Chapter 7: The Quartus II TimeQuest Timing Analyzer
Timing Reports
■
Use a -reference_pin for an input or output delay constraint
Each register in the design is reported twice per clock that clocks the register: once for
the high pulse and once for the low pulse. Example 7–39 shows the
report_min_pulse_width command and options.
Example 7–39. report_min_pulse_width Command
report_min_pulse_width
[-append]
[-file <name>]
[-nworst <number>]
[-stdout]
[<targets>]
[-detail_<summary | full_path>]
[-panel_name <name>]
f
Refer to report_min_pulse_width in Quartus II Help for full syntax information,
options, and example usage.
report_net_timing
Use the report_net_timing command to generate a report that details the delay
and fan-out information about a net in the design. A net corresponds to a cell’s output
pin.
Example 7–40 shows the report_net_timing command and options.
Example 7–40. report_net_timing Command
report_net_timing
[-append]
[-file <name>]
[-nworst_delay <number>]
[-nworst_fanout <number>]
[-stdout]
[-panel_name <name>]
f
Refer to report_net_timing in Quartus II Help for full syntax information,
options, and example usage.
report_sdc
Use the report_sdc command to generate a report of all the Synopsys design
constraints in the project.
Example 7–41 shows the report_sdc command and options.
Example 7–41. report_sdc Command
report_sdc
[-ignored]
[-append]
[-file]
[-stdout]
[-panel_name <name>]
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 7: The Quartus II TimeQuest Timing Analyzer
Timing Reports
f
7–49
Refer to report_sdc in Quartus II Help for full syntax information, options, and
example usage.
report_ucp
Use the report_ucp command to generate a report of all unconstrained paths in the
design.
Example 7–42 shows the report_ucp command and options.
Example 7–42. report_ucp Command
report_ucp
[-append]
[-file <name>]
[-hold]
[-setup]
[-stdout]
[-summary]
[-panel_name <name>]
f
Refer to report_ucp in Quartus II Help for full syntax information, options, and
example usage.
report_bottleneck
Use the report_bottleneck command to report a rating per node based on the
number of failing paths through each node for the worst 1,000 setup paths.
Example 7–43 shows the report_bottleneck command and options.
Example 7–43. report_bottleneck Command
report_bottleneck
[-cmetric <cmetric_name>]
[-details]
[-metric <default|tns|num_paths|num_fpaths|num_fanins|num_fanouts>]
[-panel <panel_name>]
[-stdout]
[<paths>]
By default, the report_bottleneck command reports a rating for the worst 1,000
setup paths.
In addition to the default metric, there are a few additional “standard” metrics to
choose from, such as:
■
-metric num_fanouts
■
-metric tns
You can also create a custom metric to evaluate the nodes based on the combination of
the number of fanouts, fanins, failing paths, total paths, and other keepers. The paths
to be analyzed can be specified by passing the result of any get_timing_paths call
as the last argument to report_bottleneck.
f
© July 2010
Refer to report_bottleneck in Quartus II Help for full syntax information,
options, and example usage.
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
7–50
Chapter 7: The Quartus II TimeQuest Timing Analyzer
Timing Reports
report_datasheet
Use the report_datasheet command to generate a datasheet report which
summarizes the timing characteristics of the entire design. It reports setup (tsu), hold
(th), clock-to-output (tco), minimum clock-to-output (mintco), output enable (tzx),
minimum output enable (mintzx), output disable (txz), minimum output disable
(mintxz), propagation delay (tpd), and minimum propagation delay (mintpd)
times. Example 7–44 shows the report_datasheet command and options.
Example 7–44. report_datasheet Command
report_datasheet
[-append]
[-file <name>]
[-stdout]
[panel_name <name>]
f
Refer to report_datasheet in Quartus II Help for full syntax information, options,
and example usage.
The delays are reported with respect to a base clock or port for which they are
relevant. If there is a case where there are multiple paths for a clock, the maximum
delay of the longest path is taken for the tSU, tH, tCO, and tPD, and the minimum delay of
the shortest path is taken for mintCO and mintPD.
report_rskm
Use the report_rskm command to generate a report that details the receiver skew
margin for LVDS receivers.
Example 7–45 shows the report_rskm command and options.
Example 7–45. report_rskm Command
report_rskm
[-append]
[-file <name>]
[-panel_name <name>]
[-stdout]
The receiver input skew margin (RSKM) is the time margin available before the LVDS
receiver megafunction fails to operate. RSKM is defined as the total time margin that
remains after subtracting the sampling window (SW) size and the receiver
channel-to-channel skew (RCCS) from the time unit interval (TUI), as expressed in the
formula shown in Equation 7–11.
Equation 7–11.
TUI – SW – RCCS RSKM = ---------------------------------------------2
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 7: The Quartus II TimeQuest Timing Analyzer
Timing Reports
7–51
The time unit interval is the LVDS clock period (1/fMAX). The sampling window is the
period of time that the input data must be stable to ensure that the data is successfully
sampled by the LVDS receiver megafunction. The sampling window size varies by
device speed grade; RCCS reflects channel-to-channel skew seen by the LVDS
receiver. This RCCS includes transmitter channel-to-channel skew (TCCS) of the
upstream transmitter and maximum channel-to-channel skew between the
transmitter and receiver. RCCS is equal to the difference between the maximum input
delay and minimum input delay. If no input delay is set, RCCS defaults to zero.
f
Refer to report_rskm in Quartus II Help for full syntax information, options, and
example usage.
report_tccs
Use the report_tccs command to generate a report that details the
channel-to-channel skew margin for LVDS transmitters. TCCS is the timing difference
between the fastest and slowest output transitions, including tCO variations and clock
skew.
Example 7–46 shows the report_tccs command and options.
Example 7–46. report_tccs Command
report_tccs
[-append]
[-file <name>]
[-panel_name <name>]
[-quiet]
[-stdout]
f
Refer to report_tccs in Quartus II Help for full syntax information, options, and
example usage.
report_partitions
Use the report_partitions command to generate a timing report listing the
worst-case setup checks for each partition in the design.
Example 7–47 shows the report_partitions command and options.
Example 7–47. report_partitions Command
report_partitions
[-nworst <number>]
[-panel_name <name>]
[-stdout]
f
Refer to report_partitions in Quartus II Help for full syntax information,
options, and example usage.
report_path
Use the report_path command to generate a report that details the longest delay
paths between any two arbitrary keeper nodes.
Example 7–48 shows the report_path command and options.
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
7–52
Chapter 7: The Quartus II TimeQuest Timing Analyzer
Timing Reports
Example 7–48. report_path Command
report_path
[-append]
[-file <name>]
[-from <names>]
[-min_path]
[-npaths <number>]
[-nworst <number>]
[-panel_name <name>]
[-stdout]
[-summary]
[-through <names>]
[-to <names>]
1
The delay path reported cannot pass through a keeper node; for example, a register or
port. Instead, the delay path must be from the output pin of a keeper node to the input
pin of a keeper node.
Figure 7–30 shows a simple design with a register-to-register path.
Figure 7–30. Simple Register-to-Register Path
data_in_a
and2
data_in_b
D
reg1
D
reg2
Q
data_out
Q
c0
clk_i
PLL
clk_out
c1
Example 7–49 shows the report generated from the following command:
report_path -from [get_pins {reg1|regout}] -to [get_pins \
{reg2|datain}] -npaths 1 -panel_name "Report Path" –stdout
Example 7–49. report_path from Keeper Output Pin to Keeper Input Pin
Info:
Info:
Info:
Info:
Info:
Info:
Info:
Info:
Info:
Info:
Info:
Info:
Info:
Info:
Info:
===============================================================
From Node : reg1|regout
To Node : reg2|datain
Path:
Total (ns) Incr (ns) Type Element
========== ========= == ==== ===================
0.000 0.000 reg1|regout
0.206 0.206 RR IC and2|datae
0.360 0.154 RR CELL and2|combout
0.360 0.000 RR IC reg2|datain
Total Path Delay : 0.360
===============================================================
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 7: The Quartus II TimeQuest Timing Analyzer
Timing Reports
7–53
Example 7–50 shows the report generated from the following command:
report_path -from [get_ports data_in_a] -to [get_pins {reg2|regout}] \
-npaths 1
Example 7–50. report_path from Keeper-to-Keeper Output Pin
Info: Report Path: No paths were found
0 0.000
No paths were reported in Example 7–50 because the destination passes through an
input pin of a keeper node.
f
Refer to report_path in Quartus II Help for full syntax information, options, and
example usage.
report_net_delay
Use the report_net_delay to generate a slack report for paths constrained with the
set_net_delay command. The report_net_delay command reports the results
of all set_net_delay commands in a single report. The report contains each
set_net_delay command with the worst case slack result followed by the results of
each edge matching the criteria set by that set_net_delay command. These results
are ordered based on the slack value. Example 7–51 shows the report_net_delay
command and options.
Example 7–51. report_net_delay Command
report_net_delay
[-append]
[-file <name>]
[-nworst <number>]
[-panel_name <name>]
[-stdout]
f
Refer to report_net_delay in Quartus II Help for full syntax information, options,
and example usage.
report_max_skew
Use the report_max_skew to generate a slack report for paths constrained with the
set_max_skew command. The report_max_skew command reports the results of
all set_max_skew commands in a single report. The report contains each
set_max_skew command with the worst case slack result followed by the results of
each path matching the criteria set by that set_max_skew command. These results
are ordered based on the slack value. Example 7–52 shows the report_max_skew
command and options.
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
7–54
Chapter 7: The Quartus II TimeQuest Timing Analyzer
Timing Reports
Example 7–52. report_max_skew Command
report_max_skew
[-detail <summary|path_only|path_and_clock|full_path>]
[-file <name>]
[-less_than_slack <slack limit>]
[-npaths <number>]
[-panel_name <name>]
[-show_routing]
[-stdout]
1
f
No results are displayed if the -from/-from_clock and -to/-to_clock are
applied to less than two paths.
Refer to report_max_skew in Quartus II Help for full syntax information, options,
and example usage.
report_skew
This report performs skew analysis on specified paths. If valid set_max_skew
constraints exist, this report computes skew with respect to the latest and the earliest
arrival of each path.
1
Unlike the report_max_skew command, the report_skew command does not
depend on the existence of set_max_skew assignments.
Skew for the latest arrival is computed by comparing the latest arrival of each path
with the earliest arrival of the path that has the smallest value for early arrival of all
other paths included in the constraint. Similarly, skew for the earliest arrival is
computed by comparing the earliest arrival of each path with the latest arrival of the
path that has the largest value for late arrival of all other paths included in the
constraint. No path is compared with itself.
The return value of this command is a two-element list. The first number is the
number of paths found in the analysis. The second is the worst-case skew, in terms of
the current default time unit.
Example 7–53 shows the report_skew command and options.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 7: The Quartus II TimeQuest Timing Analyzer
Timing Reports
7–55
Example 7–53. report_skew Command Options
report_skew
-detail <summary|path_only|path_and_clock|full_path>]
[-exclude <Tcl list>]
[-fall_from_clock <names>]
[-fall_to_clock <names>]
[-file <name>]
[-from <names>]
[-from_clock <names>]
[-greater_than_skew <slack limit>]
[-include <Tcl list>]
[-npaths <number>]
[-panel_name <name>]
[-rise_from_clock <names>]
[-rise_to_clock <names>]
[-show_routing]
[-stdout]
[-through <names>]
[-to <names>]
[-to_clock <names>]
f
Refer to report_skew in Quartus II help for full syntax information, options, and
example usage.
check_timing
Use the check_timing command to generate a report on any potential problem with
the design or applied constraints. Not all check_timing results are serious issues.
The results should be examined to see if the results are desired. Example 7–54 shows
the check_timing command and options.
Example 7–54. check_timing Command
check_timing
[-append]
[-file <name>]
[-include <check_list>]
[-stdout]
[-panel_name <name>]
f
Refer to check_timing in Quartus II help for full syntax information, options, and
example usage.
report_clock_fmax_summary
Use the report_clock_fmax_summary to report potential fMAX for every clock in
the design, regardless of the user-specified clock periods. fMAX is only computed for
paths where the source and destination registers or ports are driven by the same
clock. Paths of different clocks, including generated clocks, are ignored. For paths
between a clock and its inversion, fMAX is computed as if the rising and falling edges
are scaled along with fMAX, such that the duty cycle (in terms of a percentage) is
maintained.
Example 7–55 shows the report_clock_fmax_summary command and options.
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
7–56
Chapter 7: The Quartus II TimeQuest Timing Analyzer
Timing Reports
Example 7–55. report_clock_fmax_summary Command
report_clock_fmax_summary
[-append]
[-file <name>]
[-panel_name <name>]
[-stdout]
f
Refer to report_clock_fmax_summary in Quartus II help for full syntax
information, options, and example usage.
The fMAX Summary report contains four columns: fMAX, Restricted fMAX, Clock Name,
and Note. The description of each column is given in Table 7–9.
Table 7–9. fMAX Summary Report Column
Column Name
fMAX
Description
Shows the fastest possible frequency at which the internal register-to-register can run. This is not the
fastest the clock port can be driven.
Restricted fMAX Shows fastest possible frequency at which the clock port can run. This number may be lower than the fMAX
column for various reasons, including hold timing requirements, I/O edge rate limits for clocks (which also
depends on I/O standards), minimum pulse width checks for registers, and minimum period checks for
RAM and DSP registers.
Clock Name
Shows the clock name.
Note
Shows any notes related to the clock.
create_timing_summary
Reports the worst-case clock setup and clock hold slacks and endpoint total negative
slack (TNS) per clock domain. Total negative slack is the sum of all slacks less than
zero for each destination register or port in the clock domain.
Example 7–56 shows the create_timing_summary command and options.
Example 7–56. create_timing_summary Command
create_timing_summary
[-append]
[-file <name>]
[-hold]
[-mpw]
[-panel_name <name>]
[-recovery]
[-removal]
[-setup]
[-stdout]
f
Refer to create_timing_summary in Quartus II Help for full syntax information,
options, and example usage.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 7: The Quartus II TimeQuest Timing Analyzer
Other Features
7–57
Other Features
The TimeQuest timing analyzer supports many features that enhance and provide a
through analysis of your designs, such as multi-corner analysis, and advanced I/O
timing.
Multi-Corner Analysis
Multi-corner analysis allows a design to be verified under a variety of operating
conditions (voltage, process, and temperature) while performing a static timing
analysis on the design.
Use the set_operating_conditions command to change the operating
conditions or speed grade of the device used for static timing analysis.
Example 7–57 shows the set_operating_conditions command and options.
Example 7–57. set_operating_conditions Command
set_operating_conditions
[-model <fast|slow>]
[-speed <speed grade>]
[-temperature <value in ºC>]
[-voltage <value in mV>]
[-force_dat]
[-grade <c | i>]
[<operating condition Tcl object>]
Table 7–10 describes the options for the set_operating_conditions command.
Table 7–10. 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.
1
If an operating condition Tcl object is used, the model, speed, temperature, and
voltage options are not required. If an operating condition Tcl object is not used, the
model must be specified, and the -speed, -temperature, and -voltage options
are optional, using the appropriate defaults for the device where applicable.
1
Use the get_available_operating_conditions-all command to obtain a list
of available operating conditions for the target device.
Table 7–11 shows the operating conditions of each model for device families that
support only two operating conditions, that is, fast and slow.
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
7–58
Chapter 7: The Quartus II TimeQuest Timing Analyzer
Other Features
Table 7–11. Operating Conditions for Fast and Slow 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 7–11:
(1) Refer to the DC & Switching Characteristics chapter of the applicable device Handbook for Vcc and TJ.
A static timing analysis should be performed under all available operating conditions.
This ensures that no violations will occur under various conditions during the device
operation.
Example 7–58 shows how to set the operating conditions for a Stratix III design to the
slow model, 1100 mV, and 85° C.
Example 7–58. Setting Operating Conditions with Individual Values
set_operating_conditions -model slow -temperature 85 -voltage 1100
Alternatively, you can set the operating conditions in Example 7–58 with the Tcl object
as shown in Example 7–59.
Example 7–59. Setting Operating Conditions with a Tcl Object
set_operating_conditions 4_slow_1100mv_85c
Example 7–60 shows how to use the set_operating_conditions command to generate
different reports for various operating conditions.
Example 7–60. Script Excerpt for Analysis of Various Operating Conditions
s#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
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 7: The Quartus II TimeQuest Timing Analyzer
Other Features
7–59
Advanced I/O Timing and Board Trace Model Assignments
The TimeQuest timing analyzer is able to use advanced I/O timing and board trace
model assignments to model I/O buffer delays in your design. To enable the
Advanced I/O Timing feature, in the Settings dialog box, on the TimeQuest Timing
Analyzer page, turn on Enable Advanced I/O Timing.
If you change the Advanced I/O Timing setting or change any board trace model
assignments and do not recompile before you analyze timing, you must use the
-force_dat command when you create a timing netlist. Type the following
command in the Tcl console of the TimeQuest timing analyzer:
create_timing_netlist -force_dat r
If you change the Advanced I/O Timing settings or change any board trace model
assignments and recompile before you analyze timing, you do not have to use the
-force_dat command when you create the timing netlist.
f
For more information about the Advanced I/O Timing feature, refer to the I/O
Management chapter in volume 2 of the Quartus II Handbook.
Wildcard Assignments and Collections
To simplify the task of applying constraints to many nodes in a design, the TimeQuest
timing analyzer accepts the “*” and “?” wildcard characters. Use these wildcard
characters to reduce the number of individual constraints you must specify in your
design.
The “*” wildcard character matches any string. For example, given an assignment
made to a node specified as reg*, the TimeQuest timing analyzer searches for and
applies the assignment to all design nodes that match the prefix reg with none, one,
or several characters following, such as reg1, reg[2], regbank, and reg12bank.
The “?” wildcard character matches any single character. For example, given an
assignment made to a node specified as reg?, the TimeQuest timing 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.
Both the collection commands get_cells and get_pins have three options that
allow you to refine searches that include the wildcard character. To refine your search
results, select the default behavior, the -hierarchical option, or the
-compatibility option.
1
The pipe character is used to separate one hierarchy level from the next in the
TimeQuest timing analyzer. For example, <absolute full cell name>|<pin suffix>
represents a hierarchical pin name with the “|” separating the hierarchy from the pin
name.
When you use the collection commands get_cells and get_pins without an
option, the default search behavior is performed on a per-hierarchical level of the pin
name; that is, the search is performed level by level. A full hierarchical name may
contain multiple hierarchical levels where a “|” is used to separate the hierarchical
levels, and each wildcard character represents only one hierarchical level. For
example,”*” represents the first hierarchical level and “*|*” represents the first and
second hierarchical levels.
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
7–60
Chapter 7: The Quartus II TimeQuest Timing Analyzer
Other Features
When you use the collection commands get_cells and get_pins with the
-hierarchical option, a recursive match is performed on the relative hierarchical
path name of the form <short cell name>|<pin name>. The search is performed on the
node name; for example, the last hierarchy of the name and not the hierarchy path.
Unlike the default behavior, this option does not limit the search to each hierarchy
level represented by the pipe character.
1
The pipe character cannot be used in the search with the get_cells
-hierarchical option. However, the pipe character can be used with the
get_pins collection search.
When you use the collection commands get_cells and get_pins with the
-compatibility option, the search performed is similar to that of the Quartus II
Classic Timing Analyzer. This option searches the entire hierarchical path and pipe
characters are not treated as special characters.
Assuming the following cells exist in a design:
foo
foo|bar
and the following pin names:
foo|dataa
foo|datab
foo|bar|datac
foo|bar|datad
Table 7–12 shows the results of using these search strings.
Table 7–12. 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 7–12:
(1) Due to the additional *|*| in the search string, the search result is <empty>.
Resetting a Design
Use the reset_design command to remove all timing constraints and exceptions
from the design under analysis. The command removes all clocks, generated clocks,
derived clocks, input delays, output delays, clock latency, clock uncertainty, clock
groups, false paths, multicycle paths, min delays, and max delays.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 7: The Quartus II TimeQuest Timing Analyzer
Other Features
7–61
This command provides a convenient way to return to the initial state of analysis
without the need to delete and re-create a new timing netlist.
Cross-Probing
The cross-probing feature allows you to locate paths and elements from the
TimeQuest timing analyzer to various tools available in the Quartus II software (and
vice versa).
From the TimeQuest GUI, you can right-click any path in the View pane and select
either Locate Path or Locate.
The source is the element in the From Node column and the destination is the element
in the To Node column.
The Locate Path option allows you to located the data arrival path, default, of the
currently selected row. To locate the data required time path select a row in the data
required path panel.
1
The Locate Required Path command is available only when there is a path to show;
unless the user reports the clock path as well, there is probably only a single node in
the required path. In this case, the command is not available.
The Locate option allows you to locate the highlighted element.
The Locate Path and Locate commands can cross-probe to either the Chip Planner,
Technology Map Viewer, or Resource Property Editor. Additionally, the Locate Path
option can cross-probe to Critical Path Settings.
From the Critical Path Settings dialog box in the Chip Planner, you can cross-probe to
the TimeQuest timing analyzer to report critical paths in the design.
locate
Use the locate command in the Console pane to cross-probe to the Chip Editor,
Critical Path Settings, Resource Property Editor, and the Technology Map Viewer.
Example 7–61 shows the locate command and options.
Example 7–61. locate Command
locate
[-chip]
[-color <black|blue|brown|green|grey|light_grey|orange|purple|red|white>]
[-cps]
[-label <label>]
[-rpe]
[-tmv]
<items>
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
7–62
Chapter 7: The Quartus II TimeQuest Timing Analyzer
Other Features
Table 7–13 describes the options for the locate command.
Table 7–13. locate Options
Option
Description
-chip
Locates the object in the Chip Planner.
-color
<black|blue|brown|green|
grey|light_grey|orange|
purple|red|white>
Identifies the objects you are locating.
-cps
Locates the object in the Critical Path Settings dialog of the Chip Planner.
-label <label>
Specifies a label used to identify the objects you are locating.
-rpe
Locates in the Resource Property Editor.
-tmv
Locates the object in the Technology Map Viewer.
<items>
Items to locate. Any collection or object (such as paths, points, nodes, nets,
keepers, registers, etc.) may be located by passing a reference to the
corresponding collection or object.
Example 7–62 shows how to cross-probe ten paths from TimeQuest timing analyzer to
the Chip Editor and locate all data ports in the Technology Map Viewer.
Example 7–62. Cross-probing from TimeQuest
# Locate all of the nodes in the longest ten paths
# into the Chip Editor
locate [get_path -npaths 10] -chip
# locate all ports that begin with data to the Tech Map Viewer
locate [get_ports data*] -tmv
The Quartus II Software Options and Compilation Report
The Quartus II software allows you to configure various options for the TimeQuest
timing analyzer report generation that are generated in the Compilation Report for
the design.
The TimeQuest timing analyzer settings, in the Settings dialog box, allow you to
configure the options shown in Table 7–14.
Table 7–14. TimeQuest Timing Analyzer Settings
Options
Description
.sdc files to include in the project
Adds and removes .sdc files associated with the project.
Enable Advanced I/O Timing
Generates advanced I/O timing results from board trace models specified for each pin.
Enable multicorner timing analysis
during compilation
Generates multiple reports for all available operating conditions of the target device.
Report worst-case paths during
compilation
Generates worst-case path reports per clock domain.
Tcl Script File for customizing
report during compilation
Specifies any custom scripts to be sourced for any custom report generation.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 7: The Quartus II TimeQuest Timing Analyzer
Conclusion
1
7–63
The options shown in Table 7–14 control only the reports generated in the
Compilation Report, and do not control the reports generated in the TimeQuest
timing analyzer.
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 7–63 shows the TIMEQUEST_REPORT_WORST_CASE_TIMING_PATHS and
TIMEQUEST_REPORT_NUM_WORST_CASE_TIMING_PATHS assignments as they
appear in a .qsf.
Example 7–63. Specifying generation of a Worst Case Timing Report
#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
Conclusion
The TimeQuest timing analyzer addresses the requirements of complex designs,
resulting in increased productivity and efficiency through its intuitive user interface,
support of industry-standard constraints format, and scripting capabilities. The
TimeQuest timing analyzer is a next-generation timing analysis tool that supports the
industry-standard SDC format and allows designers to create, manage, and analyze
complex timing constraints and to perform advanced timing verification.
Document Revision History
Table 7–15 shows the revision history for this chapter.
Table 7–15. Document Revision History (Part 1 of 2)
Date
Version
Changes Made
July 2010
10.0.0
Updated to link to content on SDC commands and the TimeQuest timing analyzer GUI
in Quartus II help.
November 2009
9.1.0
Updated for the Quartus II software version 9.1, including:
© July 2010
Altera Corporation
■
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
Quartus II Handbook Version 10.0 Volume 3: Verification
7–64
Chapter 7: The Quartus II TimeQuest Timing Analyzer
Document Revision History
Table 7–15. Document Revision History (Part 2 of 2)
Date
Version
November 2008
8.1.0
Changes Made
Updated for the Quartus II software version 8.1, including:
■
May 2008
8.0.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
Updated for the Quartus II software version 8.0, including:
■
Changed the heading “Specify Design Timing Requirements” to “The Quartus II
TimeQuest Timing Analyzer Flow Guidelines” on page 7–26
■
In “SDC Constraint Files” on page 7–29, added information about order-sensitivity
■
Added a new section on “Metastability” on page 7–19
■
Added a new section on “Common Clock Path Pessimism” on page 7–22
■
Removed information about Asynchronous clocks from “Clock Groups” on page
7–43
■
Updated information in Example 7–28
■
Added three entries to Table 7–22
■
Added information to Table 7–24
■
Added information about the RSKM to “report_rskm” on page 7–80, including a
formulaic equation (Equation 12)
■
Added the section “Clock Groups” on page 7–43
■
Added Table 7–44 to “report_clock_fmax_summary” on page 7–86
■
Added qualifier to introduction of Table 7–46
■
Added Speed Grade information to Table 7–46
■
Removed [-dtw] and added [-add] to information about the
derive_clock_uncertainty command (“Derive Clock Uncertainty” on page 7–47)
■
Added the section “report_metastability” on page 7–68
■
Added a new information about RSKM to “report_rskm” on page 7–80
■
Added the section “Cross-Probing” on page 7–93
■
Minor editorial updates
■
Added hyperlinks to referenced documents throughout 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 10.0 Volume 3: Verification
© July 2010 Altera Corporation
8. Best Practices for the Quartus II
TimeQuest Timing Analyzer
QII53024-10.0.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. This chapter provides the steps to fully constrain an FPGA design with the
Quartus® II TimeQuest Timing Analyzer in the following sections:
1
f
■
“Clock Requirements”
■
“I/O Requirements” on page 8–4
■
“Exceptions” on page 8–5
The sections are ordered in the recommended flow for applying timing constraints
and exceptions in the TimeQuest timing analyzer.
For more information about constraints and exceptions supported by the TimeQuest
timing analyzer, refer to the Quartus II TimeQuest Timing Analyzer chapter in volume 3
of the Quartus II Handbook.
Clock Requirements
The TimeQuest timing 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
and routes for your design.
Clocks should be the first constraints specified in Synopsys Design Constraint (.sdc)
files. This is important because the TimeQuest timing analyzer reads .sdc constraints
and exceptions from top to bottom in the file. Clocks should be defined first, because
other constraints may reference previously defined clocks.
Base Clocks
Base clocks are the primary input clocks generated into the FPGA. Unlike
phase-locked loops (PLLs) that are derived in the FPGA, base clocks are usually
generated in off-chip oscillators or forwarded from an external device. Base clocks are
defined first, because derived clocks and other constraints can reference the base
clocks.
Use the create_clock SDC 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, you must use the get_ports commands.
Example 8–1 shows how to specify a 100-MHz requirement on a clk_sys input clock
port.
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
8–2
Chapter 8: Best Practices for the Quartus II TimeQuest Timing Analyzer
Clock Requirements
Example 8–1. create_clock Command
create_clock -period 10 [get_ports clk_sys]
You can apply multiple clocks on the same clock node with the -add option. If two
oscillators drive the same clock port on the FPGA, the following SDC commands are
used:
create_clock -period 10 -<name> clk_100 [get_ports clk_sys] r
create_clock -period 5 -<name> clk_200 [get_ports clk_sys] -add r
Derived Clocks
Derived clocks are generated in the FPGA and can modify or synthesize a source
clock signal. Derived clocks, which are PLLs or register clock dividers, are constrained
after all base clocks are constrained in the .sdc file. Derive clocks capture all clock
delays/latency where the derive clock target is defined. This ensures 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.
The TimeQuest timing analyzer supports the derive_pll_clocks command to
automatically constrain all PLL outputs in the FPGA.
Example 8–2 shows a divide-by-two clock divider.
Example 8–2. Clock Divider
create_clock -period 10 [get_ports clk_sys]
create_generated_clock -name clk_div_2 -divide_by 2 -source [get_pins reg|clk] [get_pins
reg|regout]
When using the create_generated_clock constraint, Altera recommends that the
-source option point to the closest clock pin of the specified target and not the clock
port. In Example 8–2, the -source option points to the clock pin of the register
instead of the clock port clk feeding the register’s reg clock pin. Use this when
multiple clock constraints are specified for the same pin in a design.
The TimeQuest provides the derive_pll_clocks command that automatically
generates derive clocks for all PLL clock outputs. The properties of the generated
clocks on the PLL outputs will match those that have been defined for the PLL.
Virtual Clocks
A virtual clock does not have a real source in your design and does not interact
directly with your design. Virtual clocks are created with the create_clock
command, but no targets are specified. Example 8–3 shows the command to create a
10 ns virtual clock.
Example 8–3. Creating a 10 ns Virtual Clock
create_clock -period 10 -name my_virt_clk r
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 8: Best Practices for the Quartus II TimeQuest Timing Analyzer
Clock Requirements
8–3
Figure 8–1 and Example 8–4 show when a virtual clock is used. If an FPGA interfaces
with an external device, and both the FPGA and external device have different clock
sources, the clock source for the external device is modeled with a virtual clock.
Figure 8–1. Inter-Clock Transfer
External Device
Altera FPGA
data_in
D reg1 Q
D reg1 Q
clk_in
50 MHz
100 MHz
Example 8–4. Virtual Clock Example 1
#create base clock for the design
create_clock -period 5 [get_ports clk_in]
#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 data_out]
Altera recommends using virtual clocks if you model external delays with the
set_input_delay and set_output_delay constraints. This is important if you
use the derive_clock_uncertainty command for your design. The virtual clock
prevents the derive_clock_uncertainty command from applying clock
uncertainties for either intra- or inter-clock transfers on an I/O interface clock transfer.
Altera recommends creating an equivalent virtual clock for each clock in your design
that feeds an input or output port (refer to Figure 8–2 and Example 8–5).
Figure 8–2. I/O Interface Specifications
External Device
Altera FPGA
data_in
D reg1 Q
D reg1 Q
clk_in
100 MHz
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
8–4
Chapter 8: Best Practices for the Quartus II TimeQuest Timing Analyzer
I/O Requirements
Example 8–5. .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]
I/O Requirements
You should specify all timing requirements to fully analyze a design. This includes
specifying internal and external timing requirements. With external timing
requirements specified, the I/O interface or periphery of the FPGA is verified against
any system specification. The TimeQuest timing analyzer supports input and output
external delay modeling.
You should specify I/O requirements after all clocks in your design are constrained.
When specifying I/O requirements, Altera recommends referencing a virtual clock in
the constraints.
f
For guidelines to determine delay values for set_input_delay and
set_output_delay, refer to the Quartus II TimeQuest Timing Analyzer chapter in
volume 3 of the Quartus II Handbook.
Input Requirements
Input requirements allow all the external delays feeding into the FPGA to be
specified. The requirements are specified for all input ports in your design.
You can use the set_input_delay command to specify external input delay
requirements. Altera recommends that the set_input_delay command reference a
virtual clock for the -clock option. Using a virtual clock allows the TimeQuest
timing analyzer to correctly derive clock uncertainties for inter and intra clock
transfers. The virtual clock defines the launching clock for the input port. The latching
clock inside the chip that captures the input data is automatically determined, because
all clocks in the chip are defined. Figure 8–3 shows an example of an input delay
referencing a virtual clock.
Figure 8–3. Set Input Delay
External Device
Altera Device
Oscillator
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 8: Best Practices for the Quartus II TimeQuest Timing Analyzer
Exceptions
8–5
Output Requirements
The output requirements allow all external delays from the FPGA to be specified for
all output ports in your design.
You can use the set_output_delay command to specify external output delay
requirements. The set_output_delay command must reference a virtual clock for
the -clock option. The virtual clock defines the latching clock for the output port.
The launching clock inside the chip that launches the output data is automatically
determined, because all clocks in the chip are defined. Figure 8–4 shows an example
of an output delay referencing a virtual clock.
Figure 8–4. Output Delay
Altera Device
External Device
Oscillator
Exceptions
Timing exceptions in the TimeQuest timing analyzer provide a way to modify the
default timing analysis behavior to match the analysis required by your design. The
TimeQuest timing analyzer supports the following three major categories of
exceptions:
■
False paths
■
Minimum and maximum delays
■
Multicycles
Timing exceptions are specified after clocks, and input and output delay constraints,
because timing exceptions can modify the default analysis.
False Paths
You remove a specified path from analysis when you specify a false path in your
design. This path is either a point-to-point or clock-to-clock path. An example is a
static configuration register that is written once during power-up initialization, but
will not change state again. Although these signals 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 those clock domains. However, you can selectively make
false path exceptions from the static configuration register to all endpoints.
Example 8–6 shows how to make false path exceptions from all registers beginning
with A to all registers beginning with B.
Example 8–6. False Path
set_false_path -from [get_pins A*] -to [get_pins B*]
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
8–6
Chapter 8: Best Practices for the Quartus II TimeQuest Timing Analyzer
Exceptions
The TimeQuest timing analyzer assumes all clocks are related unless you specify
otherwise. Setting clock groups is an efficient way of making false path exceptions for
clock-to-clock timing relationships in your design. It requires fewer line entries to
make false path exceptions between clocks, compared to writing multiple
set_false_path exceptions between every clock transfer to be cut. Use the
set_clock_groups command to collect groups of signals related to each other, and
use -asynchronous to specify that each group of clocks is asynchronous with each
other. In the case where multiple clocks are applied to the same port for multi-mode
operation, use set_clock_groups with -exclusive to declare these clocks are
placed into separate groups and mutually exclusive to each other. The clocks cannot
physically exist in your design at the same time.
Minimum and Maximum Delays
Use the set_max_delay and set_min_delay constraints for asynchronous signals
that do not have a specific clock relationship in your design, but require a bounded
maximum and minimum path delay. This timing exception applies to paths that go
from port to port through the FPGA without a register stage in the path. If you use
this timing exception to constrain the path delay, specify both the maximum and
minimum delay of the path. Do not constrain only the maximum or the minimum
value. The set_max_delay and set_min_delay commands modify the setup and
hold relationship equal to the constraint’s value.
You can also use the set_net_delay constraint to specify the maximum, minimum,
or skew for any edge in your design. This constraint is used when no clock
relationships are defined or required.
f
For more information about the set_net_delay constraint, refer to the Quartus II
TimeQuest Timing Analyzer chapter in volume 3 of the Quartus II Handbook.
Multicycles
Multicycle paths are often difficult to identify in a design. You must understand the
design functionality to understand if a signal is updated or sampled on the default
clock edge relationships derived by the TimeQuest timing analyzer. Thorough
coverage of multicycle paths in your design can increase performance of the Fitter and
provide better quality of results during compilation, because the coverage relaxes
some invalid setup and hold edge relationships.
An example of a potential multicycle path would be long combinational paths in
which the latching register does not require data stability on every clock edge, but
only on every second clock edge. This multicycle path is dependent on the endpoint
register’s use of that signal. In this case, the set_multicycle_path -setup 2
command states that data is stable at the endpoint every two clock cycles of the
endpoint latch clock.
If you specify a multicycle path, Altera recommends defining both the setup and hold
multicycle relationships. For the preceding example, setting data at the endpoint can
take two clock cycle, and the minimum hold time relationship is defined with a
multicycle as well. The set_multicycle_path -hold value is (N – 1), in which N
is equal to the set_multicycle_path -setup value for a register-to-register path
in the same clock domain. However, if data crosses different clock domains, the phase
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 8: Best Practices for the Quartus II TimeQuest Timing Analyzer
Conclusion
8–7
and period of the launch and latch clock may change the proper -setup and -hold
values to something different than -setup N and -hold (N – 1). Use these
multicycles with caution and examine the timing paths carefully in the TimeQuest
timing analyzer before and after applying the multicycle to determine if the launch
and latch clock edges are in the proper relationship.
f
For more information about multicycles in the TimeQuest timing analyzer, refer to AN
481: Applying Multicycle Exceptions in the TimeQuest Timing Analyzer.
Conclusion
Specifying all timing constraints and exceptions for your design is one of the most
important aspects of design implementation in the Quartus II software. Constraints
and exceptions allow the Quartus II Fitter to focus on the critical paths in your design
and reduce the amount of time spent on non-critical parts of the design. Also,
constraints and exceptions provide an easy method to verify the design’s timing
requirements. Follow the guidelines and flow in this chapter for successful design
implementation in the Quartus II software.
Document Revision History
Table 8–1 shows the revision history for this chapter.
Table 8–1. Document Revision History
Date
© July 2010
Version
Changes Made
July 2010
10.0.0
Minor editorial changes to document. No updates to
technical content.
November 2009
9.1.0
■
Added example to “Derived Clocks” on page 8–2.
■
Updated “Base Clocks” on page 8–1.
March 2009
9.0.0
Initial release.
f
For previous versions of the Quartus II Handbook, refer to the Quartus II Handbook
Archive.
f
Take an online survey to provide feedback about this handbook chapter.
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
8–8
Quartus II Handbook Version 10.0 Volume 3: Verification
Chapter 8: Best Practices for the Quartus II TimeQuest Timing Analyzer
Document Revision History
© July 2010 Altera Corporation
9. Switching to the Quartus II TimeQuest
Timing Analyzer
QII53019-10.0.0
This chapter describes the benefits of switching to the Quartus II TimeQuest Timing
Analyzer, the differences between the TimeQuest timing analyzer and Classic timing
analyzer, and the process you should follow to switch a design from using the Classic
timing analyzer to the TimeQuest timing analyzer.
Benefits of Switching to the Quartus II TimeQuest Timing Analyzer
Increasing design complexity requires a timing analysis tool with greater capabilities
and flexibility. The Quartus II TimeQuest Timing 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 DDR
memory interfaces, are much simpler to constrain and analyze with the TimeQuest
timing analyzer.
There are three main differences between the Classic timing analyzer and the
TimeQuest timing analyzer. Unlike the Classic timing analyzer, the TimeQuest timing
analyzer has the following three benefits:
■
All clocks are related by default. Refer to “Related and Unrelated Clocks” on
page 9–10.
■
The default hold multicycle value is zero. Refer to “Hold Multicycle” on
page 9–18.
■
You must constrain all ports and ripple clocks. Refer to “Automatic Clock
Detection” on page 9–15.
Chapter Contents
This chapter contains the following sections:
© July 2010
■
“Switching Your Design” describes the four-step process you should follow to
switch a design from the Classic Timing Analyzer to the TimeQuest timing
analyzer.
■
“Differences Between the Timing Analyzers” on page 9–3 describes terminology,
constraints, clocks, hold multicycle, and other differences.
■
“Timing Assignment Conversion” on page 9–24 is a comprehensive guide to
converting Quartus II Classic QSF timing assignments to Quartus II TimeQuest
SDC constraints.
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
9–2
Chapter 9: Switching to the Quartus II TimeQuest Timing Analyzer
Switching Your Design
■
“Conversion Utility” on page 9–41 describes a utility that helps you convert
Classic QSF timing assignments to the Quartus II TimeQuest SDC constraints.
■
“Notes” on page 9–50 includes notes about support for specific features in the
current version of the TimeQuest timing analyzer.
Switching Your Design
You should use the following process to switch a design from the Classic timing
analyzer to the TimeQuest timing analyzer. The process is composed of the following
steps, which are described in detail in the next sections:
1. Compile your design in the Quartus II software with the Classic timing analyzer
set to perform timing analysis (page 9–2).
2. Create a Synopsys Design Constraints (.sdc) file that contains timing constraints
(page 9–2).
3. Perform timing analysis with the TimeQuest timing analyzer and examine the
reports (page 9–3).
4. Set the default timing analyzer to the TimeQuest Timing Analyzer (page 9–3).
Compile Your Design
To begin, compile your design with the Quartus® II software, and with the Classic
timing analyzer. To run the Classic timing analyzer in the Quartus II GUI, on the
Processing menu, click Start, then click Start Classic Timing Analyzer. To run the
Classic timing analyzer if you are a command-line user, type quartus_tan <project>
r at a system command prompt.
Create an .sdc File
The TimeQuest timing analyzer supports SDC format constraints. If you are familiar
with SDC terminology, you can create an .sdc file with any text editor and skip to
“Start the Quartus II TimeQuest Timing Analyzer” on page 9–3. Name the .sdc file
<revision>.sdc (where <revision> is the current revision of your project) and save it in
your project directory.
f
For more information about TimeQuest SDC constraints, refer to the Quartus II
TimeQuest Timing Analyzer chapter in volume 3 of the Quartus II Handbook.
Alternately, you can use a Quartus II TimeQuest conversion utility to help you
convert the timing assignments in an existing Quartus II Settings File (.qsf) to
corresponding SDC constraints.
Conversion Utility
To run the Quartus II TimeQuest conversion utility, click Generate SDC file from
QSF on the Constraints menu. 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 file created by the conversion utility is named <revision>.sdc.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 9: Switching to the Quartus II TimeQuest Timing Analyzer
Differences Between the Timing Analyzers
9–3
After conversion, review the .sdc file to ensure it is correct and complete, and make
changes if necessary. Refer to “Constraint File Priority” on page 9–7 for
recommendations.
The conversion utility cannot convert some types of Classic timing analyzer
assignments if no corresponding SDC constraint exists, or if there is more than one
potentially equivalent SDC constraint. In these cases, correct conversion requires
knowledge of the intended function of your design. Manually convert any ambiguous
assignments based on the guidelines in “Timing Assignment Conversion” on
page 9–24.
Start the Quartus II TimeQuest Timing Analyzer
To open the Quartus II TimeQuest GUI, on the Tools menu, click TimeQuest Timing
Analyzer. The Quartus II TimeQuest GUI automatically opens the project you have
open in the Quartus II GUI.
If you use the system command prompt to open the TimeQuest timing analyzer, type
quartus_staw r to open the Quartus II TimeQuest GUI, or type quartus_sta -s
r to start the TimeQuest timing analyzer Tcl shell.
Set the Default Timing Analyzer
To set the TimeQuest timing analyzer as the default timing analyzer for your project,
in the Quartus II GUI, on the Assignments menu, click Settings, then select the
Timing Analysis Settings category, and turn on Use TimeQuest Timing Analyzer
during compilation. You can make the same setting in your project’s .qsf file with the
following Tcl command:
set_global_assignment -name USE_TIMEQUEST_TIMING_ANALYZER ON
The default timing analyzer setting is specific to each project, so you can decide on a
per-project basis whether to use the TimeQuest timing analyzer or the Classic timing
analyzer.
In the Quartus II software, a timing analyzer performs two functions:
■
Processing timing constraints and exceptions that affect how your design is placed
and routed
■
Reporting after place and route is complete so you know whether the design meets
timing requirements
Although you can use one timing analyzer to process timing constraints during place
and route and the other for reporting, you should use the same timing analyzer for
both. The Classic timing analyzer uses assignments in the .qsf file, and the TimeQuest
timing analyzer uses constraints in the .sdc file. Any differences between the timing
assignments in the two files may cause inconsistent results.
Differences Between the Timing Analyzers
The differences between the TimeQuest timing analyzer and the Classic timing
analyzer are described in the following sections:
© July 2010
■
“Terminology” on page 9–4
■
“Constraints” on page 9–5
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
9–4
Chapter 9: Switching to the Quartus II TimeQuest Timing Analyzer
Differences Between the Timing Analyzers
■
“Clocks” on page 9–10
■
“Hold Multicycle” on page 9–18
■
“Fitter Behavior” on page 9–20
■
“Reporting” on page 9–20
■
“Timing Assignment Conversion” on page 9–24
Terminology
This section introduces the industry-standard SDC terminology used by the
TimeQuest timing analyzer.
Netlists
The TimeQuest timing analyzer uses SDC naming conventions for netlists. Netlists
consist of cells, pins, nets, ports, and clocks.
1
■
Cells are instances of fundamental hardware elements in Altera® FPGAs (such as
logic elements, look-up tables, 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 toplevel module inputs and outputs (device inputs and outputs).
Figure 9–1 shows a sample design, and Figure 9–2 shows the Quartus II TimeQuest
netlist representation of the design. Netlist elements in Figure 9–2 are labeled to
illustrate the SDC terminology.
Figure 9–1. Sample Design
ina
inrega
ab
inb
outreg
out
inregb
clk
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 9: Switching to the Quartus II TimeQuest Timing Analyzer
Differences Between the Timing Analyzers
9–5
Figure 9–2. Quartus II TimeQuest Timing 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~clkctrl
clk
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 timing analyzer supports the
following Altera-specific collection types:
■
Keepers—Non-combinational 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 Timing Analyzer terminology, refer to the
Quartus II TimeQuest Timing Analyzer chapter in volume 3 of the Quartus II Handbook.
Constraints
The Quartus II Classic and TimeQuest timing analyzers 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 timing analyzer stores all SDC timing constraints in .sdc files. The
Classic timing analyzer stores all timing assignments in the .qsf file for your project.
When you use the TimeQuest timing analyzer, your .qsf file contains all assignments
and settings except for SDC constraints. The TimeQuest timing analyzer ignores the
timing assignments in your .qsf file except when the conversion utility converts
Quartus II Classic QSF timing assignments to Quartus II TimeQuest 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.
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
9–6
Chapter 9: Switching to the Quartus II TimeQuest Timing Analyzer
Differences Between the Timing Analyzers
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 timing analyzer, you cannot use the Assignment Editor to enter SDC
constraints. You must use one of the following methods to enter Quartus II TimeQuest
constraints:
■
Enter constraints at the Tcl prompt in the TimeQuest timing analyzer
■
Enter constraints in an .sdc file with a text editor or SDC editor
■
Use the constraint entry commands on the Constraints menu in the TimeQuest
timing analyzer GUI
You can enter timing assignments for the Classic timing analyzer even if no timing
netlist exists for your design. The TimeQuest timing analyzer requires that a netlist
exist for interactive constraint entry. Each TimeQuest timing analyzer constraint is a
Tcl command evaluated in real-time, if entered directly in the Tcl console. As part of
this evaluation, the TimeQuest timing analyzer validates all names. To do this, SDC
commands can only be evaluated after a netlist is created. An .sdc file can be created
at any time using the TimeQuest timing analyzer or any other text editor, but a netlist
is required before an .sdc file can be sourced. You must create a timing netlist in the
TimeQuest timing analyzer before you can enter constraints with either of the
following interactive methods:
■
At the Tcl console of the TimeQuest timing analyzer
■
With commands on the Constraints menu in the TimeQuest timing analyzer GUI
If you enter constraints with a text editor separate from the TimeQuest timing
analyzer, no timing netlist is required.
To create a timing netlist in the TimeQuest timing analyzer, use the
create_timing_netlist command, or double-click Create Timing Netlist in the
Tasks pane of the Quartus II TimeQuest GUI.
If you have never compiled your design, and you want to use the TimeQuest timing
analyzer to enter constraints interactively, you must synthesize your design before
you create a timing netlist. To synthesize your design from the command line, type
the following command at a system command prompt:
quartus_map <project name> r
If you use the Quartus II GUI, ensure that your project is open, then point to Start on
the Processing menu, and click Start Analysis & Synthesis.
To create the timing netlist, open the TimeQuest timing analyzer. Then, on the Netlist
menu, click Create Timing Netlist, select Post-map in the Create Timing Netlist
dialog box, and click OK. Alternately, at the TCL console, type the following
command:
create_timing_netlist -post_map r
Time Units
Enter time values are in default time units of nanoseconds (ns) with up to three
decimal places. Note that the TimeQuest timing analyzer does not display the default
time unit when it displays time values.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 9: Switching to the Quartus II TimeQuest Timing Analyzer
Differences Between the Timing Analyzers
9–7
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 timing analyzer extension.
You can specify clock constraints with period or frequency in the TimeQuest timing
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 file before reconverting assignments. If
you make changes to the .sdc file, you can manually copy the updated MegaCore
timing constraints to your .sdc file.
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 timing 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.
Constraint File Priority
The TimeQuest timing analyzer searches for .sdc files with a specific priority, as
shown in Figure 9–3.
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
9–8
Chapter 9: Switching to the Quartus II TimeQuest Timing Analyzer
Differences Between the Timing Analyzers
Figure 9–3. .sdc File 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 file with a
name other than <revision>.sdc, you must add the files to your project so the
TimeQuest timing analyzer can find them. If you use the Quartus II software, click
Add/Remove Files in Project on the Project menu, and add the appropriate .sdc files.
You can also add .sdc files to your project with the following Tcl command in your
.qsf file, repeated once for each .sdc file:
set_global_assignment -name SDC_FILE <SDC file name>
The TimeQuest timing analyzer reads constraint files from the files list in the order
they are listed.
If you use an .sdc file 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 file created by the conversion utility, so your constraints have
higher priority.
The TimeQuest timing analyzer does not run the conversion utility automatically
when it cannot find an .sdc file according to the priority shown in Figure 9–3. IYou
may be prompted to run the conversion utility from the Constraints menu in the
Quartus II TimeQuest GUI.
You must review the .sdc file as you would when manually running the conversion
utility. Refer to “Reviewing Conversion Results” on page 9–47 for information about
reviewing the converted constraints.
If no .sdc file exists when you run the Quartus II Fitter, and you have turned on Use
TimeQuest Timing Analyzer during compilation, the Fitter does not create an .sdc
file automatically, but it attempts to meet a default 1 GHz constraint on all clocks in
your design.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 9: Switching to the Quartus II TimeQuest Timing Analyzer
Differences Between the Timing Analyzers
9–9
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 timing 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 9–1 result in a multicycle assignment of 2 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 9–1. Quartus II 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 9–2 shows SDC versions of the preceding Classic timing analyzer timing
assignments. However, the TimeQuest timing analyzer evaluates the constraints from
top to bottom (regardless of point-to-point or single point), so the path from A_reg to
B_reg receives a multicycle exception of 3 because it is ordered second.
Example 9–2. Quartus II TimeQuest Timing 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
Ambiguous Constraints
Because of capabilities in the TimeQuest timing analyzer, some Quartus II Classic
assignments can be ambiguous after conversion by the conversion utility. These
assignments require manual updating based on your knowledge of your design.
Figure 9–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 timing analyzer.
Figure 9–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 2 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
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
9–10
Chapter 9: Switching to the Quartus II TimeQuest Timing Analyzer
Differences Between the Timing Analyzers
In Figure 9–4, this assignment applies to the path from reg_c to reg_d. In the
TimeQuest timing 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 Quartus II TimeQuest exceptions shown in Example 9–3 are not ambiguous
because they use collections to explicitly specify the targets of the exception.
Example 9–3. Unambiguous Quartus II TimeQuest Timing 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
Clocks
The Quartus II Classic and TimeQuest timing analyzers detect, analyze, and report
clocks differently. The following sections describe these differences.
Related and Unrelated Clocks
In the TimeQuest timing 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 9–5 shows a circuit with a path between two clock domains. The TimeQuest
timing 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 9–5. Cross Clock Domain Path
data_a
reg_a
clock_a
data_out
reg_b
clock_b
To make clocks unrelated in the TimeQuest timing analyzer, use the
set_clock_groups command with the -exclusive option. For example, the
following command makes clock_a and clock_b unrelated, so the TimeQuest
timing analyzer does not analyze paths between the two clock domains.
set_clock_groups -exclusive -group {clock_a} -group {clock_b}
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 9: Switching to the Quartus II TimeQuest Timing Analyzer
Differences Between the Timing Analyzers
9–11
Clock Offset
In the TimeQuest timing analyzer, clocks can have non-zero 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 waveform option for the create_clock
command to specify the rising and falling edge times, as shown in this example:
-waveform {<rising edge time> <falling edge time>}
Figure 9–6 shows a clock constraint with an offset in the TimeQuest timing analyzer
GUI.
Figure 9–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 9–11 for an example that illustrates the different effects of
offset and latency.
Clock Latency
The TimeQuest timing 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 9–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. You should always turn on the Enable Clock Latency option
in the Classic timing analyzer. This option is in the More Settings box of the Timing
Settings dialog box.
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
9–12
Chapter 9: Switching to the Quartus II TimeQuest Timing Analyzer
Differences Between the Timing Analyzers
Figure 9–7. Offset and Latency Example Circuit
in
reg_a
clk
3 ns
reg_b
out
PLL
The period for clk is 10 ns, and the period for the 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.
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 9–8).
Figure 9–8. Setup Relationship Using Offset
Setup Relationship Using Offset
PLL
clk
0 2
10 12
20 22
Equation 9–1 shows how to calculate the slack value for the path from reg_a to
reg_b.
Equation 9–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 2 and a hold
multicycle assignment with a value of 1 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 9–9).
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 9: Switching to the Quartus II TimeQuest Timing Analyzer
Differences Between the Timing Analyzers
9–13
Figure 9–9. Setup Relationship Using Latency
Setup Relationship Using Latency
PLL
clk
0 2
10 12
20 22
Equation 9–2 shows how to calculate the slack value for the path from reg_a to
reg_b.
Equation 9–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 timing analyzer does not ignore clock uncertainty
when you specify a setup or hold relationship between two clocks. Figure 9–10 and
Figure 9–11 illustrate the different behavior between the Quartus II TimeQuest and
Classic timing analyzers.
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
timing 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 timing analyzer is 1 ns less than in the Classic timing analyzer because of
the way they analyze clock uncertainty.
Figure 9–10. Quartus II Classic Timing Analyzer Behavior
0 ns
7 ns
10 ns
Setup Relationship with and without Uncertainty
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
9–14
Chapter 9: Switching to the Quartus II TimeQuest Timing Analyzer
Differences Between the Timing Analyzers
Figure 9–11. Quartus II TimeQuest Timing Analyzer Behavior
0
6 7
10
Clock Setup Uncertainty
Setup Relationship with Uncertainty
Setup Relationship without Uncertainty
Derived and Generated Clocks
Generated clocks in the TimeQuest timing 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 timing 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 timing 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 9–12 shows a simple ripple clock that you should constrain with generated
clocks in the TimeQuest timing analyzer.
Figure 9–12. Generated Clocks Circuit
reg_a
reg_b
clk
The TimeQuest timing analyzer constraints shown in Example 9–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 9–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
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 9: Switching to the Quartus II TimeQuest Timing Analyzer
Differences Between the Timing Analyzers
9–15
Automatic Clock Detection
The Quartus II Classic and TimeQuest timing analyzers 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 timing analyzer also traces back along the clock
network, but it stops at registers.
You can use two SDC commands in the TimeQuest timing 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
derive_clocks Command
Figure 9–13 shows a circuit with a divide-by-2 register and indicates the clock
network delays as A, B, and C. The following explanation describes how the Classic
and TimeQuest timing analyzers detect the clocks in Figure 9–13.
Figure 9–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 timing 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 timing 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 timing 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.
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
9–16
Chapter 9: Switching to the Quartus II TimeQuest Timing Analyzer
Differences Between the Timing Analyzers
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.
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 9–14.
Figure 9–14. Detectable Clock
a_in
b
■
If you do not make any clock settings, and then you run derive_clocks, it detects
a_in as a clock according to rule 11, because there are no other clocks feeding the
register.
■
If you create a clock with b as its target, and then you run derive_clocks, it does
not detect a_in as a clock according to rule 11a, because a_in feeds only another
clock.
The following examples show how the derive_clocks command detects clocks in the
circuit shown in Figure 9–15.
Figure 9–15. Two Detectable Clocks
a_in
b_in
■
If you do not make any clock settings and then you run derive_clocks, it selects a
clock arbitrarily, according to rule 11c.
■
If you create a clock with a_in as its target and then you run derive_clocks, it
does not detect b_in as a clock according to rule 11b, because another clock
(a_in) feeds the register.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 9: Switching to the Quartus II TimeQuest Timing Analyzer
Differences Between the Timing Analyzers
9–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 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 9–10.
Hold Relationship
The Quartus II TimeQuest and Classic timing analyzers choose the worst-case hold
relationship differently. Refer to Figure 9–16 for sample waveforms to illustrate the
different effects.
Figure 9–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 timing analyzer calculates worst-case hold relationships for
all possible setup relationships and chooses the absolute worst-case hold relationship.
The TimeQuest timing 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 timing analyzer chooses Hold Check A2 as the absolute worst-case
hold relationship.
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
9–18
Chapter 9: Switching to the Quartus II TimeQuest Timing Analyzer
Differences Between the 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 9–17 shows a
circuit that illustrates this situation.
Figure 9–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 timing analyzer, clocks are abstract objects that are associated with
nodes in the timing netlist. The TimeQuest timing 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 Quartus II Classic and
TimeQuest timing analyzers. 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 timing 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 1, and is the
number of clock cycles away from the setup edge. In the TimeQuest timing 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 timing analyzer, the default hold edge is
one edge before or after the setup edges. Subtract 1 from any hold multicycle value in
the Classic timing analyzer to compute the equivalent value for the TimeQuest timing
analyzer.
In the Classic timing analyzer, you can set the default value of the hold multicycle
assignment to One or Same as Multicycle. The default value applies to any
multicycle assignment in your design that does not also have a multicycle hold
assignment. Figure 9–18 illustrates the difference between One and Same as
Multicycle for a multicycle assignment of 2 using the Classic timing analyzer.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 9: Switching to the Quartus II TimeQuest Timing Analyzer
Differences Between the Timing Analyzers
9–19
Figure 9–18. Difference Between One and Same As Multicycle
Hold Edge for Value of One
Hold Edge for Value of
Same as Multicycle
Setup Edge for Multicycle = 2
If the default value is One, the Classic timing analyzer uses the clock edge one before
the setup edge for hold analysis. If the default value is Same as Multicycle, the
Classic timing analyzer uses the clock edge that is <value of multicycle assignment>
edges back from the setup edge.
Figure 9–19 shows simple waveforms for a cross-clock domain transfer with the
indicated setup and hold edges.
Figure 9–19. First Relationship Example
Hold Edge
Setup Edge
In the TimeQuest timing analyzer, only a multicycle exception of 2 is required to
constrain the design for the indicated setup and hold relationships.
In the Classic timing analyzer, if the Default Hold Multicycle value is One, only a
multicycle assignment of 2 is required to constrain the design.
If the Default Hold Multicycle value is Same as Multicycle, you must make two
assignments to constrain the design:
■
A multicycle assignment of 2
■
A hold multicycle assignment of 1 to override the default value
Figure 9–20 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 9–20. Second Relationship Example
Hold Edge
© July 2010
Altera Corporation
Setup Edge
Quartus II Handbook Version 10.0 Volume 3: Verification
9–20
Chapter 9: Switching to the Quartus II TimeQuest Timing Analyzer
Differences Between the Timing Analyzers
In the TimeQuest timing analyzer, you must use the following two exceptions:
■
A multicycle exception of 2
■
A hold multicycle exception of 1, because the hold edge is one edge behind the
default hold edge, which is one edge after the setup edge.
In the Classic timing analyzer, if the Default Hold Multicycle value is One, you must
make two assignments to constrain the design:
■
A multicycle assignment of 2
■
A hold multicycle assignment of 2 to override the default value
In the Classic timing analyzer, if the Default Hold Multicycle value is Same as
Multicycle, only a multicycle assignment of 2 is required to constrain the design.
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,
or, for the Classic timing analyzer, use the Default Hold Multicycle setting.
Fitter Behavior
The behavior for one value of the Optimize hold time Fitter assignment differs
between the TimeQuest timing analyzer and the Classic timing analyzer. When you
set the TimeQuest timing analyzer as the default timing analyzer, the I/O Paths and
Minimum TPD Paths value directs the Fitter to optimize all hold time paths, which
has the same affect as the All Paths value.
Fitter Performance
If you use the TimeQuest timing analyzer as your default timing analyzer, the Fitter
memory use and compilation time may increase. However, the timing analysis time
may decrease.
Reporting
The TimeQuest timing 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 timing
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 timing 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.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 9: Switching to the Quartus II TimeQuest Timing Analyzer
Differences Between the Timing Analyzers
9–21
Paths and Pairs
In reporting, the most significant difference between the two analyzers is that the
TimeQuest timing 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
timing analyzer. Figure 9–21 shows a sample circuit followed by a description of the
differences between path and pair reporting.
Figure 9–21. 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 clk, 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 timing analyzer reports both
failing paths regA  C  regB and regA  D  regB. It also reports path
regA  E  regB with positive slack.
Default Reports
The TimeQuest timing 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 timing analyzer, you generate desired reports on
demand.
Netlist Names
The Classic timing analyzer uses register names in reporting, but the TimeQuest
timing analyzer uses register pin names (with the exception of port names of the toplevel module). Buried nodes or register names are used when necessary.
Example 9–5 shows how register names are used in Classic timing analyzer reports.
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
9–22
Chapter 9: Switching to the Quartus II TimeQuest Timing Analyzer
Differences Between the Timing Analyzers
Example 9–5. Netlist Names in the Quartus II 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 9–6 shows the same information as presented in a TimeQuest timing
analyzer report. In this example, register pin names are used in place of register
names.
Example 9–6. Netlist Names in the Quartus II TimeQuest Timing 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 timing 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 exceptions 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.
When the clock period cannot be expressed as an integer in terms of picoseconds, you
have the situation shown in Figure 9–22. This figure shows two clocks: clk_a has a
10 ns period, and clk_b has a 6.667 ns period.
Figure 9–22. 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 9–7 between the two clocks to specify the correct
relationships.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 9: Switching to the Quartus II TimeQuest Timing Analyzer
Differences Between the Timing Analyzers
9–23
Example 9–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
Other Features
The TimeQuest timing 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 timing analyzer in a Tcl shell, output is ASCIIformatted, and columns are aligned for easy reading on 80-column consoles.
Example 9–8 shows sample output from a report_timing command from the
TimeQuest timing analyzer.
Example 9–8. ASCII-Formatted Quartus II TimeQuest Timing 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
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
9–24
Chapter 9: Switching to the Quartus II TimeQuest Timing Analyzer
Timing Assignment Conversion
Timing Assignment Conversion
This section describes Quartus II Classic QSF timing assignments and their equivalent
Quartus II TimeQuest 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 9–28
■
“Clock Latency” on page 9–25
■
“Clock Uncertainty” on page 9–25
■
“Cut Timing Path” on page 9–38
■
“Default Required fMAX Assignment” on page 9–26
■
“Hold Relationship” on page 9–25
■
“Input and Output Delay” on page 9–29
■
“Inverted Clock” on page 9–25
■
“Maximum Clock Arrival Skew” on page 9–39
■
“Maximum Data Arrival Skew” on page 9–39
■
“Maximum Delay” on page 9–38
■
“Minimum Delay” on page 9–39
■
“Minimum tCO Requirement” on page 9–35
■
“Minimum tPD Requirement” on page 9–38
■
“Multicycle” on page 9–27
■
“Not a Clock” on page 9–26
■
“Setup Relationship” on page 9–24
■
“tCO Requirement” on page 9–33
■
“tH Requirement” on page 9–31
■
“tPD Requirement” on page 9–37
■
“tSU Requirement” on page 9–29
■
“Virtual Clock Reference” on page 9–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 timing
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 timing analyzer accounts for clock latency, source tCO, or destination tSU.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 9: Switching to the Quartus II TimeQuest Timing Analyzer
Timing Assignment Conversion
9–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 timing analyzer, use the
set_min_delay command to specify the minimum hold relationship for a path.
Clock Latency
Table 9–1 shows the equivalent SDC constraints for the clock latency Classic timing
analyzer assignments.
Table 9–1. Quartus II Classic and SDC Equivalent Constraints for Clock Latency Assignments
Quartus II Classic Timing Assignment
Assignment Name
QSF Variable
SDC Constraint
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 timing analyzer,
refer to “Clock Latency” on page 9–11.
Clock Uncertainty
This section describes the conversion for the following Classic timing analyzer
assignments:
■
Clock Setup Uncertainty
■
Clock Hold Uncertainty
Table 9–2 shows the equivalent SDC constraints for each of these Classic timing
analyzer assignments.
Table 9–2. Quartus II Classic and SDC Equivalent Constraints for Clock Uncertainty Assignments
Quartus II Classic Timing Analyzer Timing Assignment
Assignment Name
QSF Variable
SDC Constraint
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 timing 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.
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
9–26
Chapter 9: 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 timing analyzer
and there is no equivalent constraint. Appropriate clock constraints are created in the
TimeQuest timing 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 9–15 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 timing
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 timing analyzer, use the create_clock
or create_generated_clock commands with the -name option and no targets.
Figure 9–23 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 9–23. Virtual Clock Circuit
Altera FPGA
Other Device
d_in
reg_a
reg_b
d_out
clk_a
clk_a
clk_b
clk_b
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)
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 9: Switching to the Quartus II TimeQuest Timing Analyzer
Timing Assignment Conversion
9–27
■
Virtual Clock Reference setting for virt_clk is on (indicates that virt_clk is a
virtual clock)
■
Output Maximum Delay of 5 ns on dataout with respect to virt_clk
(constrains the path between the two devices)
The SDC commands shown in Example 9–9 constrain the circuit the same way.
Example 9–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 timing
analyzer, use the create_clock and create_generated_clock commands to constrain
clocks.
Multicycle
Table 9–3 shows the equivalent SDC exceptions for each of these Classic timing
analyzer timing assignments.
Table 9–3. Quartus II Classic and SDC Equivalent Exceptions
Quartus II Classic Timing Assignment
Assignment Name
QSF Variable
SDC Exception
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 9–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.
The default value and numbering scheme for the hold multicycle value is different in
the Quartus II Classic and TimeQuest timing analyzers. Refer to “Hold Multicycle” on
page 9–18 for more information about the difference between the default value and
numbering scheme for the hold multicycle value in the Quartus II Classic and
TimeQuest timing analyzers.
f
© July 2010
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.
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
9–28
Chapter 9: Switching to the Quartus II TimeQuest Timing Analyzer
Timing Assignment Conversion
Clock Enable Multicycle
The Classic timing analyzer supports the following clock enable multicycle
assignments. Corresponding types of multicycle assignments are applied to all
registers enabled by the targets of the specified clock.
■
Clock Enable Multicycle
■
Clock Enable Source Multicycle
■
Clock Enable Multicycle Hold
■
Clock Enable Source Multicycle Hold
The TimeQuest timing 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 industrystandard, system-centric timing constraints. Where possible, you should use
system-centric constraints to constrain your designs for the TimeQuest timing
analyzer. Table 9–4 includes Quartus II Classic I/O assignments, the equivalent
FPGA-centric SDC constraints, and recommended system-centric SDC constraints.
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 Quartus II Classic 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 9–4. Quartus II Classic and Quartus II TimeQuest Timing Analyzers Equivalent I/O Constraints
Classic
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  <tH requirement> (1)
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)
Notes to Table 9–4:
(1) Refer to “tH Requirement” on page 9–31 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
Quartus II TimeQuest Timing Analyzer.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 9: Switching to the Quartus II TimeQuest Timing Analyzer
Timing Assignment Conversion
9–29
Input and Output Delay
Table 9–5 shows the equivalent SDC exceptions for each of these Classic timing
analyzer timing assignments.
Table 9–5. Quartus II Classic and SDC Equivalent Exceptions
Quartus II Classic Timing Assignment
Assignment Name
QSF Variable
SDC Exception
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>)
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 file 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 9–24 to understand the names in Equation 9–3 and
Equation 9–4.
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
9–30
Chapter 9: Switching to the Quartus II TimeQuest Timing Analyzer
Timing Assignment Conversion
Figure 9–24. Path Names
src.out
srctodst
dst.in
dst.utsu
src.utco
src.clk
dst.clk
board.srcclk
board.dstclk
clk
Equation 9–3 shows the derivation of this conversion.
Equation 9–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 t su = 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 9–25.
Figure 9–25. 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 9–4 shows the derivation of this conversion.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 9: Switching to the Quartus II TimeQuest Timing Analyzer
Timing Assignment Conversion
9–31
Equation 9–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 t su = dst.in + dst.utsu – dst.clk
t su requirement –  dst.in + dst.utsu – dst.clk   0
set_max_delay = t su requirement
Table 9–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 9–6. tSU Requirement and set_max_delay Equivalence
tSU Requirement
Options
-to <pin>
set_max_delay Options
-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)
Notes to Table 9–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 9–10.
Example 9–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 9–26 to understand the names in Equation 9–5 and
Equation 9–6.
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
9–32
Chapter 9: Switching to the Quartus II TimeQuest Timing Analyzer
Timing Assignment Conversion
Figure 9–26. Path Names
src.out
srctodst
dst.in
dst.uth
src.utco
src.clk
board.srcclk
dst.clk
board.dstclk
clk
Equation 9–5 shows the derivation of this calculation.
Equation 9–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 t H = 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 + tH requirement
The delay value for the set_min_delay command is the tH Requirement value.
Equation 9–6 shows the derivation of this conversion.
Equation 9–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 t H = dst.clk + dst.uth – dst.in
t H requirement –  dst.clk + dst.uth – dst.in   0
set_min_delay = – t H requirement
Table 9–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.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 9: Switching to the Quartus II TimeQuest Timing Analyzer
Timing Assignment Conversion
9–33
Table 9–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 9–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 9–29 for additional
information.
To convert a global tH assignment to an equivalent SDC exception, use the command
shown in Example 9–11.
Example 9–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 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 9–27 to understand the names in Equation 9–7 and
Equation 9–8.
Figure 9–27. Path Names
src.out
srctodst
dst.in
dst.utsu
src.utco
src.clk
dst.clk
board.srcclk
board.dstclk
clk
Equation 9–7 shows the derivation of this conversion.
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
9–34
Chapter 9: Switching to the Quartus II TimeQuest Timing Analyzer
Timing Assignment Conversion
Equation 9–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 t co = 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 9–28.
Figure 9–28. 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 9–8 shows the derivation of this conversion.
Equation 9–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 t co = src.clk + src.utco + src.out
t co requirement –  src.clk + src.utco + src.out   0
set_max_delay = t co requirement
Table 9–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 9–8. tCO Requirement and set_max_delay Equivalence (Part 1 of 2)
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 *]
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 9: Switching to the Quartus II TimeQuest Timing Analyzer
Timing Assignment Conversion
9–35
Table 9–8. tCO Requirement and set_max_delay Equivalence (Part 2 of 2)
tCO Requirement Options
set_max_delay Options
-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 9–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 9–12.
Example 9–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 9–29 to understand the names in Equation 9–9 and
Equation 9–10.
Figure 9–29. Path Names
src.out
srctodst
dst.in
dst.uth
src.utco
src.clk
dst.clk
board.srcclk
board.dstclk
clk
Equation 9–9 shows the derivation of this conversion.
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
9–36
Chapter 9: Switching to the Quartus II TimeQuest Timing Analyzer
Timing Assignment Conversion
Equation 9–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 tco – minimum t co requirement  0
minimum tco = launch + src.clk + src.utco + src.out
 launch + src.clk + src.utco + src.out  – minimum t co requirement  0
minimum tco 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 9–10 shows the derivation of this conversion.
Equation 9–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 tco – minimum t co requirement  0
minimum tco = src.clk + src.utco + src.out
 src.clk + src.utco + src.out  – minimum t co requirement  0
set_min_delay = minimum tco requirement
Table 9–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 9–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 9–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 9–13.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 9: Switching to the Quartus II TimeQuest Timing Analyzer
Timing Assignment Conversion
9–37
Example 9–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
non-registered 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 timing 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 9–30 shows a circuit to illustrate the following example of converting a tPD
Requirement to a set_max_delay constraint.
Figure 9–30. tPD Example
comb_out
reg_out
a_in
b_in
clk
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 9–14 in the TimeQuest
timing analyzer.
Example 9–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:
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
9–38
Chapter 9: Switching to the Quartus II TimeQuest Timing Analyzer
Timing Assignment Conversion
<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 9–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 9–15. Converting a Global tPD Requirement Assignment to an Equivalent SDC Exception
set_max_delay -from [all_inputs] -to [all_outputs] <value>
Minimum tPD Requirement
The Minimum tPD Requirement assignment specifies the minimum acceptable input
to non-registered 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 timing 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 9–37 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 9–16.
Example 9–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 timing 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 timing analyzer.
1
The Maximum Delay assignment for the Classic timing analyzer is not related to the
set_max_delay exception in the TimeQuest timing analyzer.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 9: Switching to the Quartus II TimeQuest Timing Analyzer
Timing Assignment Conversion
9–39
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 timing analyzer.
1
The Minimum Delay assignment for the Classic timing analyzer is not related to the
set_min_delay exception in the TimeQuest timing 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 timing 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 timing 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 9–31 shows a simplified source-synchronous
interface used in the following example.
Figure 9–31. 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 and 3 ns after the clk_out signal. Assume that clk_in and clk_out
have a period of 8 ns.
The following equations and example show how to create timing requirements that
satisfy the timing relationships shown in Figure 9–32.
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
9–40
Chapter 9: Switching to the Quartus II TimeQuest Timing Analyzer
Timing Assignment Conversion
Figure 9–32. Source-Synchronous Timing Diagram
clk_out
data_out
0
2
3
4
8
10
11
12
Equation 9–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 9–11.
latch – launch = 0ns
output delay = latch – launch – 2ns
output delay = – 2ns
Equation 9–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 9–12.
latch – launch = 8ns
output delay = latch – launch – 3ns
output delay = 5ns
Refer to “I/O Constraints” on page 9–28 for an explanation of the above equations.
Example 9–17 shows the three constraints together.
Example 9–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 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 9: Switching to the Quartus II TimeQuest Timing Analyzer
Conversion Utility
9–41
Conversion Utility
The TimeQuest timing analyzer includes a conversion utility to help you convert
Quartus II Classic timing assignments in a .qsf file to SDC constraints in an .sdc file.
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 file.
Refer to “Conversion Utility” on page 9–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 9–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 9–10. Global Timing Assignments
Assignment Name
QSF Variable
More Information
tSU Requirement
TSU_REQUIREMENT
tH Requirement
TH_REQUIREMENT
page 9–31
tCO Requirement
TCO_REQUIREMENT
page 9–33
Minimum tCO Requirement
MIN_TCO_REQUIREMENT
page 9–35
tPD Requirement
TPD_REQUIREMENT
page 9–37
Minimum tPD Requirement
MIN_TPD_REQUIREMENT
page 9–38
page 9–29
Recommended Global Assignments
When any unsupported assignments have been identified, the conversion utility
checks the global assignments in Table 9–11 to ensure they match the specified values.
Table 9–11. Recommended Global Assignments
Quartus II Classic 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
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 timing analyzer.
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
9–42
Chapter 9: Switching to the Quartus II TimeQuest Timing Analyzer
Conversion Utility
■
Cut off clear and preset signal paths— The TimeQuest timing 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 timing analyzer does not match
the functionality of the Classic timing analyzer when this assignment is OFF.
■
Cut off read during write signal paths—The TimeQuest timing analyzer does not
match the functionality of the Classic timing analyzer when this assignment is
OFF.
■
Analyze latches as synchronous elements—The TimeQuest timing analyzer
analyzes latches as synchronous elements by default and does not match the
functionality of the Classic timing analyzer when this assignment is OFF. The
Classic timing analyzer analyzes latches as synchronous elements by default.
■
Enable Clock Latency—The TimeQuest timing analyzer includes clock latency in
its calculations. The TimeQuest timing analyzer does not match the functionality
of the Classic timing analyzer when this assignment is 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 9–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 timing analyzer because they do not include the entity name when this
option is ON.
If your design meets timing requirements in the Classic timing analyzer without all of
the settings recommended in Table 9–11 on page 9–41, you should perform one of the
following actions:
■
Change the settings and re-constrain and reverify as necessary.
or
■
Add or modify SDC constraints as appropriate because analysis in the TimeQuest
timing analyzer may be different after conversion.
Clock Conversion
Next, the conversion utility adds the derive_pll_clocks command to the .sdc file. This
command creates generated clocks on all PLL outputs in your design each time the
.sdc file 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 file 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.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 9: Switching to the Quartus II TimeQuest Timing Analyzer
Conversion Utility
9–43
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 9–15 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
timing analyzer displays the reminder the first time it reads the .sdc file. 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 file. 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 9–11 for information about how to use offset values in the TimeQuest
timing analyzer.
Instance Assignment Conversion
Next, the conversion utility converts the instance assignments shown in Table 9–12.
Refer to the indicated page for information about each assignment.
Table 9–12. Instance Timing Assignments (Part 1 of 2)
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
© July 2010
Altera Corporation
More Information
page 9–25
page 9–25
page 9–27
page 9–28
Quartus II Handbook Version 10.0 Volume 3: Verification
9–44
Chapter 9: Switching to the Quartus II TimeQuest Timing Analyzer
Conversion Utility
Table 9–12. Instance Timing Assignments (Part 2 of 2)
Assignment Name
QSF Variable
More Information
Cut Timing Path
CUT
page 9–38
Input Maximum Delay
INPUT_MAX_DELAY
page 9–29
Input Minimum Delay
INPUT_MIN_DELAY
Output Maximum Delay
OUTPUT_MAX_DELAY
Output Minimum Delay
OUTPUT_MIN_DELAY
Notes to Table 9–1 2:
(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 file 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 9–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 9–18 for more information on hold
multicycle differences between the Quartus II Classic and TimeQuest timing
analyzers.
Next, the conversion utility converts the instance assignments shown in Table 9–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 9–13. Instance Timing Assignments
Assignment Name
QSF Variable
More Information
tPD Requirement (1)
TPD_REQUIREMENT
page 9–37
Minimum tPD Requirement (1)
MIN_TPD_REQUIREMENT
page 9–38
Setup Relationship
SETUP_RELATIONSHIP
page 9–24
Hold Relationship
HOLD_RELATIONSHIP
page 9–25
Note to Table 9–1 3:
(1) Refer to “tPD and Minimum tPD Requirement Conversion” on page 9–52 for more information about how the
conversion utility converts single-point tPD and minimum tPD assignments.
The conversion utility converts Quartus II Classic I/O timing assignments to
FPGA-centric SDC constraints. Table 9–14 includes Quartus II Classic assignments,
the equivalent FPGA-centric SDC constraints, and recommended system-centric SDC
constraints.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 9: Switching to the Quartus II TimeQuest Timing Analyzer
Conversion Utility
9–45
Table 9–14. Quartus II Classic and Quartus II TimeQuest Equivalent Constraints
Quartus II Classic
FPGA-Centric SDC
System-Centric SDC
More Information
tSU Requirement (1)
set_max_delay
set_input_delay -max
page 9–29
tH Requirement (1)
set_min_delay
set_input_delay -min
page 9–31
tCO Requirement (2)
set_max_delay
set_output_delay -max
page 9–33
Minimum tCO Requirement
(2)
set_min_delay
set_output_delay -min
page 9–35
Notes to Table 9–1 4:
(1) Refer to “tPD and Minimum tPD Requirement Conversion” on page 9–52 for more information about how the
conversion utility converts this type of assignment.
(2) Refer to “tCO Requirement Conversion” on page 9–46 for more information about how the conversion utility
converts this type of assignment.
The conversion utility can convert Quartus II Classic 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 Quartus II Classic 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.
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 9–13:
Equation 9–13.
<pll output period>  <phase shift> <correct value> = <converted value> – --------------------------------------------------------------------------------------360
Example 9–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 file contains the following assignment:
Example 9–18. Assignment
set_instance_assignment -name TCO_REQUIREMENT -to data[0] 1.0
The conversion utility generates the SDC command shown in Example 9–19.
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
9–46
Chapter 9: Switching to the Quartus II TimeQuest Timing Analyzer
Conversion Utility
Example 9–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 - = – 0.25
1.0 – ------------------360
Then, change the value so the SDC command so that it looks like Example 9–20.
Example 9–20. SDC Command with Correct Values
set_max_delay -from [get_registers *] -to [get_ports data[0]] -0.25
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 9–21 shows how the conversion utility converts a
tCO Requirement assignment of 5.0 ns to data[0].
Example 9–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 9–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 9–15. Entity-Specific Timing Assignments
Quartus II Classic
1
QSF Variable
More Information
Multicycle
MULTICYCLE
page 9–27
Source Multicycle
SRC_MULTICYCLE
Multicycle Hold
HOLD_MULTICYCLE
Source Multicycle Hold
SRC_HOLD_MULTICYCLE
Setup Relationship
SETUP_RELATIONSHIP
page 9–24
Hold Relationship
HOLD_RELATIONSHIP
page 9–25
Cut Timing Path
CUT
page 9–38
You must manually convert all other entity-specific timing assignments.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 9: Switching to the Quartus II TimeQuest Timing Analyzer
Conversion Utility
9–47
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.
Unsupported Instance Assignments
Finally, the conversion utility checks for the unsupported instance assignments listed
in Table 9–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 9–16. Instance Timing Assignments
Assignment Name
QSF Variable
More
Information
Inverted Clock
INVERTED_CLOCK
page 9–25
Maximum Clock Arrival Skew
MAX_CLOCK_ARRIVAL_SKEW
page 9–39
Maximum Data Arrival Skew
MAX_DATA_ARRIVAL_SKEW
page 9–39
Maximum Delay
MAX_DELAY
page 9–38
Minimum Delay
MIN_DELAY
page 9–39
Virtual Clock Reference
VIRTUAL_CLOCK_REFERENCE
page 9–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 timing 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 file with the same name as your current revision,
<revision>.sdc, and it overwrites any existing <revision>.sdc file. If you use the
conversion utility to create an .sdc file, you should make additions or corrections in a
separate .sdc file, or a copy of the .sdc file created by the conversion utility. That way,
you can re-run 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 9–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.
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
9–48
Chapter 9: Switching to the Quartus II TimeQuest Timing Analyzer
Conversion Utility
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 9–24 for information about conversions for
all QSF timing assignments.
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 9–41 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 timing 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
timing analyzer analysis may be different from the Classic timing analyzer analysis.
Refer to “Recommended Global Assignments” on page 9–41 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 9–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 9–15 on page 9–46 lists the
entity-specific assignments the script can convert automatically.
Refer to “Timing Assignment Conversion” on page 9–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 file if
appropriate. Refer to “Clock Offset” on page 9–11 for more information about
converting clock offset.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 9: Switching to the Quartus II TimeQuest Timing Analyzer
Conversion Utility
9–49
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 file.
No Clock Settings defined in QSF file
If your .qsf file has no clock settings, ignore this message. You must add clock
constraints in your .sdc file manually.
Clocks
Ensure that the conversion utility converted all clock assignments correctly. Run
report_clocks, or double-click Report Clocks in the Tasks pane in the TimeQuest
timing 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 timing 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 report_clock_transfers,
or double-click Report Clock Transfers in the Tasks pane in the TimeQuest timing
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 timing analyzer. You
must cut unrelated clock domains. Refer to “Related and Unrelated Clocks” on
page 9–10 for information about how to cut unrelated clock domains.
Path Details
If you have unexpected differences between the Quartus II Classic and TimeQuest
timing analyzers on some paths, follow these steps to identify the cause of the
difference.
1. List the path in the Classic timing analyzer.
2. Report timing on the path in the TimeQuest timing analyzer.
3. Compare slack values.
4. Compare source and destination clocks.
5. Compare the launch/latch times in the TimeQuest timing analyzer to the
setup/hold relationship in the Classic timing analyzer. The times are absolute in
the TimeQuest timing analyzer and relative in the Classic timing analyzer.
6. Compare clock latency values.
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
9–50
Chapter 9: Switching to the Quartus II TimeQuest Timing Analyzer
Notes
Unconstrained Paths
Next, run report_ucp, or double-click Report Unconstrained Paths in the Tasks
pane in the TimeQuest timing 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 timing analyzer, some assignments may not have been
converted properly. Also, some of the assignments could be ambiguous. The
TimeQuest timing 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.
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 9–7 for more information.
Other
Review the notes listed in “Conversion Utility” on page 9–52.
Re-Running the Conversion Utility
You can force the conversion utility to run even if it can find an .sdc file according to
the priority described in “Constraint File Priority” on page 9–7. Any method
described in “Conversion Utility” on page 9–2 forces the conversion utility to run
even if it can find an .sdc file.
Notes
This section describes notes for the TimeQuest timing analyzer.
Output Pin Load Assignments
The TimeQuest timing 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 timing 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 Quartus II Settings File (.qsf).
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 9: Switching to the Quartus II TimeQuest Timing Analyzer
Notes
9–51
Constraint Target Types
The TimeQuest timing analyzer supports mixed exception types; you can apply an
exception of any clock/node combination.
DDR Constraints with the DDR Timing Wizard
The DDR Timing Wizard (DTW) creates an .sdc file that contains constraints for a
DDR interface. You can use that .sdc file with the TimeQuest timing analyzer to
analyze only the DDR interface part of a design.
You should use the .sdc file created by DTW for constraining a DDR interface in the
TimeQuest timing analyzer. Additionally, your .qsf file should not contain timing
assignments for the DDR interface if you plan to use the conversion utility to create an
.sdc file. You should run the conversion utility before you use DTW, and you should
choose not to apply assignments to the .qsf file.
However, if you used DTW and chose to apply assignments to a .qsf file, before you
used the conversion utility, you should remove the DTW-generated QSF timing
assignments and re-run the conversion utility. The conversion utility creates some
incompatible SDC constraints from the DTW QSF assignments.
Unsupported SDC Features
Some SDC commands and features are not supported by the current version of the
TimeQuest timing analyzer. The following commands are included:
■
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 file. If you
change timing constraints in synthesis software after creating an .sdc file for the
TimeQuest timing analyzer, you must update the SDC constraints. You can use the
conversion utility, or update the .sdc file manually.
If you use physical synthesis with the TimeQuest timing analyzer, the design may
have lower performance.
Clock Network Delay Reporting
In the Quartus II software version 6.0, the TimeQuest timing analyzer reports delay
on the clock network as a single number, rather than node-to-node segments, as the
Classic timing analyzer does. Beginning with version 6.0 SP1, the TimeQuest Timing
Analyzer reports delay on the clock network by node-to-node segments.
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
9–52
Chapter 9: Switching to the Quartus II TimeQuest Timing Analyzer
Document Revision History
Project Management
If you use the project_open Tcl command in the TimeQuest timing analyzer to open a
project compiled with an earlier version of the Quartus II software, the TimeQuest
timing 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
timing analyzer, refer to the Quartus II TimeQuest Timing Analyzer chapter in volume 3
of the Quartus II Handbook.
Document Revision History
Table 9–17. Document Revision History
Date
Version
Changes Made
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.
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 10.0 Volume 3: Verification
© July 2010 Altera Corporation
10. Quartus II Classic Timing Analyzer
QII53004-10.0.0
This chapter details the aspects of timing analysis using the Quartus® II Classic
Timing Analyzer.
Static timing analysis is a method for analyzing, debugging, and validating the timing
performance of a design. Static timing analysis, used in conjunction with functional
simulation, allows you to verify overall design operation. As part of the compilation
flow, the Classic Timing Analyzer automatically performs a static timing analysis so
you do not have to use a third-party timing analysis tool. The Quartus II software also
includes the TimeQuest Timing Analyzer, which provides advanced constraints and
analysis capabilities that cater to all designs. Like the Classic Timing Analyzer, the
TimeQuest Timing Analyzer can also be an automatic part of your compilation flow,
and should be used for all new designs.
f
For more information about switching to the TimeQuest Timing Analyzer, refer to the
Switching to the Quartus II TimeQuest Timing Analyzer chapter in volume 3 of the
Quartus II Handbook.
This chapter assumes you have some Tcl expertise; Tcl commands are used
throughout this chapter to describe the alternative methods for making timing
analysis assignments. For more information about GUI-equivalent timing constraints,
refer to “Timing Analysis Using the Quartus II GUI” on page 10–35.
1
New device families are not supported in the Classic Timing Analyzer. Altera
recommends using the TimeQuest Timing Analyzer for all new designs.
This chapter discusses the following topics:
© July 2010
■
“Timing Analysis Tool Setup” on page 10–2
■
“Static Timing Analysis Overview” on page 10–2
■
“Clock Settings” on page 10–8
■
“Clock Types” on page 10–9
■
“Clock Uncertainty” on page 10–10
■
“Clock Latency” on page 10–11
■
“Timing Exceptions” on page 10–13
■
“I/O Analysis” on page 10–22
■
“Asynchronous Paths” on page 10–25
■
“Skew Management” on page 10–29
■
“Generating Timing Analysis Reports with report_timing” on page 10–30
■
“Other Timing Analyzer Features” on page 10–31
■
“Timing Analysis Using the Quartus II GUI” on page 10–35
■
“Scripting Support” on page 10–39
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
10–2
Chapter 10: Quartus II Classic Timing Analyzer
Timing Analysis Tool Setup
■
“MAX+PLUS II Timing Analysis Methodology” on page 10–43
Timing Analysis Tool Setup
The Quartus II software includes two static timing analysis tools:
■
Classic Timing Analyzer
■
TimeQuest Timing Analyzer
Use the Timing Analysis option under the Settings menu to set the timing analyzer
that is used in the compilation process.
1
Altera recommends using the TimeQuest Timing Analyzer for new designs. The
TimeQuest Timing Analyzer provides advanced constraints and analysis capabilities
that cater to all designs.
To use the Classic Timing Analyzer, follow these steps:
1. On the Assignments menu, click Settings. The Settings dialog box appears.
2. In the Category list, expand Timing Analysis Settings and select Use Classic
Timing Analyzer during compilation.
f
For more information about the advanced features available in the TimeQuest Timing
Analyzer, refer to the Quartus II TimeQuest Timing Analyzer chapter in volume 3 of the
Quartus II Handbook.
Static Timing Analysis Overview
This section provides information about the static timing analysis concepts. A
complete understanding of the concepts presented in this section allows you to take
advantage of the static timing analysis features available in the Quartus II software.
Various paths exist in any given design which connect design elements together,
including the path from an output of a register to the input of another register. Timing
paths play a significant role during a static timing analysis. Understanding the types
of timing paths is important for timing closure and optimization. Some of the
commonly analyzed paths are described in this section and are shown in Figure 10–1.
■
Clock paths—Clock paths are the paths from device pins or internally generated
clocks (nodes designated as a clock via a clock setting) to the clock ports of
sequential elements such as registers.
■
Data paths—Data paths are the paths from the data output port of a sequential
element to the data input port of another sequential element.
■
Asynchronous paths—Asynchronous paths are paths from a node to the
asynchronous set or clear port of a sequential element.
Figure 10–1 shows the commonly analyzed paths types.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 10: Quartus II Classic Timing Analyzer
Static Timing Analysis Overview
10–3
Figure 10–1. Path Types
D
Q
D
Clock Path
Q
Data Path
clk
CLRN
CLRN
Async Path
rst
After the path types are identified, the Classic Timing Analyzer computes data and
clock arrival times for all valid register-to-register paths. Data arrival time is the delay
from the source clock to the destination register. The Classic Timing Analyzer
calculates this delay by adding the clock path delay to the source register, the micro
clock-to-out (tCO) of the source register, and the data path delay from the source
register to the destination register. Clock arrival time is the delay from the destination
clock node to the destination register.
Figure 10–2 shows a data arrival path and a clock arrival path.
Figure 10–2. Data Arrival and Clock Arrival
D
Q
D
Q
Data Arrival
Clock Arrival
In addition to identifying various paths within a design, the Classic Timing Analyzer
analyzes clock characteristics to compute the worst-case requirement between any
two registers in a single register-to-register path. You must use timing constraints to
specify the characteristics of all clock signals in the design before this analysis occurs.
The active clock edge that sends data out of a sequential element, acting as a source
for the data transfer, is the launch edge. The active clock edge that captures data at the
data port of a sequential element, acting as a destination for the data transfer, is the
latch edge.
Figure 10–3 shows a single-cycle system that uses consecutive clock edges to transmit
and capture data, a register-to-register path, and the corresponding launch and latch
edges timing diagram. In this example, the launch edge sends the data out of register
reg1 at 0 ns, and register reg2 latch edge captures the data at 5 ns.
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
10–4
Chapter 10: Quartus II Classic Timing Analyzer
Static Timing Analysis Overview
Figure 10–3. Launch Edge and Latch Edge
D
Q
D
reg1
Q
reg2
clk
Launch Edge at Source Register reg1
Latch Edge at Destination Register reg2
clk
0 ns
5 ns
10 ns
15 ns
By analyzing specific paths relative to the launch and latch edges, the Classic Timing
Analyzer performs clock setup and clock hold checks, validating them against your
timing assignments.
Clock Analysis
A comprehensive static timing analysis includes analysis of register-to-register, I/O,
and asynchronous reset paths. Static Timing Analysis tools use data required times,
data arrival times, and clock arrival times to verify circuit performance and detect
possible timing violations. The Classic Timing 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.
Clock Setup Check
To determine if a design meets performance, the Classic Timing Analyzer calculates
clock timing, timing requirements, and timing exceptions to perform a clock setup
check at each destination register based on the source and destination clocks and
timing constraints, or exceptions that are applicable to those paths. A clock setup
check ensures that data launched by a source register is latched correctly by the
destination register. To perform a clock setup check, the Classic Timing Analyzer
determines the clock arrival time and data arrival time at the destination register by
using the longest path for the data arrival time and the shortest path for the clock
arrival time. The Classic Timing Analyzer then checks that the difference is greater
than or equal to the micro setup (tSU) of the destination register as shown in
Equation 10–1.
Equation 10–1.
Clock Arrival Time – Data Arrival Time  micro t SU
1
By default, the Classic Timing Analyzer assumes the launched and latched edges
happen on consecutive active clock edges.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 10: Quartus II Classic Timing Analyzer
Static Timing Analysis Overview
10–5
The results of clock setup checks are reported in terms of slack. 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, and negative slack indicates the margin by which a
requirement is not met. The Classic Timing Analyzer determines clock setup slack
using Equation 10–2 through Equation 10–5.
Equation 10–2.
Clock Setup Slack = Data Required Time – Data Arrival Time
Equation 10–3.
Data Required = Clock Arrival Time – micro t SU – Setup Uncertainty
Equation 10–4.
Clock Arrival Time = Latch Edge + Shortest Clock Path to Destination Register
Equation 10–5.
Data Arrival Time = Launch Edge + Longest Clock Path to Source Register
+ micro t CO + Longest Data Delay
The Classic Timing Analyzer reports clock setup slack using Equation 10–6
through Equation 10–9 (which are equivalent to Equation 10–2 through
Equation 10–5).
Equation 10–6.
Clock Setup Slack = Largest Register-to-Register Requirement – Longest Register-to-Register Delay
Equation 10–7.
Largest Register-to-Register Requirement = Setup Relationship between Source and Destination
+ largest clock skew – micro t CO of Source Register – micro t SU of Destination Register
Equation 10–8.
Setup Relationship between Source & Destination Register =
Latch Edge – Launch Edge Setup Uncertainty
Equation 10–9.
Largest Clock Skew = Shortest Clock Path to Destination Register
– Longest Clock Path to Source Register
Both sets of equations are used to determine the slack value of any path.
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
10–6
Chapter 10: Quartus II Classic Timing Analyzer
Static Timing Analysis Overview
Clock Hold Check
To prevent hold violations, the Classic Timing Analyzer calculates clock timing,
timing requirements, and timing exceptions to perform a clock hold check at each
destination register. A clock hold check ensures data launched from the source
register is not captured by an active clock edge earlier than the setup latch edge, and
that the destination register does not capture data launched from the next active
launch edge. To perform a clock hold check, the Classic Timing Analyzer determines
the clock arrival time and data arrival time at the destination register using the
shortest path for the data arrival time and the longest path for the clock arrival time.
The Classic Timing Analyzer checks that the difference is greater than or equal to the
micro hold time (tH) of the destination register, as shown in Equation 10–10.
Equation 10–10.
Data Arrival Time – Clock Arrival Time  tH
The Classic Timing Analyzer determines clock hold slack using Equation 10–11
through Equation 10–14.
Equation 10–11.
Clock Hold Slack = Data Arrival Time – Data Required Time
Equation 10–12.
Data Required Time = Clock Arrival Time + micro t H + Hold Uncertainty
Equation 10–13.
Clock Arrival Time = Latch Edge + Longest Clock Path to Destination Register
Equation 10–14.
Data Arrival Time = Launch Edge + Shortest Clock Path to Source Register
+ micro t CO + Shortest Data Delay
The Classic Timing Analyzer reports clock hold slack using Equation 10–15
through Equation 10–18.
Equation 10–15.
Clock Hold Slack = Shortest Register-to-Register Delay
– Smallest Register-to-Register Requirement
Equation 10–16.
Smallest Register-to-Register Requirement = Hold Relationship between Source & Destination +
Smallest Clock Skew – micro t co of Source Register + micro t H of Destination Register
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 10: Quartus II Classic Timing Analyzer
Static Timing Analysis Overview
10–7
Equation 10–17.
Hold Relationship between Source and Destination Register = Latch – Launch + Hold Uncertainty
Equation 10–18.
Smallest Clock Skew = Longest Clock Path from Clock to Destination Register
– Shortest Clock Path from Clock to Source Register
These equations can be used to determine the slack value of any path.
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 10–4 shows an example of a multicycle path between a multiplier’s input
registers and output register where the destination latches data on every other clock
edge. For more information about multicycle exceptions, refer to “Multicycle” on
page 10–14.
Figure 10–4. Example Diagram of a Multicycle Path
D
D
Q
Q
ENA
D
D
Q
ENA
Q
ENA
2 cycles
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
10–8
Chapter 10: Quartus II Classic Timing Analyzer
Clock Settings
Figure 10–5 shows the default clock setup analysis launch and latch edges where
multicycle assignment is equal to 1.
Figure 10–5. Default Clock Setup Analysis
src_clk
dst_clk
Figure 10–6 shows an analysis similar to Figure 10–5, but with a multicycle of 2.
Figure 10–6. Multicycle = 2 Clock Setup Analysis
src_clk
dst_clk
Clock Settings
You can use individual and default clock settings to define the clocks in your design.
You can base these clock settings on other clock settings already defined in your
design.
1
To ensure that the Quartus II Fitter achieves the desired performance requirements
and the Classic Timing Analyzer performs a thorough static timing analysis, you must
specify all timing assignments prior to compiling the design.
Individual Clock Settings
Individual clock settings allow you to specify clock properties including performance
requirements, offsets, duty cycles, and other properties for individual clock signals in
your design.
You can define individual clock settings using the create_base_clock Tcl
command. The following example defines an individual clock setting named
sys_clk with a requirement of 100 MHz (10 ns), and assigns it to clock node clk.
create_base_clock -fmax 100MHz -target clk sys_clk
Default Clock Settings
You can assign a project-wide clock requirement to constrain all detected clocks in a
design that do not have individual clock settings.
The set_global_assignment -name FMAX_REQUIREMENT Tcl command
specifies a global default requirement assignment. The following example defines a
100 MHz default clock requirement:
set_global_assignment -name FMAX_REQUIREMENT "100.0 MHz"
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 10: Quartus II Classic Timing Analyzer
Clock Types
1
10–9
For best placement and routing results, apply individual clock settings to all clocks in
your design. All clocks adopting the default fMAX are by default unrelated.
Clock Types
This section describes the types of clocks recognized by the timing analyzer:
■
Base clocks
■
Derived clocks
■
Undefined clocks
■
PLL clocks
Base Clocks
A base clock is independent of other clocks in a design. For example, a base clock is
typically a clock signal driven directly by a device pin. A base clock is defined by
individual clock settings, or automatically detected using the default clock setting.
You can use the create_base_clock Tcl command to define a base clock setting
and assign the clock setting to a clock node. The following Tcl command creates a
clock setting called sys_clk with a requirement of 5 ns (200 MHz) and applies the
clock setting to clock node main_clk:
create_base_clock -fmax 5ns –target main_clk sys_clk
Derived Clocks
A derived clock is based on a previously defined base clock. For a derived clock, you
can specify the phase shift, offset, multiplication and division factors, and duty cycle
relative to the base clock.
You can use the create_relative_clock Tcl command to define and assign a
derived clock setting. The following example creates a derived clock setting named
system_clockx2 that is twice as fast as the base clock system_clock applied to
clock node clkx2.
create_relative_clock -base_clock system_clock -duty_cycle 50 \
-multiply 2 -target clkx2 system_clockx2
Undefined Clocks
The Classic Timing Analyzer detects undeclared clocks in your design and displays a
warning similar to the following:
Warning: Found pins functioning as undefined clocks and/or memory
enables
Info: Assuming node "clk_src" is an undefined clock
Info: Assuming node "clk_dst" is an undefined clock
The Classic Timing Analyzer reports actual data delay for undefined clocks, but
because no clock requirements exist for undefined clocks, the Classic Timing Analyzer
does not report slack for any register-to-register paths driven by an undefined clock.
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
10–10
Chapter 10: Quartus II Classic Timing Analyzer
Clock Uncertainty
PLL Clocks
Phase-locked loops (PLLs) are used for clock synthesis in Altera® devices. This device
feature is configured and connected to your design using the ALTPLL megafunction
included with the Quartus II software. Using the MegaWizard™ Plug-In Manager, you
can customize the input clock frequency, multiplication factors, division factors, and
other parameters of the ALTPLL megafunction.
f
For more information about using the PLL feature in your design, refer to the ALTPLL
Megafunction User Guide or the handbook for the targeted device family.
For PLLs, the Classic Timing Analyzer automatically creates derived clock settings
based on the parameterization of the PLL and automatically creates a base clock
setting for the input clock pin. For example, if the input clock frequency to a PLL is
100 MHz and the multiplication and division ratio is 5:2, the clock period of the PLL
clock is set to 4.0 ns and is automatically calculated by the Classic Timing Analyzer.
For the Stratix® and Cyclone® device families, you can override the PLL input clock
frequency by applying a clock setting to the input clock pin of the PLL. For example, if
the PLL input clock period is set to 10 ns (100 MHz) with a multiplication and
division ratio of 5:2, but a clock setting of 20 ns (50 MHz) is applied to the input clock
pin of the PLL, the setup relationship is 8.0 ns (125 MHz) and not 4.0 ns (250 MHz).
The Classic Timing Analyzer issues a message similar to the following:
Warning: ClockLock PLL "mypll_test:inst|altpll:altpll_component|_clk1"
input frequency requirement of 200.0 MHz overrides default required fmax
of 100.0 MHz -- Slack information will be reported
1
You cannot override the PLL output clock frequency with a clock setting in the Classic
Timing Analyzer.
1
The ALTPLL megafunction is supported in only Stratix I, Stratix II, and Stratix III of
the Stratix device family.
Clock Uncertainty
You can use Clock Setup Uncertainty and Clock Hold Uncertainty assignments to
model jitter, skew, or add a guard band associated with clock signals.
When a clock uncertainty assignment exists for a clock signal, the timing analyzer
performs the most conservative setup and hold checks. For clock setup check, the
setup uncertainty is subtracted from the data required time. Figure 10–7 shows an
example of clock sources with a clock setup uncertainty applied.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 10: Quartus II Classic Timing Analyzer
Clock Latency
10–11
Figure 10–7. Clock Setup Uncertainty
Source Clock
Destination Clock
0 ns
5 ns
10 ns
15 ns
Clock Setup Check without Uncertainty
Clock Setup Check with Uncertainty
You can create clock uncertainty assignments using the Tcl command
set_clock_uncertainty. The set_clock_uncertainty assignment used with
the switch –setup specifies a clock setup uncertainty assignment. The following
example creates a Clock Setup Uncertainty assignment with a value of 2 ns applied
to clock signal clk:
set_clock_uncertainty -to clk -setup 2ns
For the clock hold check, the hold uncertainty is added to the data required time.
Figure 10–8 shows an example of clock setup check with a clock setup uncertainty and
clock hold uncertainty applied.
Figure 10–8. Clock Hold Uncertainty
Source Clock
Destination Clock
0 ns
5 ns
10 ns
15 ns
Clock Setup Check without Uncertainty
Clock Setup Check with Uncertainty
You can use the set_clock_uncertainty Tcl command with the option –hold to
specify a Clock Hold Uncertainty assignment. The following example creates a Clock
Hold Uncertainty assignment with a value of 2 ns for clock signal clk.
set_clock_uncertainty -to clk -hold 2ns
You can also apply the clock uncertainty assignments between two clock sources. The
following example creates a Clock Setup Uncertainty assignment for clock setup
checks where clk1 is the source clock and clk2 is the destination clock:
set_clock_uncertainty -from clk1 -to clk2 -setup 2ns
Clock Latency
You can use clock latency assignments to model delays from the clock source. For
example, you can use clock latency to model an external delay from an ideal clock
source, such as an oscillator, to the clock pin or port of the device.
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
10–12
Chapter 10: Quartus II Classic Timing Analyzer
Clock Latency
The Early Clock Latency assignment allows you to specify the shortest or earliest
delay of the clock source. Conversely, the Late Clock Latency assignment allows you
to specify the longest or latest delay of the clock source.
During setup analysis, the Quartus II Classic Timing Analyzer adds the Late Clock
Latency assignment value to the source clock path delay and adds the Early Clock
Latency assignment value to the destination clock path delay when determining clock
skew for the path. During clock hold analysis, the Classic Timing Analyzer adds the
Early Clock Latency assignment value to the source clock path delay and adds the
Late Clock Latency assignment value to the destination clock path delay when
determining clock skew for the path.
The Early Clock Latency and Late Clock Latency assignments do not change the
latch and launch edges defined by the clock setting and therefore does not change the
setup or hold relationships between source and destination clocks. The clock latency
assignments add only delay to the clock network and therefore only affects clock
skew.
Figure 10–9 shows the clock edges used to calculate clock skew for a setup check
when the Early Clock Latency and Late Clock Latency assignments are used.
Figure 10–9. Clock Setup Check Clock Skew
Clock Skew Edges Without Latency
Clock Skew Edges With Latency
Source Clock
Destination Clock
Original Clock
Early Clock Latency
Late Clock Latency
Figure 10–10 shows the clock edges used to calculate clock skew for a hold check
when the Early Clock Latency and Late Clock Latency assignments are used.
Figure 10–10. Clock Hold Check Clock Skew
Clock Skew Edges Without Latency
Clock Skew Edges With Latency
Source Clock
Destination Clock
Original Clock
Early Clock Latency
Late Clock Latency
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 10: Quartus II Classic Timing Analyzer
Timing Exceptions
1
10–13
The Classic Timing Analyzer ignores clock latency if the clock signal at the source and
destination registers are the same.
You can use the set_clock_latency Tcl command with the switches -early or
-late to specify an Early Clock Latency assignment or Late Clock Latency
assignment, respectively. Example 10–1 specifies that the clock signal at clk2 arrives
as early as 1.8 ns and as late as 2.0 ns.
Example 10–1. Specifying Early or Late Clock Latency at clk2
set_clock_latency -early -to clk2 1.8ns
set_clock_latency -late -to clk2 2ns
1
The early clock latency default value is the same as the late clock latency delay, and
the late clock latency default value is the same as the early clock latency delay, if only
one is specified.
The Enable Clock Latency option must be set to ON for the Classic Timing Analyzer
to analyze clock latency. When this option is set to ON, the Classic Timing Analyzer
reports clock latency as part of the clock skew calculation for either the source or
destination clock path depending upon the analysis performed. To set the Enable
Clock Latency option to ON, use the following Tcl command:
set_global_assignment -name ENABLE_CLOCK_LATENCY ON
When the Enable Clock Latency option is turned on, the Classic Timing Analyzer
automatically calculates latencies for derived clocks instead of automatically
calculating offsets; for example, PLL compensation delays. These clock path delays
are accounted for as clock skew instead of part of the setup or hold relationship as
done with offsets.
f
For more information about clock latency, refer to AN 411: Understanding PLL Timing
for Stratix II Devices.
Timing Exceptions
Timing exceptions allow you to modify the default behavior of the Classic Timing
Analyzer. This section describes the following timing exceptions:
1
© July 2010
■
Multicycle
■
Setup relationship and hold relationship
■
Maximum delay and minimum delay
■
False paths
Not all timing exceptions presented in this chapter are applicable to the HardCopy® II
devices. If you are designing for the HardCopy II device family, refer to the Timing
Constraints for HardCopy II Devices chapter in the HardCopy II Handbook.
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
10–14
Chapter 10: Quartus II Classic Timing Analyzer
Timing Exceptions
Multicycle
By default, the Classic Timing Analyzer performs a single-cycle analysis for all valid
register-to-register paths in the design. Multicycle assignments specify the number of
clock periods before a source register launches the data or a destination register
latches the data. Multicycle assignments adjust the latch or launch edges, which
relaxes the required clock setup check or clock hold check between the source and
destination register pairs. You can specify multicycles separately for setup and hold,
and multicycles can be based on the source clock or destination clock. Apply
Multicycle exception to time groups, clock nodes, or common clock enables.
Destination Multicycle Setup Exception
A destination multicycle setup, referred to as a Multicycle exception, specifies the
minimum number of clock cycles required before a register should latch a value. A
Multicycle exception changes the latch edge by relaxing the required setup
relationship. Figure 10–11 shows a timing diagram for a multicycle path that exists in
a design with related clocks, and with the latch edge label for a clock setup check.
1
By default, the Multicycle exception value is 1.
Figure 10–11. Multicycle Setup
Source Clock
Default Clock Setup Check Latch Edge
Multicycle = 2
Destination Clock
-20 ns
-10 ns
0 ns
10 ns
20 ns
30 ns
You can apply Multicycle exception between any two registers or between any two
clock domains. Use the Tcl command set_multicycle_assingment, and the
switch –setup and –end. For example, to apply a Multicycle exception of 2 between
all registers clocked by source clock clk_src, and all registers clocked by destination
clock clk_dst, enter the following Tcl command:
set_multicycle_assignment –setup –end –from clk_src –to clk_dst 2
To apply a Multicycle exception of 2 between the source register reg1 and the
destination register reg2, enter the following Tcl command:
set_multicycle_assignment –setup –end –from reg1 –to reg2 2
Destination Multicycle Hold Exception
A destination multicycle hold, referred to as a Multicycle Hold exception, modifies
the latch edge used for a clock hold check for the register-to-register path based on the
destination clock. A Multicycle Hold exception changes the latch edge by relaxing the
required hold relationship. Figure 10–12 shows a timing diagram labeling the latching
edge for a clock setup check.
1
If no Multicycle Hold value is specified, the Multicycle Hold value defaults to the
value of the multicycle exception.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 10: Quartus II Classic Timing Analyzer
Timing Exceptions
10–15
Figure 10–12. Multicycle Hold
Source Clock
Default Clock Hold
Check Latch Edge
Multicycle Hold = 2
Destination Clock
-20 ns
-10 ns
0 ns
10 ns
20 ns
30 ns
You can create Multicycle Hold exceptions with the Tcl command
set_multicycle_assingment and the switch –hold and –end. The following
example specifies a Multicycle Hold exception of 3 from register reg1 to register
reg2:
set_multicycle_assignment –hold –end –from reg1 –to reg2 3
By default, the hold multicycle is set to equal that of the setup multicycle value along
the same path. For example, if a setup multicycle of 2 has been applied to a register-toregister path without a separate hold multicycle, the hold multicycle value would be
set to 2. The default hold multicycle value can also be changed to a value of 1. This
forces all paths with a setup multicycle assignment to have a default hold multicycle
of 1. To change the default hold multicycle value, in the Settings dialog box, click the
More Timing Settings option.
If your design requires a hold multicycle value not equal to the setup multicycle or 1,
you must explicitly apply a hold multicycle assignment to the path.
Source Multicycle Setup Exception
A source multicycle setup, referred to as Source Multicycle Setup exception, is used to
extend the required delay by adjusting the source clock’s launch edge rather than the
destination clock’s latch edge; for example, multicycle setup. Source Multicycle
exceptions are useful when the source and destination registers are clocked by related
clocks at different frequencies.
Figure 10–13 shows an example of a Source Multicycle exception with the launch edge
labeled for a clock setup check.
Figure 10–13. Source Multicycle
Source Clock
Source Multicycle = 2
Default Launch Edge for a
Clock Setup Check
Destination Clock
-20 ns
-10 ns
0 ns
10 ns
20 ns
You can create Source Multicycle Setup exceptions with the Tcl command
set_multicycle_assignment and the switches -setup and -start. The
following example specifies a Source Multicycle exception of 3 from register reg1 to
register reg2:
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
10–16
Chapter 10: Quartus II Classic Timing Analyzer
Timing Exceptions
set_multicycle_assignment –setup –start –from reg1 –to reg2 3
By default, the hold multicycle is set to equal that of the setup multicycle value along
the same path. For example, if a setup multicycle of 2 has been applied to a
register-to-register path without a separate hold multicycle, the hold multicycle value
would be set to 2. The default hold multicycle value can also be changed to a value
of 1. This forces all paths with a setup multicycle assignment to have a default hold
multicycle of 1. To change the default hold multicycle value, in the Settings dialog
box, click the More Timing Settings option.
If your design requires a hold multicycle value not equal to the setup multicycle or 1,
you must explicitly apply a hold multicycle assignment to the path.
Source Multicycle Hold Exception
The Source Multicycle Hold exception modifies the latch edge used for a clock hold
check for the register-to-register path based on the source clock. Source Multicycle
Hold exceptions increase the required hold delay by adding source clock cycles.
Figure 10–14 shows an example of a source multicycle hold with launch edge labeled
for a clock hold check.
Figure 10–14. Source Multicycle Hold
Source Clock
Default Clock Hold
Check Launch Edge
Source Multicycle Hold = 2
Destination Clock
-20 ns
-10 ns
0 ns
10 ns
20 ns
You can create Source Multicycle Hold exceptions with the Tcl command
set_multicycle_assingment and the switch –setup and –start. The
following example specifies a Source Multicycle Hold exception of 3 from register
reg1 to register reg2:
set_multicycle_assignment –hold –start –from reg1 –to reg2 3
Default Hold Multicycle
The Classic Timing Analyzer sets the hold multicycle value to equal the multicycle
value when a multicycle exception has been entered without a corresponding hold
multicycle. You can change the behavior with the DEFAULT_HOLD_MULTICYCLE
assignment. The value of the assignment can either be "ONE" or "SAME AS
MULTICYCLE".
The assignment has the following syntax:
set_global_assignment -name DEFAULT_HOLD_MULTICYCLE "<value>"
Clock Enable Multicycle
For all enable-driven registers, the setup relationship or hold relationship can be
modified with the Clock Enable Multicycle, Clock Enable Multicycle Hold, Clock
Enable Source Multicycle, or Clock Enable Multicycle Source Hold.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 10: Quartus II Classic Timing Analyzer
Timing Exceptions
10–17
The Clock Enable Multicycle modifies the latching edge when a clock setup check is
performed for all registers driven by the specified clock enables, and the Clock
Enable Multicycle Hold modifies the latching edge when a clock hold check is
performed for all registers driven by the specified clock enable. The Clock Enable
Source Multicycle modifies the launching edge when a clock setup check is
performed for all enabled driven registers, and the Clock Enable Source Multicycle
Hold modifies the launching edge when a clock hold check is performed for all
enabled driven registers.
1
Clock enable-based multicycle exceptions apply only to registers using dedicated
clock enable circuitry. If the enable is synthesized into a logic cell; for example, due to
signal prioritization, the multicycle does not apply.
The Clock Enable Multicycle, Clock Enable Multicycle Hold, Clock Enable Source
Multicycle, and Clock Enable Multicycle Source Hold can be either a single-point or
a point-to-point assignment.
Figure 10–15 shows an example of a single-point assignment. In this example, register
Reg A has the single-point assignment applied. This has the affect of modifying a
register-to-register latching edge whose enable port is driven by register Reg A. All
register-to-register paths with enables driven by the single-point assignment are
affected, even those driven by different clock sources.
Figure 10–15. Single-Point Clock Enable Multicycle
Single-Point
Assignment to Reg A
D
Q
Reg A
ENA
Assignment Affects all Enable-Driven Registers
Paths of Assigned Register:
Reg C to Reg B
Reg C to Reg D
Reg F to Reg G
D
Q
Reg B
ENA
D
Q
Reg C
D
Q
Reg D
ENA
ENA
D
Q
Reg E
D
D
Q
Reg G
ENA
ENA
Q
Reg F
ENA
Point-to-point assignments apply to all paths where the source registers’ enable ports
are driven by the source (from) node and the destination registers’ enable ports are
driven by the destination (to) node.
Figure 10–16 shows an example of a point-to-point assignment made to different
source and destination registers. In this example, register Reg A is specified as the
source, and register Reg B is specified as the destination for the assignment. Only
register-to-register paths that have their enables driven by the assigned point-to-point
registers have their latching edges modified.
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
10–18
Chapter 10: Quartus II Classic Timing Analyzer
Timing Exceptions
Figure 10–16. Different Source and Destination Point-to-Point Assignment Clock Enable Multicycle
Point-to-point Assignment Made to Source & Destination
Register Feeding Enable-Driven Register(s)
(Reg A to Reg B)
D
Q
Reg A
D
Q
Reg B
ENA
ENA
D
Q
Reg C
D
Q
Reg D
ENA
ENA
Affected Path: Reg C to Reg D
Figure 10–17 shows an example of a point-to-point assignment made to the same
source and destination register. In this example, register Reg A has been specified as
both the source and register for the assignment. Only register-to-register paths that
have both the source-enable port and destination-enable port has the
latching edge modified by the assigned point-to-point assignment.
Figure 10–17. Same Source and Destination Point-to-Point Assignment Clock Enable Multicycle
Point-to-Point Assignment
From Reg A to Reg A
(From Reg A to Reg A)
D
Q
Reg A
ENA
Assignment Affects Paths in Which Both
Source & Destination are Controlled by
the Same Clock Enable Signal:
Reg C to Reg B
Reg C to Reg D
D
Q
Reg B
ENA
D
Q
Reg C
D
Q
Reg D
ENA
ENA
D
Q
Reg E
D
D
Q
Reg G
ENA
ENA
Q
Reg F
ENA
You can use the set_instance_assignment -name
CLOCK_ENABLE_MULTICYCLE and set_instance_assignment -name
CLOCK_ENABLE_MULTICYCLE_HOLD Tcl commands to specify either a Clock Enable
Multicycle or a Clock Enable Multicycle Hold assignment, respectively. The
following example specifies a single-point Clock Enable Multicycle assignment of
2 ns to reg1:
set_instance_assignment -name CLOCK_ENABLE_MULTICYCLE 2 -to reg1
The following example specifies a point-to-point Clock Enable Multicycle Hold
assignment of 2 from register reg1 to register reg2:
set_instance_assignment -name CLOCK_ENABLE_MULTICYCLE_HOLD 2 \
-from reg1 -to reg2
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 10: Quartus II Classic Timing Analyzer
Timing Exceptions
10–19
You can use the set_instance_assignment -name
CLOCK_ENABLE_SOURCE_MULTICYCLE and set_instance_assignment -name
CLOCK_ENABLE_MULTICYCLE_SOURCE_HOLD Tcl commands to specify either a
Clock Enable Multicycle or Clock Enable Multicycle Hold assignment, respectively.
The following example specifies a single-point Clock Enable Multicycle assignment
of 2 ns to reg1:
set_instance_assignment -name CLOCK_ENABLE_SOURCE_MULTICYCLE 2 \
-to reg1
The following example specifies a point-to-point Clock Enable Multicycle Hold
assignment of 2 from register reg1 to register reg2:
set_instance_assignment -name \
CLOCK_ENABLE_SOURCE_MULTICYCLE_HOLD 2 -from reg1 -to reg2
Setup Relationship and Hold Relationship
By default, the Classic Timing Analyzer determines all setup and hold relationships
based on clock settings. The Setup Relationship and Hold Relationship exceptions
allow you to override any default setup or hold relationships. Example 10–2 shows
the path details of a register-to-register path that has a 10 ns clock setting applied to
the clock signal driving the 2 registers.
Example 10–2. Default Setup Relationship with 10 ns Clock Setting
Info: Slack time is 9.405 ns for clock "data_clk" between source register "reg9" and
destination register "reg10"
Info: Fmax is restricted to 500.0 MHz due to tcl and tch limits
Info: + Largest register to register requirement is 9.816 ns
Info: + Setup relationship between source and destination is 10.000 ns
Info: + Latch edge is 10.000 ns
Info: - Launch edge is 0.000 ns
Info: + Largest clock skew is 0.000 ns
Info: - Micro clock to output delay of source is 0.094 ns
Info: - Micro setup delay of destination is 0.090 ns
Info: - Longest register to register delay is 0.411 ns
In Example 10–3, a 15 ns Setup Relationship exception is applied to the
register-to-register path, overriding the default 10 ns setup relationship.
Example 10–3. Setup Relationship Assignment of 15 ns
Info: Slack time is 14.405 ns for clock "data_clk" between source register "reg9" and
destination register "reg10"
Info: Fmax is restricted to 500.0 MHz due to tcl and tch limits
Info: + Largest register to register requirement is 14.816 ns
Info: + Setup relationship between source and destination is 15.000 ns
Info: Setup Relationship assignment value is 15.000 ns between source "reg9" and
destination "reg10"
Info: + Largest clock skew is 0.000 ns
Info: Total interconnect delay = 1.583 ns ( 51.31 % )
Info: - Micro clock to output delay of source is 0.094 ns
Info: - Micro setup delay of destination is 0.090 ns
Info: - Longest register to register delay is 0.411 ns
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
10–20
Chapter 10: Quartus II Classic Timing Analyzer
Timing Exceptions
You can create a Setup Relationship exception with the Tcl command
set_instance_assignment -name SETUP_RELATIONSHIP. The following
example specifies a Setup Relationship exception of 5 ns from register reg1 to register
reg2:
set_instance_assignment -name SETUP_RELATIONSHIP 5ns -from reg1 \
-to reg2
You can use Hold Relationship exception to override the default hold relationship of
any register-to-register paths.
You can use the set_instance_assignment -name HOLD_RELATIONSHIP Tcl
command to specify a hold relationship assignment. The following example specifies
a Hold Relationship exception of 1 ns from register reg1 to register reg2:
set_instance_assignment -name HOLD_RELATIONSHIP 1ns -from reg1 \
-to reg2
Maximum Delay and Minimum Delay
You can use Maximum Delay and Minimum Delay assignments to specify delay
requirements for pin-to-register, register-to-register, and register-to-pin paths. The
Maximum Delay assignment overrides any setup relationship for any path. The
Minimum Delay assignment overrides any hold relationship for any path.
1
The Classic Timing Analyzer ignores the effects of clock skew when checking a design
against Maximum Delay and Minimum Delay assignments.
You can use the set_instance_assignment –name MAX_DELAY and
set_instance_assignment –name –MIN_DELAY Tcl commands to specify a
Maximum Delay assignment or a Minimum Delay assignment, respectively. The
following example specifies a maximum delay of 2 ns between source register reg1
and destination register reg2:
set_instance_assignment -name MAX_DELAY 2ns -from reg1 -to reg2
The following example specifies a minimum delay of 1 ns between input pin
data_in to destination register dst_reg:
set_instance_assignment -name MIN_DELAY 1ns -from data_in -to dst_reg
False Paths
A false path is any path that is not relevant to the operation of a circuit, such as test
logic. There are several global assignments to cut different classes of paths, such as
unrelated clock domains and paths through bidirectional pins, but you can also cut an
individual timing path to a specific false path.
The timing analyzer provides the following three global options that allow you to
remove false paths from your design:
■
Cut off feedback from I/O pins
■
Cut off read-during-write signal paths
■
Cut paths between unrelated clock domains
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 10: Quartus II Classic Timing Analyzer
Timing Exceptions
10–21
You can use the set_global_assignment -name CUT_OFF_IO_PIN_FEEDBACK
ON Tcl command to cut the feedback path when a bidirectional I/O pin is connected
directly or indirectly to both the input and output of a latch.
You can use the set_global_assignment -name
CUT_OFF_READ_DURING_WRITE_PATHS ON Tcl command to cut the path from the
write-enable register through memory element to a destination register.
You can use the set_global_assignment -name
CUT_OFF_PATHS_BETWEEN_CLOCK_DOMAINS ON Tcl command to cut paths
between register-to-register where the source and destination clocks are different.
You can use the set_timing_cut_assignment Tcl command to cut specific timing
paths. In Figure 10–18, the path from inst1 through the multiplexer to inst2 is used
only for design testing. This false path is not required under normal operation and
does not need to be analyzed during static timing analysis.
Figure 10–18 shows an example of a false path.
Figure 10–18. False Path Signal
DFF
D
Q
Clock
BUSMX
inst
dataa[]
datab[]
inst3
0
1
result[]
DFF
D
Q
sel
DFF
D
Q
Test Enable
inst1
To cut the timing path from source register inst1 to destination register inst2, enter
the following Tcl command:
set_timing_cut_assignment -from inst1 -to inst2
You can also use the set_timing_cut_assignment Tcl command as a single point
assignment. When you use the single point assignment, all fanout of the node is cut.
For example, the following Tcl command cuts all timing paths originating for node
src_reg:
set_timing_cut_assignment -to src_reg
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
10–22
Chapter 10: Quartus II Classic Timing Analyzer
I/O Analysis
I/O Analysis
The I/O analysis performed by the Classic Timing Analyzer ensures your Altera
FPGA design meets all timing specifications for interfacing with external devices. This
section describes assignments relevant to I/O analysis and other I/O analysis features
and options available with the Quartus II Classic Timing Analyzer.
External Input Delay and Output Delay Assignments
External input and output delays represent delays from or to external devices or
boards traces. You can make Input Delay and Output Delay assignments to ensure
the Classic Timing Analyzer can perform a full system analysis. By providing Input
Delays and Output Delays, the Classic Timing Analyzer is able to perform clock
setup and clock hold checks for these paths. This also allows other timing
assignments, such as multicycle or clock uncertainty, to be applied to input and
output paths.
1
Do not combine individual or global tSU, tH, tPD, tCO, minimum tCO, or minimum tPD
assignments with Input Delay or Output Delay assignments.
Input Delay Assignment
External input delays are specified with either Input Maximum Delay or Input
Minimum Delay assignments. Make Input Maximum Delay assignments to specify
the maximum delay of a signal from an external register to a specified input or
bidirectional pin on the FPGA relative to a specified clock source. Make Input
Minimum Delay assignments to specify the minimum delay of a signal from an
external register to a specified input or bidirectional pin on the FPGA relative to a
specified clock source.
When performing a clock setup check, the Classic Timing Analyzer adds the Input
Maximum Delay assignment value to the data arrival time (or subtracts the
assignment value from the point-to-point requirement).
When performing a clock hold check, the Classic Timing Analyzer adds the Input
Minimum Delay assignment value to the data arrival time (or subtracts the
assignment value from the point-to-point requirement).
The value of the input delay assignment usually represents the sum of the tCO of the
external device, the actual board delay to the input pin of the Altera device, and the
board clock skew.
1
The Input Minimum Delay defaults to the Input Maximum Delay and the Input
Maximum Delay defaults to the Input Minimum Delay if only one is specified.
For example, the Input Maximum Delay and Input Minimum Delay can be used to
model the delay associated with an external device driving into an Altera FPGA.
Figure 10–19 shows an example of the input delay path. For Figure 10–19, the Input
Maximum Delay can be calculated as shown in Equation 10–19.
Equation 10–19.
Input Maximum Delay = External Device Board Clock Path + External Device t co +
External Device to Altera Device Board Delay – External Clock Path to Altera Device
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 10: Quartus II Classic Timing Analyzer
I/O Analysis
10–23
Figure 10–19. Input Delay
External Device
Altera Device
Oscillator
Use the Tcl command set_input_delay to specify an input delay. The following
example specifies an Input Maximum Delay assignment of 1.5 ns from clock node
clk to input pin data_in:
set_input_delay -clk_ref clk -to "data_in" -max 1.5ns
The following example specifies an Input Minimum Delay assignment of 1 ns from
clock node clk to input pin data_in:
set_input_delay -clk_ref clk -to "data_in" -min 1ns
When using Input Delay assignments, specify a particular clock reference. The clock
reference is the clock that feeds the external register’s clock port that feeds the Altera
device. This allows the Classic Timing Analyzer to perform the proper analysis for the
input path.
1
The tSU, tH, tPD, and min tPD timing paths reported for input pins, where input delay
internal to the Altera FPGA assignments has been applied, include only the data
delay from these pins and do not account for any clock setup relationships, clock hold
relationships, or slack.
Output Delay Assignment
You can specify external output delays with either Output Maximum Delay or
Output Minimum Delay assignments. Make Output Maximum Delay assignments
to specify the maximum delay of a signal from the specified FPGA output pin to an
external register, relative to a specified clock source. Make Output Minimum Delay
assignments to specify the minimum delay of a signal from the specified FPGA
output pin to an external register relative to a specified clock source.
When performing a clock setup check, the Classic Timing Analyzer subtracts the
Output Maximum Delay assignment value from the data required time (or subtracts
the assignment value from the point-to-point requirement).
When performing a clock hold check, the Classic Timing Analyzer subtracts the
Output Minimum Delay assignment value from the data required time (or subtracts
the assignment value from the point-to-point requirement).
The value of this assignment usually represents the sum of the tSU of the external
device, the actual board delay from the output pin of the Altera device, and the board
clock skew.
1
© July 2010
The Output Minimum Delay default value is the same as the Output Maximum Delay,
and the Output Maximum Delay default value is the same as the Output Minimum
Delay if only one is specified.
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
10–24
Chapter 10: Quartus II Classic Timing Analyzer
I/O Analysis
For example, use the Output Maximum Delay and Output Minimum Delay to model
the delay associated with outputs for an Altera FPGA driving into an external device.
Figure 10–20 shows an example of an output delay path. For Figure 10–20 the Output
Maximum Delay can be calculated, as shown in Equation 10–20.
Equation 10–20.
Output Maximum Delay = Altera Device to External Device Board Delay + External Device t su +
External Clock Path to Altera Device – External Device Board Clock Path
Figure 10–20. Output Delay
Altera Device
External Device
Oscillator
The Tcl command set_output_delay specifies an Output Delay assignment. The
following example specifies an Output Maximum Delay assignment of 2 ns from
clock clk to output pin data_out:
set_output_delay -clk_ref clk -to data_out -max 2ns
The following example specifies an Output Minimum Delay assignment of 1 ns from
clock clk to output pin data_out:
set_output_delay -clk_ref clk -to data_out -min 1ns
When using output delay assignments, specify a specific clock reference. The clock
reference is the clock that feeds the external register’s clock port that is fed by the
Altera device. This allows the Classic Timing Analyzer to perform the correct static
timing analysis on the output path.
1
The tCO, minimum tCO, tPD, and minimum tPD timing paths reported for output pins,
where output delay assignments have been applied include only the data delay
internal to the Altera FPGA to those pins, and do not account for any clock setup
relationships, clock hold relationships, or slack.
Virtual Clocks
You can use virtual clocks to model clock signals outside of the Altera FPGA, that is,
clocks that do not directly drive anything within the Altera FPGA. For example, you
can use a virtual clock to model a clock signal feeding an external output register that
feeds the Altera FPGA.
Using the -virtual option of the create_base_clock Tcl command specifies a
virtual clock assignment.
1
Before a you can use virtual clock for either an input or output delay assignment, the
virtual clock must have the Virtual Clock Reference assignment enabled for the
virtual clock setting.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 10: Quartus II Classic Timing Analyzer
Asynchronous Paths
10–25
The code in Example 10–4 creates a virtual clock named virt_clk, with a 200 MHz
requirement, and uses the virtual clock setting as the clock reference for the input
delay assignment.
Example 10–4. Creating a Virtual Clock Named virt_clk
#create the virtual clock setting
create_base_clock -fmax 200MHz -virtual virt_clk
#enable the virtual clock reference for the virtual clock setting
set_instance_assignment -name VIRTUAL_CLOCK_REFERENCE On -to virt_clk
#use the virtual clock setting as the clock reference for the input delay assignment
set_input_delay –clk_ref virt_clk –to data_in –max 2ns
Asynchronous Paths
The Classic Timing Analyzer can analyze asynchronous signals that connect to the
clear, preset, or load ports of a register. This section explains how the Classic Timing
Analyzer analyzes asynchronous paths.
Recovery and Removal
Recovery time is the minimum length of time an asynchronous control signal; for
example, clear and preset, must be stable before the active clock edge. Removal time is
the minimum length of time an asynchronous control signal must be stable after the
active clock edge. The Enable Recovery/Removal analysis option reports the results
of recovery and removal checks for paths that end at an asynchronous clear, preset, or
load signal of a register.
Enable the recovery and removal analysis with the following Tcl command:
set_global_assignment -name ENABLE_RECOVERY_REMOVAL_ANALYSIS ON
With this option enabled, the Classic Timing Analyzer reports the result of the
recovery analysis and removal analysis.
1
By default, the recovery and removal analysis is disabled. You should enable his
option for all designs that contain asynchronous controls signals.
Recovery Report
When you set ENABLE_RECOVERY_REMOVAL_ANALYSIS to ON, the Classic Timing
Analyzer determines the recovery time as the minimum amount of time required
between an asynchronous control signal becoming inactive and the next active clock
edge, compares this to your design, and reports the results as slack. The Recovery
report alerts you to conditions where an active clock edge occurs too soon after the
asynchronous input becomes inactive, rendering the register’s data uncertain.
The recovery slack time calculation is similar to the calculation for clock setup slack,
which is based on data arrival time and data required time except for asynchronous
control signals. If the asynchronous control is registered, the Classic Timing Analyzer
calculates the recovery slack time using Equation 10–21 through Equation 10–23.
Equation 10–21.
Recovery Slack Time = Data Required Time – Data Arrival Time
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
10–26
Chapter 10: Quartus II Classic Timing Analyzer
Asynchronous Paths
Equation 10–22.
Data Arrival Time = Launch Edge + Longest Clock Path to Source Register +
micro t co of Source Register + Longest Register-to-Register Delay
Equation 10–23.
Data Required Time = Latch Edge + Longest Clock Path to Source Register +
micro t su of Destination Register
Example 10–5 shows recovery time as reported by the timing analyzer.
Example 10–5. Recovery Time Reporting for a Registered Asynchronous Reset Signal
Info: Slack time is 8.947 ns for clock "a_clk" between source register "async_reg1" and
destination register "reg_1"
Info: Requirement is of type recovery
Info: - Data arrival time is 4.028 ns
Info: + Launch edge is 0.000 ns
Info: + Longest clock path from clock "a_clk" to source register is 3.067 ns
Info: + Micro clock to output delay of source is 0.094 ns
Info: + Longest register to register delay is 0.867 ns
Info: + Data required time is 12.975 ns
Info: + Latch edge is 10.000 ns
Info: + Shortest clock path from clock "a_clk" to destination register is 3.065 ns
Info: - Micro setup delay of destination is 0.090 ns
If the asynchronous control is not registered, the Classic Timing Analyzer uses
Equation 10–24 through Equation 10–26 to calculate the recovery slack time.
Equation 10–24.
Recovery Slack Time = Data Required Time – Data Arrival Time
Equation 10–25.
Data Arrival Time = Launch Edge + Maximum Input Delay + Maximum Pin-to-Register Delay
Equation 10–26.
Data Required Time = Latch Edge + Shortest Clock Path to Destination Register Delay –
micro t SU of Destination Register
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 10: Quartus II Classic Timing Analyzer
Asynchronous Paths
10–27
Example 10–6 shows recovery time as reported by the timing analyzer.
Example 10–6. Recovery Time Reporting for a Non-Registered Asynchronous Reset Signal
Info: Slack time is 8.744 ns for clock "a_clk15" between source pin "a_arst2" and
destination register "inst5"
Info: Requirement is of type recovery
Info: - Data arrival time is 4.787 ns
Info: + Launch edge is 0.000 ns
Info: + Max Input delay of pin is 1.500 ns
Info: + Max pin to register delay is 3.287 ns
Info: + Data required time is 13.531 ns
Info: + Latch edge is 10.000 ns
Info: + Shortest clock path from clock "a_clk15" to destination register is 3.542 ns
Info: - Micro setup delay of destination is 0.011 ns
1
If the asynchronous reset signal is from a device pin, an Input Maximum Delay
assignment must be made to the asynchronous reset pin for the Classic Timing
Analyzer to perform recovery analysis on that path.
Removal Report
When you set ENABLE_RECOVERY_REMOVAL_ANALYSIS to ON, the Classic Timing
Analyzer determines the removal time as the minimum amount of time required
between an active clock edge that occurs while an asynchronous input is active, and
the deassertion of the asynchronous control signal. The Classic Timing Analyzer then
compares this to your design and reports the results as slack. The Removal report
alerts you to a condition in which an asynchronous input signal goes inactive too soon
after a clock edge, thus rendering the register’s data uncertain.
The removal time slack calculation is similar to the one used to calculate clock hold
slack, which is based on data arrival time and data required time except for
asynchronous control signals. If the asynchronous control is registered, the Classic
Timing Analyzer uses Equation 10–27 through Equation 10–29 to calculate the
removal slack time.
Equation 10–27.
Removal Slack Time = Data Arrival Time – Data Required Time
Equation 10–28.
Data Arrival Time = Launch Edge + Shortest Clock Path from Source Register Delay +
micro t co of Source Register + Shortest Register-to-Register Delay
Equation 10–29.
Data Required Time = Latch Edge + Longest Clock Path to Destination Register Delay +
micro t H of Destination Register
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
10–28
Chapter 10: Quartus II Classic Timing Analyzer
Asynchronous Paths
Example 10–7 shows removal time as reported by the Classic Timing Analyzer.
Example 10–7. Removal Time Reporting for a Registered Asynchronous Reset Signal
Info: Minimum slack time is 814 ps for clock "a_clk" between source register "async_reg1"
and destination register "reg_1"
Info: Requirement is of type removal
Info: + Data arrival time is 4.028 ns
Info: + Launch edge is 0.000 ns
Info: + Shortest clock path from clock "a_clk" to source register is 3.067 ns
Info: + Micro clock to output delay of source is 0.094 ns
Info: + Shortest register to register delay is 0.867 ns
Info: - Data required time is 3.214 ns
Info: + Latch edge is 0.000 ns
Info: + Longest clock path from clock "a_clk" to destination register is 3.065 ns
Info: + Micro hold delay of destination is 0.149 ns
If the asynchronous control is not registered, the Classic Timing Analyzer uses
Equation 10–30 through Equation 10–32 to calculate the removal slack time.
Equation 10–30.
Removal Slack Time = Data Arrival Time – Data Required Time
Equation 10–31.
Data Arrival Time = Launch Edge + Input Minimum Delay of Pin +
Minimum Pin-to-Register Delay
Equation 10–32.
Data Required Time = Latch Edge + Longest Clock Path to Destination Register Delay +
micro t H of Destination Register
Example 10–8 shows removal time as reported by the Classic Timing Analyzer.
Example 10–8. Removal Time Reporting for a Non-Registered Asynchronous Reset Signal
Info: Minimum slack time is 1.131 ns for clock "a_clk15" between source pin "a_arst2"
and destination register "inst5"
Info: Requirement is of type removal
Info: + Data arrival time is 4.787 ns
Info: + Launch edge is 0.000 ns
Info: + Min Input delay of pin is 1.500 ns
Info: + Min pin to register delay is 3.287 ns
Info: - Data required time is 3.656 ns
Info: + Latch edge is 0.000 ns
Info: + Longest clock path from clock "a_clk15" to destination register is 3.542 ns
Info: + Micro hold delay of destination is 0.114 ns
1
If the asynchronous reset signal is from a device pin, an Input Minimum Delay
assignment must be made to the asynchronous reset pin for the Classic Timing
Analyzer to perform a removal analysis on this path.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 10: Quartus II Classic Timing Analyzer
Skew Management
10–29
Skew Management
Clock skew is the difference in the arrival times of a clock signal at two different
registers, which can be caused by path length differences between two clock paths, or
by using gated or rippled clocks. As clock periods become shorter and shorter, the
skew between data arrival times and clock arrival times becomes more significant.
The Classic Timing Analyzer provides two assignments for analyzing and
constraining skew for data and clock signals.
Maximum Clock Arrival Skew
Make Maximum Clock Arrival Skew assignments to specify the maximum allowable
clock arrival skew between a clock signal and various destination registers. The
Classic Timing Analyzer compares the longest clock path to the registers’ clock port
and the shortest clock path to the registers’ clock port to determine if your maximum
clock arrival skew is achieved. Maximum clock arrival skew is calculated using
Equation 10–33.
Equation 10–33.
Maximum Clock Arrival Skew = Longest Clock Path – Shortest Clock Path
For example, if the delay from clock pin clk to the clock port of register reg1 is
1.0 ns, and the delay from clock pin clk to the clock port of register reg2 is 3.0 ns, as
shown in Figure 10–21, the Classic Timing Analyzer provides a clock skew slack time
of 2.0 ns.
Figure 10–21. Clock Arrival Paths
data
reg1
reg2
out1
clk
1
You should apply the Maximum Clock Arrival Skew assignment to a clock node and
a group of registers. When you make a Maximum Clock Arrival Skew assignment,
the Fitter attempts to satisfy the skew requirement.
You can use the set_instance_assignment -name
max_clock_arrival_skew Tcl command to specify a Maximum Clock Arrival
Skew assignment. The following example specifies a maximum clock arrival skew of
1 ns from clock signal clk to the bank of registers matching reg*:
set_instance_assignment -name max_clock_arrival_skew 1ns -from clk \
-to reg*
Maximum Data Arrival Skew
Make Maximum Data Arrival Skew assignments to specify the maximum allowable
data arrival skew to various destination registers or pins. The Classic Timing
Analyzer compares the longest data arrival path to the shortest data arrival path to
determine if your specified maximum data arrival skew is achieved. Maximum data
arrival skew is calculated using Equation 10–34.
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
10–30
Chapter 10: Quartus II Classic Timing Analyzer
Generating Timing Analysis Reports with report_timing
Equation 10–34.
Maximum Data Arrival Skew = Longest Data Arrival Path – Shortest Data Arrival Path
For example, if the data arrival time to output pin out1 is 2.0 ns, the data arrival time
to output pin out2 is 1.5 ns, and the data arrival time to output pin out3 is 1.0 ns, as
shown in Figure 10–22, the Classic Timing Analyzer provides a maximum data arrival
skew slack time of 1.0 ns.
Figure 10–22. Data Arrival Paths
reg1
out1
reg2
out2
reg3
out3
clk
1
When you make a Maximum Data Arrival Skew assignment, the Fitter attempts to
satisfy the skew requirement.
You can use the set_instance_assignment -name max_data_arrival_skew
Tcl command to specify a maximum data arrival skew value. The following example
specifies a maximum data arrival skew of 1 ns from clock signal clk to the bank of
output pins dout:
set_instance_assignment -name max_data_arrival_skew 1ns -from clk \
-to dout[*]
Generating Timing Analysis Reports with report_timing
The Classic Timing Analyzer includes the report_timing Tcl command for
generating text-based timing analysis reports. You can customize the output of
report_timing using multiple switches that allow the generation of both detailed
and general timing reports on any path in the design.
1
The report_timing Tcl command is available in the quartus_tan executable.
Prior to using the report_timing Tcl command, you must open a Quartus II project
and create a timing netlist. For example, the following two Tcl commands accomplish
this:
project_open my_project
create_timing_netlist
The report_timing Tcl command provides -from and -to switches for filtering
specific source and destination nodes. For example, the following report_timing
Tcl command reports all clock setup paths, with the switch –clock_setup, between
registers src_reg* and dst_reg*. The –npaths 20 switch limits the report to 20
paths.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 10: Quartus II Classic Timing Analyzer
Other Timing Analyzer Features
10–31
report_timing –clock_setup –from src_reg* -to dst_reg* -npaths 20
The switches -clock_filter and -src_clock_filter are also available for
filtering based on specific clock sources. For example, the following report_timing
Tcl command reports all clock setup paths where the destination registers are clocked
by clk:
report_timing -clock_setup -clock_filter clk
The following example reports clock setup paths where the destination registers are
clocked by clk, and the source registers are clocked by src_clock.
report_timing -clock_setup -clock_filter clk -src_clock_filter src_clk
Example 10–9 is an example script that can be sourced by the quartus_tan
executable:
Example 10–9. Source for the quartus_tan Executable
# Open a project
project_open my_project
# Always create the netlist first
create_timing_netlist
# List clock setup paths for clock clk
# from registers abc* to registers xyz*
report_timing -clock_setup -clock_filter clk -from abc* -to xyz*
# List the top 5 pin-to-pin combinational paths
report_timing -tpd -npaths 5
# List the top 5 pin-to-pin combinational paths and
# write output to an out.tao file
report_timing -tpd -npaths 5 -file out.tao
# Compute min tpd and append results to existing out.tao
report_timing -min_tpd -npaths 5 -file out.tao -append
# Show longest path (register to register data path) between a* and b*
report_timing -longest_paths -npaths 1
delete_timing_netlist
project close
Other Timing Analyzer Features
The Classic Timing Analyzer provides many features for customizing and increasing
the efficiency of static timing analysis, including:
■
Wildcard assignments
■
Assignment groups
■
Fast corner analysis
■
Early timing estimation
■
Timing constraint checker
■
Latch analysis
Wildcard Assignments
To simplify the tasks of making assignments to many node assignments, the
Quartus II software accepts the ‘*’ and ‘?’ wildcard characters. Use these wildcard
characters to reduce the number of individual assignments you need to make for your
design.
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
10–32
Chapter 10: Quartus II Classic Timing Analyzer
Other Timing Analyzer Features
The ‘*’ wildcard character matches any string. For example, given an assignment
made to a node specified as reg*, the Classic Timing Analyzer searches and applies
the assignment to all design nodes that match the prefix reg with none, one, or
several characters following, such as reg1, reg[2], regbank, and reg12bank.
The ‘?’ wildcard character matches any single character. For example, given an
assignment made to a node specified as reg?, the Classic Timing Analyzer searches
and applies the assignment to all design nodes that match the prefix reg and any
single character following, such as reg1, rega, and reg4.
Assignment Groups
Assignment groups, also known as time groups, allow you to define a custom group
of nodes to which you can assign timing assignments. You can also exclude specific
nodes, wildcards, and time groups from a time group.
Use the timegroup Tcl command to create an assignment group. The following
example creates an assignment group srcgrp and adds nodes with names that match
src1* to the group:
timegroup srcgrp –add_member src1*
For example, Figure 10–23 has false paths between source register reg1 and
destination register bank sram_reg, external_reg, internal_reg, and
cam_reg that need to be cut. Without the use of assignment groups, the assignments
required are:
set_timing_cut_assignment
set_timing_cut_assignment
set_timing_cut_assignment
set_timing_cut_assignment
–from
–from
–from
–from
reg1
reg1
reg1
reg1
to
to
to
to
sram_reg
external_reg
internal_reg
cam_reg
Figure 10–23. False Path
sram_reg
sram
external_reg
reg1
clk
external
internal_reg
internal
cam_reg
cam
With an assignment group called dst_reg_bank, the assignments required are:
#create a time group called dst_reg
timegroup dst_reg_bank –add_member sram_reg
timegroup dst_reg_bank –add_member external_reg
timegroup dst_reg_bank –add_member internal_reg
timegroup dst_reg_bank –add_member cam_reg
#cut timing paths
set_timing_cut_assignment –from reg1 to dst_reg_bank
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 10: Quartus II Classic Timing Analyzer
Other Timing Analyzer Features
10–33
Once an assignment group has been defined, applicable timing assignment can be
made to the time group without redefining the assignment group.
1
Assigning individual nodes to time groups and applying timing assignments to these
time groups can improve the performance of the Classic Timing Analyzer.
Fast Corner Analysis
Fast Corner Analysis uses timing models generated under best-case conditions
(voltage, process, and temperature) for the fastest speed-grade device.
1
Both Fast Corner and Slow Corner static timing analysis reports are saved to the
<project name>.tan.rpt file, potentially overwriting previous timing analysis reports.
To preserve a copy of your reports, save the file with a new name before the next
compilation or static timing analysis, or use the Combined Fast/Slow Analysis report
feature.
The Quartus II software also reports minimum delay checks after a slow corner
(default) analysis. These results are generated by reporting minimum delay checks
using worst-case timing models.
To perform fast corner static timing analysis with the best-case timing models, you
can use the switch -–fast_model=on with the quartus_tan executable. The
following Tcl command enables the fast timing models:
quartus_tan <project_name> --fast_model=on
Early Timing Estimation
The majority of Quartus II software compilation time is consumed by the place-androute process used to obtain optimal design results. To accelerate the design process
for large designs, the Quartus II software provides Early Timing Estimation. This
feature provides a quick static timing analysis in a fraction of the time required for a
full compilation by performing a preliminary place-and-route on the design without
full optimizations, which reduces total compile time by up to five times compared to a
fully fitted design.
1
An Early Timing Estimate fit is not fully optimized or legally routed. The timing delay
report is only an estimate. Typically, the estimated delays are within 10% of those
obtained with a full fit when the realistic setting is used.
The Early Timing Estimate has three settings for generating timing estimates:
Realistic, Optimistic, and Pessimistic. Table 10–1 describes these settings.
Table 10–1. Early Timing Estimate Setting Options
Setting
Description
Realistic (default setting: estimates final timing
using standard fitting)
Generates timing estimates that are likely to be closest to full
compilation results.
Optimistic (estimates best-case final timing)
Generates timing estimates that are unlikely to be exceeded by full
compilation.
Pessimistic (estimates worst-case final timing)
Generates timing estimates that are likely to be exceeded by full
compilation.
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
10–34
Chapter 10: Quartus II Classic Timing Analyzer
Other Timing Analyzer Features
To use the Early Timing Estimate feature, enter the following Tcl command when
performing a fit:
quartus_fit \
--early_timing_estimate[=<realistic|optimistic|pessimistic>]
After Early Timing Estimate is complete, a full timing report is generated based on
the early placement and routing delays. In addition, you can view the preliminary
logic placement in the Chip Planner. The early timing placement allows you to
perform initial placement and view the timing interaction of various placement
topology.
Timing Constraint Checker
Altera recommends that you enter all timing constraints into the Quartus II software
prior to performing a full compilation. This ensures that the Fitter targets the correct
timing requirements and ensures that the Classic Timing Analyzer reports the correct
violations for all timing paths in the design. To ensure that all constraints have been
applied to design nodes, the Timing Constraint Check feature reports all
unconstraint paths in your design. Example 10–10 shows the timing constraint check
summary generated after a full compilation.
Example 10–10. Timing Constraint Check Summary
+------------------------------------------------------------------------------------+
; Timing Constraint Check Summary
;
+----------------------------------------+-------------------------------------------+
; Timing Constraint Check Status
; Analyzed - Tue Feb 28 11:42:31 2006
;
; Quartus II Version
; 6.1 Internal Build 143 02/20/2006 SJ Full Version ;
; Revision Name
; test
;
; Top-level Entity Name
; Block1
;
; Unconstrained Clocks
; 0
;
; Unconstrained Paths (Setup)
; 22
;
; Unconstrained Reg-to-Reg Paths (Setup) ; 0
;
; Unconstrained I/O Paths (Setup)
; 22
;
; Unconstrained Paths (Hold)
; 12
;
; Unconstrained Reg-to-Reg Paths (Hold) ; 0
;
; Unconstrained I/O Paths (Hold)
; 12
;
+----------------------------------------+-------------------------------------------+
To perform a timing constraint check, use the switch –-check_constraints with
the quartus_tan executable. The following Tcl command performs a timing
constraint check on both setup and hold on the design system:
quartus_tan block1 --check_constraints=both
Latch Analysis
Latches are implemented in the Quartus II software as look-up-tables (LUTs) feeding
back onto themselves. The Classic Timing Analyzer can analyze these latches as
synchronous elements rather than as combinational elements. The clock enables are
analyzed as inverted clocks. The Classic Timing Analyzer reports the results of setup
and hold analysis on these latches.
You can turn on the Analyze Latches As Synchronous Elements option with the
following Tcl command:
set_global_assignment -name ANALYZE_LATCHES_AS_SYNCHRONOUS_ELEMENTS ON
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 10: Quartus II Classic Timing Analyzer
Timing Analysis Using the Quartus II GUI
10–35
Timing Analysis Using the Quartus II GUI
In addition to the extensive scripting support available in the Classic Timing
Analyzer, the Quartus II software provides the Assignment Editor and other user
interface tools, giving you access to the Classic Timing Analyzer features and
assignments.
Assignment Editor
The Assignment Editor is a spreadsheet-style interface used for adding, modifying,
and deleting timing assignments.
To make timing assignments in the Assignment Editor, choose Timing from the
category list to cause the Assignment Name column to display only timing
assignments. Double-click <<new>> in the Assignment Name field, the Assignment
Name list displays. Figure 10–24 shows the Assignment Editor with the Assignment
Name list displaying timing assignment types.
Figure 10–24. Assignment Editor
f
© July 2010
For more information about the Assignment Editor, refer to the Assignment Editor
chapter in volume 2 of the Quartus II Handbook.
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
10–36
Chapter 10: Quartus II Classic Timing Analyzer
Timing Analysis Using the Quartus II GUI
Timing Settings
You can specify delay requirements and clock settings with the Timing Analysis
Settings page of the Settings dialog box.
To access this page, on the Assignments menu, click Settings. In the Category list,
expand Timing Analysis Settings. (Ensure that the Use Classic Timing Analyzer
during compilation radio button is turned on.) Select Classic Timing Analyzer
Settings. The Classic Timing Analysis Settings page appears.
Clock Settings Dialog Box
You can create or modify base clock settings or derived clock settings using the Clock
Settings dialog box. To access this page, on the Assignments menu, click Settings. In
the Category list, expand Timing Analysis Settings. (Ensure that the Use Classic
Timing Analyzer during compilation radio button is turned on.) Click Classic
Timing Analyzer Settings. The Timing Analysis Settings page displays. Under
Clock Settings, click Individual Clocks. The Individual Clock dialog box appears.
Click the New button in the Individual Clocks dialog box to access the New Clock
Settings dialog box and create a base or derived clock setting.
More Timing Settings Dialog Box
On the Timing Analysis Settings page of the Settings dialog box, click More Settings
to display the More Timing Settings dialog box. The More Timing Settings dialog
box provides access to many global timing analysis options.
Timing Reports
The Classic Timing Analyzer report is a section of the Compilation Report containing
the static timing analysis results. The Classic Timing Analyzer report includes clock
setup and clock hold measurements for all clock sources. The report also shows tCO for
all output pins, tSU and tH for all input pins, and tPD for any pin-to-pin combinational
paths in the design. Other reports are created for different analyses and device
features.
In the Settings dialog box, you can specify the range of information to be reported in
the timing analysis of the Compilation Report. To access this page, on the
Assignments menu, click Settings. In the Category list, expand Timing Analysis
Settings. (Ensure that the Use Classic Timing Analyzer during compilation radio
button is turned on.) Expand the Classic Timing Analyzer Settings list. Click Classic
Timing Analyzer Reporting. The Classic Timing Analyzer Reporting dialog box
appears.
If there are no timing assignments for the design, the Classic Timing Analyzer does
not generate slack reports for any detected clock nodes. The Classic Timing Analyzer
only reports slack measurements for pins with individual or global tSU, tH, or tCO
assignments. A positive slack indicates the margin by which the path surpasses the
clock timing requirements. A negative slack indicates the margin by which the path
fails the clock timing requirements.
1
This Timing Analysis report is also available in text format located in the design
directory with the file name <revision name>.tan.rpt.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 10: Quartus II Classic Timing Analyzer
Timing Analysis Using the Quartus II GUI
10–37
In the Compilation Report, select an analysis type under the timing analyzer folder to
display the analysis report; for example, Clock Setup or Clock Hold. Figure 10–25
shows an example of a Clock Setup report for clock signal clk.
Figure 10–25. Timing Analysis Report
Advanced List Path
The Advanced List Paths dialog box provides detailed information about a specific
path, such as interconnect and cell delays between any two valid register-to-register
paths (Figure 10–26).
The Advanced List Paths dialog box allows you to select the type of paths you want
listed. For example, you can obtain detailed information for Clock Setup and Clock
Hold for a specific clock. In addition, the Tcl command field in the window matches
the equivalent Tcl command you can use in either a custom Tcl script or in the Tcl
console.
Figure 10–26. Advanced List Paths Dialog Box
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
10–38
Chapter 10: Quartus II Classic Timing Analyzer
Timing Analysis Using the Quartus II GUI
You can perform a list path command directly from the Timing Analysis report. To do
this, right click a path and click List Path (Figure 10–27). To launch the Advanced List
Paths dialog box, right-click a path and in the menu that appears, and select
Advanced List Paths.
The Advanced List Paths dialog box displays only paths that are visible in the Timing
Analysis report. To increase the amount of paths reported by the Classic Timing
Analyzer, on the Assignments menu, click Timing Analysis Settings. In the Category
list, expand Timing Analysis Settings and select Timing Analyzer Reporting. In the
Timing Analyzer Reporting page, specify the range of information to be reported by
the Classic Timing Analyzer.
1
Both the Advanced List Paths and the List Path commands display the path
information in the System message window.
Figure 10–27. List Path in the Message Window
1
If the Combined Fast/Slow Timing option is enabled, the List Path Tcl command
displays only path delays reported in the Slow Model section.
Early Timing Estimate
To start an Early Timing Estimate, on the Processing menu, point to Start and click
Start Early Timing Estimate. To specify the Early Timing Estimate mode, on the
Assignments menu, click Settings. In the Category list, select Compilation Processes
Settings, select Early Timing Estimate and click the desired timing estimate mode.
For more information about the Early Timing Estimate feature, refer to “Early Timing
Estimation” on page 10–33.
Assignment Groups
To define, modify, and delete assignment groups, also known as time groups, from a
single dialog box, on the Assignments menu, click Assignment (Time) Groups. The
Assignment Groups dialog box appears.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 10: Quartus II Classic Timing Analyzer
Scripting Support
10–39
Scripting Support
You can run procedures and make settings described in this chapter in a Tcl script.
You can also run some procedures at a command prompt. For detailed information
about scripting command options, refer to the Quartus II Command-Line and Tcl API
Help browser. To run the Help browser, type the following command at the command
prompt:
quartus_sh --qhelp
f
For more information about Tcl scripting, refer to the Tcl Scripting chapter in volume 2
of the Quartus II Handbook.
f
For more information about command-line scripting, refer to the Command-Line
Scripting chapter in volume 2 of the Quartus II Handbook.
Creating Clocks
There are two Tcl commands that allow you to define clocks in a design,
create_base clock and create_relative_clock.
Base Clocks
Use the create_base_clock Tcl command to define a base clock:
create_base_clock [-h | -help] [-long_help] -fmax <fmax> \
[-duty_cycle <integer>] [-virtual] [-target <name>] [-no_target] \
[-entity <entity>] [-disable] [-comment <comment>] <clock_name>
To define a base clock setting named sys_clk with a 100 MHz requirement applied
to node clk_src, enter the following Tcl command:
create_base_clock –fmax 100MHz –target clk_src sys_clk
Derived Clocks
Use the create_relative_clock Tcl command to define a relative clock:
create_relative_clock [-h | -help] [-long_help] \
-base_clock <Base clock> [-duty_cycle <integer>] \
[-multiply <integer>] [-divide <integer>] [-offset <offset>] \
[-phase_shift <integer>] [-invert] [-virtual] [-target <name>] \
[-no_target] [-entity <entity>] [-disable] \
[-comment <comment>] <clock_name>
To define a relative clock named aux_clk based upon base clock setting sys_clk
with a multiplication factor of 2 applied to node rel_clk, enter the following Tcl
command:
create_relative_clock –base_clock sys_clk –multiply 2 \
–target rel_clk aux_clk
Clock Latency
You can use the set_clock_latency Tcl command to create either an early or late
clock latency assignment:
set_clock_latency [-h | -help] [-long_help] [-early] [-late] \
-to <to> [<value>]
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
10–40
Chapter 10: Quartus II Classic Timing Analyzer
Scripting Support
To apply an early clock latency of 1 ns and a late clock latency of 2 ns to clock node
clk, enter the following Tcl commands:
set_clock_latency -early -to clk 2ns
Clock Uncertainty
You can use the set_clock_uncertainty Tcl command to create clock uncertainty
assignments as shown in the following example:
set_clock_uncertainty [-h] [-help] [-long_help [-from \
<source clock name> ] -to <destination clock name> [-setup] [-hold] \
[-remove] [-disable] [-comment <comment>] <value>
To apply a clock setup uncertainty of 50 ps between source clock node clk_src and
destination clock node clk_dst, enter the following Tcl command:
set_clock_uncertainty –from clk_src –to clk_dst –setup 50ps
To apply a clock hold uncertainty of 25 ps between to clock node clk_sys, enter the
following Tcl command:
set_clock_uncertainty –to clk_sys –setup 25ps
Cut Timing Paths
You can use the set_timing_cut_assignment Tcl command to create cut timing
assignments:
set_timing_cut_assignment [-h | -help] [-long_help] \
[-from <from_node_list>] [-to <to_node_list>] [-remove] [-disable] \
[-comment <comment>]
To cut the timing path from source register reg1 to destination register reg2, enter
the following Tcl command:
set_timing_cut_assignment -from reg1 -to reg2
Input Delay Assignment
You can use the Tcl command set_input_delay to create input delay assignments:
set_input_delay [-h | -help] [-long_help] [-clk_ref <clock>] \
-to <input_pin> [-min] [-max] [-clock_fall] [-remove] [-disable] \
[-comment <comment>] [<value>]
To apply an input maximum delay of 2 ns to an input pin named data_in that feeds
a register clocked by clock source clk, enter the following Tcl command:
set_input_delay -clk_ref clk -to data_in –max 2ns
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 10: Quartus II Classic Timing Analyzer
Scripting Support
10–41
Maximum and Minimum Delay
The following Tcl commands create the Maximum Delay and Minimum
Relationship assignments, respectively:
set_instance_assignment -name MAX_delay <value> -from <node> -to <node>
set_instance_assignment -name MIN_delay <value> -from <node> -to <node>
To apply a maximum delay of 8 ns and a minimum of 5 ns between source register
reg1 and destination register reg2, enter the following Tcl command:
set_instance_assignment -name MAX_DELAY 8ns -from reg1 -to reg2
set_instance_assignment -name MIN_DELAY 5ns -from reg1 -to reg2
To apply a maximum delay of 10 ns for all paths from source clock clk_src to
destination clock clk_dst, enter the following Tcl command:
set_instance_assignment -name MAX_DELAY 10ns -from clk_src -to clk_dst
Maximum Clock Arrival Skew
The following Tcl command defines the Maximum Clock Arrival Skew assignment:
set_instance_assignment -name max_clock_arrival_skew <value> \
-from <clock> -to <node>
To apply a maximum clock arrival skew of 1 ns for clock source clk to a predefined
timegroup called reg_group, enter the following Tcl command:
set_instance_assignment -name max_clock_arrival_skew 1ns -from clk \
-to reg_group
Maximum Data Arrival Skew
To create Maximum Data Arrival Skew assignments, use the Tcl command
set_instance_assignment -name max_data_arrival:
set_instance_assignment -name max_data_arrival_skew <value> \
-from <clock> -to <node>
To apply a maximum data arrival skew of 1 ns for clock source clk to a predefined
timegroup of pins called pin_group, enter the following Tcl command:
set_instance_assignment -name max_data_arrival_skew 1ns -from clk \
-to pin_group
Multicycle
Use the set_multicycle_assignment Tcl command to create Multicycle
assignments:
set_multicycle_assignment [-h | -help] [-long_help] [-setup] [-hold] \
[-start] [-end] [-from <from_list>] [-to <to_list>] [-remove] \
[-disable] [-comment <comment>] <path_multiplier>
To apply a multicycle setup of 2 and a hold multicycle of 1 between source register
reg1 and destination register reg2, enter the following Tcl commands:
set_multicycle_assignment –setup -end –from reg1 –to reg2 2
set_multicycle_assignment –hold -end –from reg1 –to reg2 1
To apply a Source Multicycle Setup of 2 between source register reg1 and destination
register reg2, enter the following Tcl command:
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
10–42
Chapter 10: Quartus II Classic Timing Analyzer
Scripting Support
set_multicycle_assignment –setup -start –from reg1 –to reg2 1
To apply a multicycle setup of 2 for all paths from source clock clk_src to
destination clock clk_dst, enter the following Tcl command:
set_multicycle_assignment –setup –end –from clk_src –to clk_dst 2
Output Delay Assignment
Use the Tcl command set_output_delay to create Output Delay assignments:
set_output_delay [-h | -help] [-long_help] [-clk_ref <clock>] \
-to <output_pin> [-min] [-max] [-clock_fall] [-remove] [-disable] \
[-comment <comment>] [<value>]
To apply an output maximum delay of 3 ns to an output pin named data_out that is
fed to a register clocked by clock source clk, enter the following Tcl command:
set_output_delay -clk_ref clk -to data_out –max 3ns
Report Timing
Use the report_timing Tcl command to generate timing reports:
report_timing [-h | -help] [-long_help] [-npaths <number>] [-tsu] \
[-th] [-tco] [-tpd] [-min_tco] [-min_tpd] [-clock_setup] \
[-clock_hold] [-clock_setup_io] [-clock_hold_io] [-clock_setup_core] \
[-clock_hold_core] [-recovery] [-removal] [-dqs_read_capture] \
[-stdout] [-file <name>] [-append] [-table <name>] [-from <names>] \
[-to <names>] [-clock_filter <names>] [-src_clock_filter <names>] \
[-longest_paths] [-shortest_paths] [-all_failures]
The following example generates a list of all clock setup paths for clock source clk
from registers src_reg* to registers dst_reg*:
report_timing -clock_setup -clock_filter clk -from src_reg* \
-to dst_reg*
Setup and Hold Relationships
The following Tcl commands create Setup Relationship and Hold Relationship
assignments, respectively:
set_instance_assignment -name SETUP_RELATIONSHIP <value> -from <node> \
-to <node>
set_instance_assignment -name HOLD_RELATIONSHIP <value> -from <node> \
-to <node>
To apply a setup relationship of 12 ns and a hold relationship of 2 ns between source
register reg1 and destination registers reg2, enter the following Tcl command:
set_instance_assignment -name SETUP_RELATIONSHIP 12ns -from reg1 \
-to reg2
set_instance_assignment -name HOLD_RELATIONSHIP 2ns -from reg1 -to reg2
To apply a setup relationship of 10 ns for all paths from source clock clk_src to
destination clock clk_dst, enter the following Tcl command:
set_instance_assignment -name SETUP_RELATIONSHIP 10ns -from clk_src \
-to clk_dst
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 10: Quartus II Classic Timing Analyzer
MAX+PLUS II Timing Analysis Methodology
10–43
Assignment Group
Use the timegroup Tcl command to create assignment groups:
timegroup [-h | -help] [-long_help] [-add_member <name>] \
[-add_exception <name>] [-remove_member <name>] [-remove_exception \
<name>] [-get_members] [-get_exceptions] [-overwrite] [-remove] \
[-disable] [-comment <comment>] <group_name>
The following example creates an assignment group called reg_bank with members
dst_reg*, and excludes register dst_reg5.
timegroup reg_bank -add_member dst_reg* -add_exception dst_reg5
Virtual Clock
Use the create_relative_clock with the –virtual switch to create Virtual
Clock assignments:
create_relative_clock [-h | -help] [-long_help] -base_clock \
<Base clock> [-duty_cycle <integer>] [-multiply <integer>] \
[-divide <integer>] [-offset <offset>] [-phase_shift <integer>] \
[-invert] [-virtual] [-target <name>] [-no_target] [-entity <entity>] \
[-disable] [-comment <comment>] <clock_name>
To define a virtual clock derived from the base clock setting clk_aux named
brd_sys, enter the following Tcl command:
create_relative_clock –base_clock clk_aux -virtual brd_sys
MAX+PLUS II Timing Analysis Methodology
This section describes the basic static timing analysis and assignments available in the
Quartus II software that originated in the MAX+PLUS® II design software.
fMAX Relationships
Maximum clock frequency is the fastest speed at which the design clock can run
without violating internal setup and hold time requirements. The Quartus II software
performs static timing analysis on both single- and multiple-clock designs.
1
Apply clock settings to all clock nodes in a design to ensure that you meet all
performance requirements. Refer to “Clock Settings” on page 10–8 for more
information.
Slack
Slack is the margin by which a timing requirement such as fMAX 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 Quartus II software
determines slack using Equation 10–35 through Equation 10–38.
Equation 10–35.
Clock Setup Slack = Longest Register-to-Register Requirement – Longest Register-to-Register Delay
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
10–44
Chapter 10: Quartus II Classic Timing Analyzer
MAX+PLUS II Timing Analysis Methodology
Equation 10–36.
Register-to-Register Requirement = Setup Relationship + Largest Clock Skew –
micro t co of Source Register – micro t su of Destination Register
Equation 10–37.
Clock Hold Slack = Shortest Register-to-Register Delay – Smallest Register-to-Register Requirement
Equation 10–38.
Shortest Register-to-Register Requirement = Hold Relationship + Smallest Clock Skew –
micro t co of Source Register – micro t H of Destination Register
Figure 10–28 shows a slack calculation diagram.
Figure 10–28. Slack Calculation Diagram
Slack
Clock Period
Launching Edge
clk1
clk2
Latching Edge
Register 2
Register 1
tCO
Logic
tSU
Data
clk1
clk2
Point to Point Delay
I/O Timing
This section describes the basic measurements made for I/O timing in the Quartus II
software.
tSU Timing
tSU specifies the length of time data needs to arrive and be stable at an external input
pin prior to a clock transition on an associated clock I/O pin. A tSU requirement
describes this relationship for an input register relative to the I/O pins of the FPGA.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 10: Quartus II Classic Timing Analyzer
MAX+PLUS II Timing Analysis Methodology
10–45
Figure 10–29 shows a diagram of clock setup time.
Figure 10–29. Clock Setup Time (tSU)
Data Delay
Micro tSU
data
tSU
clk
Clock Delay
Micro tSU is the internal setup time of the register. It is a characteristic of the register
and is unaffected by the signals feeding the register. Equation 10–39 calculates the tSU
of data with respect to clk for the circuit shown in Figure 10–29.
Equation 10–39.
t su = Longest Data Delay – Shortest Clock Delay + micro t su of Input Register
tH Timing
tH specifies the length of time data needs to be held stable on an external input pin
after a clock transition on an associated clock I/O pin. A tH requirement describes this
relationship for an input register relative to the I/O pins of the FPGA. Figure 10–30
shows a diagram of clock hold time.
Figure 10–30. Clock Hold Time (tH)
Data Delay
Micro tH
data
tH
clk
Clock Delay
Micro tH is the internal hold time of the register. Equation 10–40 calculates the tH of
data with respect to clk for the circuit shown in Figure 10–30.
Equation 10–40.
t H = Longest Clock Delay – Shortest Data Delay + micro t H of Input Register
tCO Timing
Clock-to-output delay is the maximum time required to obtain a valid output at an
output pin fed by a register, after a clock transition on the input pin that clocks the
register. Micro tCO is the internal clock-to-output delay of the register.
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
10–46
Chapter 10: Quartus II Classic Timing Analyzer
MAX+PLUS II Timing Analysis Methodology
Figure 10–31 shows a diagram of clock-to-output delay.
Figure 10–31. Clock-to-Output Delay (tCO)
Data Delay
Micro tCO
data_out
tCO
clk
Clock Delay
Equation 10–41 calculates the tCO for output pin data_out with respect to clock node
clk for the circuit shown in Figure 10–31.
Equation 10–41.
t co = Longest Clock Delay + micro t co of Output Register
Minimum tCO (min tCO)
Minimum clock-to-output delay is the minimum time required to obtain a valid
output at an output pin fed by a register, after a clock transition on the input pin that
clocks the register. Micro tCO is the internal clock-to-output delay of registers in Altera
FPGAs. Unlike the tCO assignment, the min tCO assignment looks at the shortest delay
paths (refer to Equation 10–42).
Equation 10–42.
min t co = Shortest Clock Delay + Shortest Data Delay + micro t co of Output Register
tPD Timing
Pin-to-pin delay (tPD) is the time required for a signal from an input pin to propagate
through combinational logic and appear at an external output pin (refer to
Equation 10–43).
Equation 10–43.
t PD = Longest Pin-to-Pin Delay
1
In the Quartus II software, you can make tPD assignments between an input pin and an
output pin.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 10: Quartus II Classic Timing Analyzer
Conclusion
10–47
Minimum tPD (min tPD)
The minimum pin-to-pin delay (tPD) is the time required for a signal from an input pin
to propagate through combinational logic and appear at an external output pin.
Unlike the tPD assignment, the min tPD assignment applies to the shortest pin-to-pin
delay (refer to Equation 10–44).
Equation 10–44.
min t PD = Shortest Pin-to-Pin Delay
Conclusion
Static timing analysis is important to help you verify design timing requirements.
Without full design constraints and a complete static timing analysis, you risk circuit
failure in complex designs. The Classic Timing Analyzer provides legacy static timing
analysis features to analyze your design.
1
For more advanced constraints and analysis capabilities, Altera recommends that you
switch to the TimeQuest Timing Analyzer.
Document Revision History
Table 10–2 shows the revision history for this chapter.
Table 10–2. Document Revision History
Date
Version
July 2010
10.0.0
November 2009
9.1.0
Changes Made
■
Updated “PLL Clocks” on page 10–10.
■
Updated “Early Timing Estimation” on page 10–33.
■
Removed The Timing Analyzer Tool.
■
This was chapter 11 in the Quartus II 9.1 software release.
■
Updated the “Introduction” section.
■
Updated “Timing Analysis Tool Setup” on page 10–2.
March 2009
9.0.0
■
This was chapter 9 in version 8.1.
November 2008
8.1.0
■
Changed to 8-1/2 x 11 page size. No change to content.
May 2008
8.0.0
■
Added hyperlinks to referenced documents throughout the chapter.
No other substantive changes were made.
© July 2010
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.
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
10–48
Quartus II Handbook Version 10.0 Volume 3: Verification
Chapter 10: Quartus II Classic Timing Analyzer
Document Revision History
© July 2010 Altera Corporation
11. Synopsys PrimeTime Support
QII53005-10.0.0
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 11–1 shows the PrimeTime flow diagram.
Figure 11–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 11–2
■
“Running the PrimeTime Software” on page 11–7
■
“PrimeTime Timing Reports” on page 11–8
■
“Static Timing Analyzer Differences” on page 11–17
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.
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
11–2
Chapter 11: 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.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 11: Synopsys PrimeTime Support
Files Generated for the PrimeTime Software Environment
11–3
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:
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>
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
11–4
Chapter 11: Synopsys PrimeTime Support
Files Generated for the PrimeTime Software Environment
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>
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.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 11: Synopsys PrimeTime Support
Files Generated for the PrimeTime Software Environment
11–5
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.
1
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 11–1 shows the search_path and link_path variables defined in the Tcl
script:
Example 11–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 11–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 11–1. Equivalent Quartus II and PrimeTime Software Constraints
Quartus II Equivalent
Clock defined on input pin, clock of 10 ns
period and 50% duty cycle
PrimeTime Constraint
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]
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
11–6
Chapter 11: Synopsys PrimeTime Support
Files Generated for the PrimeTime Software Environment
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.
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 11–2 shows the files that are generated for the PrimeTime software when the
Classic Timing Analyzer is selected.
Table 11–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 11–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 11–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.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 11: Synopsys PrimeTime Support
Running the PrimeTime Software
11–7
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.
3. Modify the Quartus II path in Tcl scripts to point to the PrimeTime libraries using
the first line of Example 11–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
© July 2010
You can also run pt_shell without a script file by typing pt_shellr at the UNIX
command line prompt.
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
11–8
Chapter 11: Synopsys PrimeTime Support
PrimeTime Timing Reports
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.
The PrimeTime software timing report is similar to the sample shown in
Example 11–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 11–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.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 11: Synopsys PrimeTime Support
PrimeTime Timing Reports
11–9
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 11–9
■
“Clock Hold Relationship and Slack” on page 11–12
■
“Input Delay and Output Delay Relationships and Slack” on page 11–15
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 11–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 11–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 11–2:
Equation 11–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 11–3.
Largest Register-to-Register Requirement =
Setup Relationship between Source and Destination + Largest Clock Skew –
Micro tco 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
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
11–10
Chapter 11: Synopsys PrimeTime Support
PrimeTime Timing Reports
Figure 11–2 shows a simple three-register design.
Figure 11–2. Simple Three-Register Design
The Classic Timing Analyzer generates a report for the design, as shown in
Figure 11–3.
Figure 11–3. Timing Analyzer Report from Figure 11–2
Equation 11–1, Equation 11–2, and Equation 11–3 are similar to those found in other
static timing analysis tools, such as the PrimeTime software. Equation 11–4 through
Equation 11–7, used by the PrimeTime software, are essentially the same as those used
by the Classic Timing Analyzer, but they are rearranged.
Equation 11–4.
Slack = Data Required – Data Arrival
Equation 11–5.
Clock Arrival = Latch Edge + Shortest Clock Path to Destination
Equation 11–6.
Data Required = Clock Arrival – Micro t su
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 11: Synopsys PrimeTime Support
PrimeTime Timing Reports
11–11
Equation 11–7.
Data Arrival = Launch Edge + Longest Clock Path to Source + Micro t co + Longest Data Delay
1
The longest data delay in the previous equation is equal to
register-to-register data delay.
Figure 11–4 shows a clock setup check in the Quartus II software.
Figure 11–4. Clock Setup Check Reporting with the Classic Timing Analyzer
The results in Equation 11–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 11–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
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
11–12
Chapter 11: 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 11–3:
Example 11–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 11–9:
Equation 11–9.
Data Arrival – Clock Arrival  t H
The Classic Timing Analyzer determines the clock hold slack with Equation 11–10,
Equation 11–11, Equation 11–12, and Equation 11–13:
Equation 11–10.
Clock Hold Slack = Shortest Register-to-Register Delay – Smallest Register-to-Register Requirement
Equation 11–11.
Smallest Register-to-Register Requirement = Hold Relationship between Source & Destination +
Smallest Clock Skew – Micro tsu of Source + Micro t H of Destination
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 11: Synopsys PrimeTime Support
PrimeTime Timing Reports
11–13
Equation 11–12.
Hold Relationship between Source & Destination = Latch Edge – Launch Edge
Equation 11–13.
Smallest Clock Skew = Longest Clock Path from Clock to Destination Register –
Shortest Clock Path from Clock to Source Register
Figure 11–5 shows a simple three-register design.
Figure 11–5. Simple Three-Register Design
The Classic Timing Analyzer generates a report as shown in Figure 11–6.
Figure 11–6. Timing Analyzer Report Generated from the Three-Register Design
The previous equations are similar to those found in the Quartus II software.
Equation 11–14 through Equation 11–17 are the same equations that are used by the
PrimeTime software, but they are rearranged.
Equation 11–14.
Slack = Data Required – Data Arrival
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
11–14
Chapter 11: Synopsys PrimeTime Support
PrimeTime Timing Reports
Equation 11–15.
Clock Arrival = Latch Edge + Longest Clock Path to Destination
Equation 11–16.
Data Required = Clock Arrival – Micro t H
Equation 11–17.
Data Arrival = Launch Edge + Longest Clock Path to Source + Micro t co + Shortest Data Delay
1
The shortest register-to-register delay in the previous equation is equal to
register-to-register data delay.
Figure 11–7 shows a clock setup check with the Classic Timing Analyzer.
Figure 11–7. Clock Hold Check Reporting with the Classic Timing Analyzer
The results in Equation 11–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 11–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 tco 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
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 11: Synopsys PrimeTime Support
PrimeTime Timing Reports
11–15
For the same register-to-register path, the PrimeTime software generates the report
shown in Example 11–4:
Example 11–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 11–8 shows the
input delay and output delay report for the design shown in Figure 11–5 on
page 11–13.
Figure 11–8. Input and Output Delay Reporting with the Classic Timing Analyzer
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
11–16
Chapter 11: Synopsys PrimeTime Support
PrimeTime Timing Reports
Figure 11–9 shows the fully expanded view for the output delay path.
Figure 11–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 11–5:
Example 11–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
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 11: Synopsys PrimeTime Support
Static Timing Analyzer Differences
11–17
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.)
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
11–18
Chapter 11: Synopsys PrimeTime Support
Static Timing Analyzer Differences
Registered Clock Signals
Registered clock signals are clock signals that pass through a register before reaching
the clock port of a sequential element. Figure 11–10 shows an example of a registered
clock signal.
Figure 11–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 11–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 11–11 shows a
sample design that contains multiple path pairs between the source register and
destination register.
Figure 11–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 11–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.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 11: Synopsys PrimeTime Support
Static Timing Analyzer Differences
1
11–19
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.)
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
11–20
Chapter 11: Synopsys PrimeTime Support
Static Timing Analyzer Differences
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.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 11: Synopsys PrimeTime Support
Conclusion
11–21
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 11–4 shows the revision history for this chapter.
Table 11–4. Document Revision History
Date
© July 2010
Version
Changes Made
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 chapter.
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
11–22
Quartus II Handbook Version 10.0 Volume 3: Verification
Chapter 11: Synopsys PrimeTime Support
Document Revision History
© July 2010 Altera Corporation
Section III. Power Estimation and
Analysis
As FPGA designs grow larger and processes continue to shrink, power is an everincreasing concern. When designing a PCB, the power consumed by a device must be
accurately estimated to develop an appropriate power budget, and to design the
power supplies, voltage regulators, heat sink, and cooling system.
The Quartus® II software allows you to estimate the power consumed by your current
design during timing simulation. The power consumption of your design can be
calculated using the Microsoft Excel-based power calculator, or the Simulation-Based
Power Estimation features in the Quartus II software. This section explains how to use
both.
This section includes the following chapter:
■
Chapter 12, PowerPlay Power Analysis
This chapter describes the Altera® Quartus II PowerPlay power analysis tool and
how to use the tools to accurately estimate device power consumption.
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
III–2
Quartus II Handbook Version 10.0 Volume 3: Verification
Section III: Power Estimation and Analysis
© July 2010 Altera Corporation
12. PowerPlay Power Analysis
QII53013-10.0.0
This chapter describes how to use the Altera® Quartus® II PowerPlay Power Analysis
tools to accurately estimate device power consumption.
As designs grow larger and process technology continues to shrink, power becomes
an increasingly important design consideration. When designing a PCB, the power
consumed by a device must be accurately estimated to develop an appropriate power
budget and to design the power supplies, voltage regulators, heat sink, and cooling
system. As shown in Figure 12–1, the PowerPlay Power Analysis tools provide the
ability to estimate power consumption from early design concept through design
implementation.
Figure 12–1. PowerPlay Power Analysis
Higher
Estimation Accuracy
PowerPlay EPE
Quartus II PowerPlay Power Analyzer
Placement and
Routing
Results
User Input
Quartus II
Design Profile
Design Implementation
Design Concept
Lower
Simulation
Results
PowerPlay Power Analysis Input
Higher
f
For more information about the PowerPlay suite of power analysis and optimizations
tools, refer to About Power Estimation and Analysis in Quartus II Help.
f
For more information about acquiring the PowerPlay EPE spreadsheet, refer to
PowerPlay Early Power Estimators (EPE) and Power Analyzer on the Altera website.
This chapter discusses the following topics:
© July 2010
■
“Creating PowerPlay EPE Spreadsheets”
■
“Types of Power Analysis” on page 12–4
■
“Factors Affecting Power Consumption” on page 12–4
■
“PowerPlay Power Analyzer Flow” on page 12–7
■
“Using Simulation Files in Modular Design Flows” on page 12–10
■
“Using the PowerPlay Power Analyzer” on page 12–17
■
“Conclusion” on page 12–27
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
12–2
Chapter 12: PowerPlay Power Analysis
Creating PowerPlay EPE Spreadsheets
Creating PowerPlay EPE Spreadsheets
You can use PowerPlay EPE spreadsheets to perform a preliminary thermal analysis
and power consumption estimate for your design. You can either enter the data
manually or use the tools in the Quartus II software to assist you with generating the
device resources usage information for your design.
f
For more information about generating a PowerPlay EPE File in the Quartus II
software, refer to Performing an Early Power Estimate Using the PowerPlay Early Power
Estimator in Quartus II Help.
Figure 12–2 shows an example of the contents of a PowerPlay EPE File generated for a
design that targets a Stratix III device.
Figure 12–2. Example of a PowerPlay EPE File
The PowerPlay EPE spreadsheet includes the Import Data macro that parses the
information in the PowerPlay EPE File and transfers it into the spreadsheet. If you do
not want to use the macro, you can manually transfer the data into the PowerPlay EPE
spreadsheet.
For example, after importing the PowerPlay EPE File information into the PowerPlay
EPE spreadsheet, you can add additional device resource information at any time. If
the existing Quartus II project represents only a portion of your full design, you must
enter the additional device resources used in the final design manually.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 12: PowerPlay Power Analysis
Creating PowerPlay EPE Spreadsheets
12–3
PowerPlay EPE File Generator Compilation Report
After successfully generating the PowerPlay EPE File, you can locate a PowerPlay
EPE File Generator report under the Compilation Report section. This report contains
different sections, such as Summary, Settings, Generated Files, Confidence Metric
Details, and Signal Activities. For more information about the PowerPlay EPE File
Generator report, refer to “PowerPlay Power Analyzer Compilation Report” on
page 12–23.
Table 12–1 lists the main differences between the PowerPlay EPE and the Quartus II
PowerPlay Power Analyzer.
Table 12–1. Comparison of the PowerPlay EPE and Quartus II PowerPlay Power Analyzer
Characteristic
PowerPlay EPE
Quartus II PowerPlay Power Analyzer
Phase in the design cycle
Any time
Post-fit
Tool requirements
Spreadsheet program or the Quartus II
software
The Quartus II software
Accuracy
Medium
Medium to very high
Data inputs
■
Resource usage estimates
■
Post-fit design
■
Clock requirements
■
Clock requirements
■
Environmental conditions
■
Signal activity defaults
■
Toggle rate
■
Environmental conditions
■
Register transfer level (RTL) simulation
results (optional)
■
Post-fit simulation results (optional)
■
Signal activities per node or entity
(optional)
Data outputs (1)
■
Total thermal power dissipation
■
Total thermal power
■
Thermal static power
■
Thermal static power
■
Thermal dynamic power
■
Thermal dynamic power
■
Off-chip power dissipation
■
Thermal I/O power
■
Current drawn from voltage supplies(2)
■
Thermal power by design hierarchy
■
Thermal power by block type
■
Thermal power dissipation by clock
domain
■
Off-chip (non-thermal) power dissipation
■
Device supply currents (2)
Notes to Table 12–1:
(1) The PowerPlay EPE output varies by device family as some features might not be available.
(2) Available only for Arria II GX, Cyclone III, Cyclone III LS, Cyclone IV GX, MAX II, Stratix III, Stratix IV series, and Stratix V device families.
The result of the PowerPlay Power Analyzer is only an estimation of power. Altera
does not recommend using the result as a specification. The purpose of the estimation
is to help you to establish a guide for the power budget of your design. Altera
recommends measuring the actual power on the board. You must measure the total
dynamic current of your design during device operation because the estimate is
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
12–4
Chapter 12: PowerPlay Power Analysis
Types of Power Analysis
design dependent and depends on many variable factors, including input vector
quantity, quality, and exact loading conditions of a PCB design. Static power
consumption must not be based on empirical observation. The values reported by the
PowerPlay Power Analyzer or data sheet must be used because the tested devices
might not exhibit worst-case behavior.
Types of Power Analysis
Understanding the uses of power analysis and the factors affecting power
consumption helps you to use the PowerPlay Power Analyzer effectively. Power
analysis meets two significant planning requirements:
■
Thermal planning—The cooling solution must be sufficient to dissipate the heat
generated by the device. The computed junction temperature must fall within
normal device specifications.
■
Power supply planning—Power supplies must provide adequate current to
support device operation.
The two types of analyses are closely related because much of the power supplied to
the device is dissipated as heat from the device; however, in some situations, the two
types of analyses are not identical. For example, if you are using terminated I/O
standards, some of the power drawn from the power supply of the device dissipates
in termination resistors rather than in the device.
Power analysis also addresses the activity of your design over time as a factor that
impacts the power consumption of the device. Static power is the power consumed
regardless of design activity. Dynamic power is the additional power consumed due
to signal activity or toggling.
1
For power supply planning, you can use the PowerPlay EPE at the early stages of
your design cycle, or use the PowerPlay Power Analyzer reports when your design is
complete to get an estimate of your design power requirement.
Factors Affecting Power Consumption
This section describes the factors affecting power consumption. Understanding these
factors allows you to use the PowerPlay Power Analyzer and interpret its results
effectively.
Device Selection
Different device families have different power characteristics. Many parameters affect
the device family power consumption, including choice of process technology, supply
voltage, electrical design, and device architecture. For example, the Cyclone II device
family architecture consumes less static power than the high-performance and
full-featured Stratix II device family.
Power consumption also varies in a single device family. A larger device consumes
more static power than a smaller device in the same family because of its larger
transistor count. Dynamic power can also increase with device size in devices that
employ global routing architectures, for example, the MAX device family. Cyclone,
Max II, and Stratix devices do not exhibit significantly increased dynamic power as
device size increases.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 12: PowerPlay Power Analysis
Factors Affecting Power Consumption
12–5
The choice of device package also affects the ability of the device to dissipate heat.
This choice can impact your cooling solution choice required to meet junction
temperature constraints.
Process variation can affect power consumption. Process variation primarily impacts
static power because sub-threshold leakage current varies exponentially with changes
in transistor threshold voltage. As a result, it is critical to consult device specifications
for static power and not rely on empirical observation. Process variation has a weak
effect on dynamic power.
Environmental Conditions
Operating temperature primarily affects device static power consumption. Higher
junction temperatures result in higher static power consumption. The device thermal
power and cooling solution that you use must result in the device junction
temperature remaining within the maximum operating range for the device. The main
environmental parameters affecting junction temperature are the cooling solution and
ambient temperature.
Airflow
Airflow is a measure of how quickly heated air is removed from the vicinity of the
device and replaced by air at ambient temperature. Airflow can either be specified as
“still air” when no fan is used, or as the linear feet per minute rating of the fan used in
the system. Higher airflow decreases thermal resistance.
Heat Sink and Thermal Compound
A heat sink allows more efficient heat transfer from the device to the surrounding area
because of its large surface area exposed to the air. The thermal compound that
interfaces the heat sink to the device also influences the rate of heat dissipation. The
case-to-ambient thermal resistance (CA) parameter describes the cooling capacity of
the heat sink and thermal compound employed at a given airflow. Larger heat sinks
and more effective thermal compounds reduce CA.
Junction Temperature
The junction temperature of a device is equal to:
TJunction = TAmbient + PThermal · JA
in which JA is the total thermal resistance from the device transistors to the
environment, having units of degrees Celsius per watt. The value JA is equal to the
sum of the junction-to-case (package) thermal resistance (JC) and the case-to-ambient
thermal resistance (CA) of your cooling solution.
Board Thermal Model
The thermal resistance of the path through the board is referred to as the
junction-to-board thermal resistance (JB), having units of degrees Celsius per watt. It
is used in conjunction with the board temperature, as well as the top-of-chip JA and
ambient temperatures, to compute junction temperature.
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
12–6
Chapter 12: PowerPlay Power Analysis
Factors Affecting Power Consumption
Device Resource Usage
The number and types of device resources used greatly affects power consumption.
Number, Type, and Loading of I/O Pins
Output pins drive off-chip components, resulting in high-load capacitance that leads
to a high-dynamic power per transition. Terminated I/O standards require external
resistors that generally draw constant (static) power from the output pin.
Number and Type of Logic Elements, Multiplier Elements, and RAM Blocks
A design with more logic elements (LEs), multiplier elements, and memory blocks
tends to consume more power than a design with fewer circuit elements. The
operating mode of each circuit element also affects its power consumption. For
example, a DSP block performing 18 × 18 multiplications and a DSP block performing
multiply-accumulate operations consume different amounts of dynamic power
because of different amounts of internal capacitance being charged on each
transition.The operating mode of a circuit element also affects static power.
Number and Type of Global Signals
Global signal networks span large portions of the device and have high capacitance,
resulting in significant dynamic power consumption. The type of global signal is
important as well. For example, Stratix II devices support several kinds of global clock
networks that span either the entire device or a specific portion of the device (a
regional clock network covers a quarter of the device). Clock networks that span
smaller regions have lower capacitance and tend to consume less power. The location
of the logic array blocks (LABs) driven by the clock network can also have an impact
because the Quartus II software automatically disables unused branches of a clock.
Signal Activities
The final important factor in estimating power consumption is the behavior of each
signal in your design. The two vital statistics are the toggle rate and the static
probability.
The toggle rate of a signal is the average number of times that the signal changes
value per unit of time. The units for toggle rate are transitions per second and a
transition is a change from 1 to 0, or 0 to 1.
The static probability of a signal is the fraction of time that the signal is logic 1 during
the period of device operation that is being analyzed. Static probability ranges from 0
(always at ground) to 1 (always at logic-high).
Dynamic power increases linearly with the toggle rate as the capacitive load is
charged more frequently for logic and routing. The Quartus II software models full
rail-to-rail switching. For high toggle rates, especially on circuit output I/O pins, the
circuit can transition before fully charging the downstream capacitance. The result is a
slightly conservative prediction of power by the PowerPlay Power Analyzer.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 12: PowerPlay Power Analysis
PowerPlay Power Analyzer Flow
12–7
The static power consumed by both routing and logic can sometimes be affected by
the static probabilities of their input signals. This effect is due to state-dependent
leakage and has a larger effect on smaller process geometries. The Quartus II software
models this effect on devices at 90 nm (or smaller) if it is important to the power
estimate. The static power also varies with the static probability of a logic 1 or 0 on the
I/O pin when output I/O standards drive termination resistors.
1
To get accurate results from the power analysis, the signal activities for analysis must
represent the actual operating behavior of your design. Inaccurate signal toggle rate
data is the largest source of power estimation error.
PowerPlay Power Analyzer Flow
The PowerPlay Power Analyzer supports accurate power estimations by allowing
you to specify all the important design factors affecting power consumption.
Figure 12–3 shows the high-level PowerPlay Power Analyzer flow.
Figure 12–3. PowerPlay Power Analyzer High-Level Flow
User Design
(Post-Fit)
Operating
Conditions (1)
PowerPlay
Power Analyzer
Signal
Activities
Power Analysis
Report
Note to Figure 12–3:
(1) Operating condition specifications are available only for Arria II GX, Arria GX, Cyclone II, Cyclone III series,
Cyclone IV series, HardCopy series, MAX II, Stratix II, Stratix II GX, Stratix III, Stratix IV, and Stratix V device
families.
The PowerPlay Power Analyzer requires your design to be synthesized and fitted to
the target device. You must specify the electrical standard used by each I/O cell and
the capacitive load on each I/O standard in your design to obtain accurate I/O power
estimates.
Operating Conditions
For Arria II GX, Arria GX, Cyclone II, Cyclone III series, Cyclone IV series, HardCopy
series, MAX II, Stratix II, Stratix II GX, Stratix III, Stratix IV, and Stratix V device
families, you can specify the operating settings and conditions for power analysis in
the Quartus II software.
The following settings are available when you click Operating Settings and
Conditions in the Settings dialog box:
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
12–8
Chapter 12: PowerPlay Power Analysis
PowerPlay Power Analyzer Flow
■
Device power characteristics—You can specify that the device has typical power
consumption characteristics or maximum power consumption characteristics.
f
For more information, refer to Operating Setting and Conditions Page
(Settings Dialog Box) in Quartus II Help.
■
Selectable Core Voltage—You can select a suitable core supply voltage for your
design based on performance and power requirements using the Core Supply
Voltage option, available for Stratix III devices with variable voltage support. The
power consumption of a device is heavily dependent on voltage, so it is very
important to choose the right core supply voltage for your design. The core supply
voltage provides power to device logic resources such as LABs, memory logic
array blocks (MLABs), DSP functions, memory, and interconnects.
■
Environmental conditions and junction temperature—The PowerPlay Power
Analyzer automatically computes the junction temperature based on the specified
ambient temperature and the cooling solution that you selected. For a more
accurate analysis, enter the thermal resistance of your cooling solution. For some
cooling solutions, such as a heat sink with no forced airflow, the thermal resistance
varies with the amount of thermal power that is dissipated. Air convection
increases as the difference between the device temperature and the ambient
temperature increases, reducing thermal resistance. If you are entering a thermal
resistance in such cases, it is important to use the thermal resistance that occurs
when the heat flow (Q) is equal to the thermal power generated by the device.
1
■
You can also specify a junction temperature in the PowerPlay Power
Analyzer. However, Altera does not recommend it because the PowerPlay
Power Analyzer provides more accurate results by computing the junction
temperature.
Board Thermal Modeling—If you want the PowerPlay Power Analyzer thermal
model to take the JB into consideration, set the board thermal model to either
Typical or Custom. This feature produces more accurate thermal power
estimation.
A Typical board thermal model automatically sets JB to a value based on the
package and device selected. You must specify a board temperature. If you choose
a Custom board thermal model, you must specify a value for JB and a board
temperature. If you do not want the PowerPlay Power Analyzer thermal model to
take the JB resistance into consideration, set the Board thermal modeling option
to None (conservative). In this case, the path through the board and the path
through power dissipation are not considered, and a more conservative thermal
power estimate is obtained.
The Board thermal modeling option is only available if you select the Auto
compute junction temperature using cooling solution option with the pre-set
cooling solution set to a heat sink solution option or custom solution. The Auto
compute junction temperature using cooling solution option is disabled when a
cooling solution with no heat sink is selected, as thermal conduction through the
board is included in the JA value used to compute a junction temperature.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 12: PowerPlay Power Analysis
PowerPlay Power Analyzer Flow
12–9
Signal Activities Data Sources
The PowerPlay Power Analyzer provides a flexible framework for specifying signal
activities. It reflects the importance of using representative signal-activity data during
power analysis. You can use the following sources to provide information about
signal activity:
■
Simulation results
■
User-entered node, entity, and clock assignments
■
User-entered default toggle rate assignment
■
Vectorless estimation
The PowerPlay Power Analyzer allows you to mix and match the signal-activity data
sources on a signal-by-signal basis. Figure 12–4 shows the priority scheme. The
following sections describe the data sources.
Figure 12–4. Signal-Activity Data Source Priority Scheme
Start
No
Node or entity
assignment?
Yes
Simulation
data?
Yes
Use node or
entity assignment
Use simulation
data
No
Is primary
input?
Yes
No
Vectorless
supported and
enabled?
(1)
Yes
Use vectorless
estimation
No
Use default
assignment
Note to Figure 12–4:
(1) Vectorless estimation is available only for the Arria II GX, Arria GX, Cyclone II, Cyclone III series, Cyclone IV series, MAX II, Stratix II, Stratix II GX,
Stratix III, Stratix IV, and Stratix V device families.
Simulation Results
The PowerPlay Power Analyzer directly reads the waveforms generated by a design
simulation. The static probability and toggle rate for each signal are calculated from
the simulation waveform. Power analysis is most accurate when you use
representative input stimuli to generate simulations.
The PowerPlay Power Analyzer reads results generated by the following simulators:
© July 2010
■
ModelSim®
■
ModelSim-Altera
■
QuestaSim
■
Active-HDL
■
NCSim
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
12–10
Chapter 12: PowerPlay Power Analysis
Using Simulation Files in Modular Design Flows
■
VCS
■
VCS MX
■
Riviera-PRO
Signal activity and static probability information derive from a Verilog Value Change
Dump File (.vcd). For more information, refer to “Signal Activities” on page 12–6.
For third-party simulators, use the Quartus II EDA Tool Settings for Simulation to
specify a Generate Value Change Dump file script. These scripts instruct the
third-party simulators to generate a .vcd that encodes the simulated waveforms. The
Quartus II PowerPlay Power Analyzer reads this file directly to derive the toggle rate
and static probability data for each signal.
Third-party EDA simulators, other than those listed, can generate a .vcd that can then
be used with the PowerPlay Power Analyzer. For those simulators, you must
manually create a simulation script to generate the appropriate .vcd.
1
You can use a .vcd created for power analysis to optimize your design for power
during fitting by utilizing the appropriate settings in the PowerPlay power
optimization list, available in the Fitter Settings page of the Settings dialog box.
f
For more information about power optimization, refer to the Power Optimization
chapter in volume 2 of the Quartus II Handbook.
f
For more information about how to create a .vcd in other third-party EDA simulation
tools, refer to Section I. Simulation in volume 3 of the Quartus II Handbook.
Using Simulation Files in Modular Design Flows
A common design practice is to create modular or hierarchical designs in which you
develop each design entity separately, and then instantiate it in a higher-level entity,
forming a complete design. You can perform simulation on a complete design or on
each modular design for verification. The PowerPlay Power Analyzer supports
modular design flows when reading the signal activities generated from these
simulation files. An example of a modular design flow is shown in Figure 12–5.
Figure 12–5. Modular Simulation Flow
Parameter
Input
Video
Processing
Column
Driver
system.vcd
video_gizmo.vcd
output_driver.vcd
Memory
Interface
Quartus II Handbook Version 10.0 Volume 3: Verification
Video
Source
Interface
Timing
Control
video_input.vcd
© July 2010 Altera Corporation
Chapter 12: PowerPlay Power Analysis
Using Simulation Files in Modular Design Flows
12–11
When specifying a simulation file, an associated design entity name is given, such that
the signal activities derived from the simulation file (.vcd) are imported into the
PowerPlay Power Analyzer for that particular design entity. The PowerPlay Power
Analyzer also supports the specification of multiple .vcd for power analysis, with
each having an associated design entity name to allow the integration of partial
design simulations into a complete design power analysis. When specifying multiple
.vcd for your design, it is possible that more than one simulation file contains
signal-activity information for the same signal. When you apply multiple .vcd to the
same design entity, the signal activity used in the power analysis is the equal-weight
arithmetic average of each .vcd. When you apply multiple simulation files to design
entities at different levels in your design hierarchy, the signal activity in the power
analysis derives from the simulation file that applies to the most specific design entity.
Figure 12–6 shows an example of a hierarchical design. The top-level module of your
design, called Top, consists of three 8b/10b decoders, followed by a multiplexer. The
output of the multiplexer is then encoded again before being the output from your
design. There is also an error-handling module that handles any 8b/10b decoding
errors. The top contains the top-level entity of your design and any logic not defined
as part of another module. The design file for the top-level module might be just a
wrapper for the hierarchical entities below it, or it might contain its own logic. The
following usage scenarios show common ways that you can simulate your design and
import .vcd into the PowerPlay Power Analyzer.
Figure 12–6. Example Hierarchical Design
Top
8b10b_dec:decode1
8b10b_rxerr:err1
8b10b_dec:decode2
mux:mux1
8b10b_dec:decode3
8b10b_enc:encode1
Complete Design Simulation
You can simulate the entire design top, generating a .vcd from a third-party simulator.
The .vcd can then be imported (specifying entity top) into the PowerPlay Power
Analyzer. The resulting power analysis uses all the signal activities information from
the generated .vcd, including those that apply to submodules, such as decode [13], err1, mux1, and encode1.
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
12–12
Chapter 12: PowerPlay Power Analysis
Using Simulation Files in Modular Design Flows
Modular Design Simulation
You can independently simulate submodules of the design top, and then import all
the resulting .vcd into the PowerPlay Power Analyzer. For example, you can simulate
the 8b10b_dec independent of the entire design, as well as multiplexer,
8b10b_rxerr, and 8b10b_enc. You can then import the .vcd generated from each
simulation by specifying the appropriate instance name. For example, if the files
produced by the simulations are 8b10b_dec.vcd, 8b10b_enc.vcd, 8b10b_rxerr.vcd,
and mux.vcd, the import specifications in Table 12–2 are used.
Table 12–2. Import Specifications
File Name
Entity
8b10b_dec.vcd
Top|8b10b_dec:decode1
8b10b_dec.vcd
Top|8b10b_dec:decode2
8b10b_dec.vcd
Top|8b10b_dec:decode3
8b10b_rxerr.vcd
Top|8b10b_rxerr:err1
8b10b_enc.vcd
Top|8b10b_enc:encode1
mux.vcd
Top|mux:mux1
The resulting power analysis applies the simulation vectors found in each file to the
assigned entity. Simulation provides signal activities for the pins and for the outputs
of functional blocks. If the inputs to an entity instance are input pins for the entire
design, the simulation file associated with that instance does not provide signal
activities for the inputs of that instance. For example, an input to an entity such as
mux1 has its signal activity specified at the output of one of the decode entities.
Multiple Simulations on the Same Entity
You can perform multiple simulations of an entire design or specific modules of a
design. For example, in the process of verifying the design top, you can have three
different simulation testbenches: one for normal operation and two for corner cases.
Each of these simulations produces a separate .vcd. In this case, apply the different
.vcd names to the same top-level entity, shown in Table 12–3.
Table 12–3. Multiple Simulation File Names and Entities
File Name
Entity
normal.vcd
Top
corner1.vcd
Top
corner2.vcd
Top
The resulting power analysis uses an arithmetic average that the signal activities
calculated from each simulation file to obtain the final signal activities used. If a signal
err_out has a toggle rate of zero toggles per second in normal.vcd, 50 toggles per
second in corner1.vcd, and 70 toggles per second in corner2.vcd, the final toggle rate
in the power analysis is 40 toggles per second.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 12: PowerPlay Power Analysis
Using Simulation Files in Modular Design Flows
12–13
Overlapping Simulations
You can perform a simulation on the entire design top and more exhaustive
simulations on a submodule, such as 8b10b_rxerr. Table 12–4 shows the import
specification for overlapping simulations.
Table 12–4. Overlapping Simulation Import Specifications
File Name
Entity
full_design.vcd
Top
error_cases.vcd
Top|8b10b_rxerr:err1
In this case, signal activities from error_cases.vcd are used for all of the nodes in the
generated .vcd and signal activities from full_design.vcd are used for only those
nodes that do not overlap with nodes in error_cases.vcd. In general, the more specific
hierarchy (the most bottom-level module) derives signal activities for overlapping
nodes.
Partial Simulations
You can perform a simulation in which the entire simulation time is not applicable to
signal-activity calculation. For example, run a simulation for 10,000 clock cycles and
reset the chip for the first 2,000 clock cycles. If the signal-activity calculation is
performed over all 10,000 cycles, the toggle rates are only 80% of their steady state
value (because the chip is in reset for the first 20% of the simulation). In this case, you
must specify the useful parts of the .vcd for power analysis. The Limit VCD Period
option enables you to specify a start and end time to be used when performing
signal-activity calculations.
Node Name Matching Considerations
Node name mismatches happen when you have .vcd applied to entities other than the
top-level entity. In a modular design flow, the gate-level simulation files created in
different Quartus II projects may not match their node names with the current
Quartus II project.
For example, if you have a file named 8b10b_enc.vcd, which was generated in a
separate project called 8b10b_enc and is simulating the 8b10b encoder, and you
import that .vcd into another project called Top, you might encounter name
mismatches when applying the .vcd to the 8b10b_enc module in the Top project.
This mismatch happens because all the combinational nodes in the 8b10b_enc.vcd
might be named differently in the Top project.
You can avoid name mismatching with only RTL simulation data, in which register
names do not change, or with an incremental compilation flow that preserves node
names in conjunction with a gate-level simulation.
1
f
© July 2010
To ensure the best accuracy, Altera recommends using an incremental compilation
flow to preserve the node names of your design.
For more information about the incremental compilation flow, refer to the Quartus II
Incremental Compilation for Hierarchical and Team-Based Design chapter in volume 1 of
the Quartus II Handbook.
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
12–14
Chapter 12: PowerPlay Power Analysis
Using Simulation Files in Modular Design Flows
Glitch Filtering
The PowerPlay Power Analyzer defines a glitch as two signal transitions so closely
spaced in time that the pulse or glitch occurs faster than the logic and routing circuitry
can respond. The output of a transport delay model simulator contains glitches for
some signals. The logic and routing structures of the device form a low-pass filter that
filters out glitches that are tens to hundreds of picoseconds long, depending on the
device family.
Some third-party simulators use different models than the transport delay model as
default model. Different models cause differences in signal activity and power
estimation. The inertial delay model, which is the ModelSim default model, filters out
more glitches than the transport delay model and usually yields a lower power
estimate.
1
f
Altera recommends using the transport simulation model when using the Quartus II
software glitch filtering support with third-party simulators. Simulation glitch
filtering has little effect if you use the inertial simulation model.
For more information about how to set the simulation model type for your specific
simulator, refer to Quartus II Help.
Glitch filtering in a simulator can also filter a glitch on one LE (or other circuit
element) output from propagating to downstream circuit elements to ensure that the
glitch does not affect simulated results. It prevents a glitch on one signal from
producing non-physical glitches on all downstream logic, which can result in a signal
toggle rate and a power estimate that are too high. Circuit elements in which every
input transition produces an output transition, including multipliers and logic cells
configured to implement XOR functions, are especially prone to glitches. Therefore,
circuits with such functions can have power estimates that are too high when you do
not use glitch filtering.
Altera recommends using the glitch filtering feature to obtain the most accurate
power estimates. For .vcd, the PowerPlay Power Analyzer flows support two levels of
glitch filtering, both of which are recommended for power estimation.
In the first level of glitch filtering, glitches are filtered during simulation. To enable
this level of glitch filtering in the Quartus II software for supported third-party
simulators, follow these steps:
1. On the Assignments menu, click Settings. The Settings dialog box appears.
2. In the Category list, select Simulation under EDA Tool Settings. The Simulation
page appears.
3. Select the Tool name to use for the simulation.
4. Turn on Enable glitch filtering.
The second level of glitch filtering occurs while the PowerPlay Power Analyzer is
reading the .vcd generated by a third-party simulator. To enable this level of glitch
filtering, follow these steps:
On the Assignments menu, click Settings. The Settings dialog box appears.
1. In the Category list, select PowerPlay Power Analyzer Settings. The PowerPlay
Power Analyzer Settings page appears.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 12: PowerPlay Power Analysis
Using Simulation Files in Modular Design Flows
12–15
2. Under Input File(s), turn on Perform glitch filtering on VCD files.
The .vcd file reader performs complementary filtering to the filtering performed
during simulation and is often not as effective. While the .vcd file reader can remove
glitches on logic blocks, it has no way of determining how downstream logic and
routing are affected by a given glitch, and may eliminate the impact of the glitch
completely. Filtering the glitches during simulation avoids switching downstream
routing and logic automatically.
1
When running simulation for design verification (rather than to produce input to the
PowerPlay Power Analyzer), Altera recommends turning off the glitch filtering
option to produce the most rigorous and conservative simulation from a functionality
viewpoint. When performing simulation to produce input for the PowerPlay Power
Analyzer, Altera recommends turning on the glitch filtering to produce the most
accurate power estimates.
Node and Entity Assignments
You can assign specific toggle rates and static probabilities to individual nodes and
entities in the design. These assignments have the highest priority, overriding data
from all other signal-activity sources.
You must use the Assignment Editor or Tcl commands to create the Power Toggle
Rate and Power Static Probability assignments. You can specify the power toggle
rate as an absolute toggle rate in transitions using the Power Toggle Rate assignment
or you can use the Power Toggle Rate Percentage assignment to specify a toggle rate
relative to the clock domain of the assigned node for a more specific assignment made
in terms of hierarchy level.
1
If the Power Toggle Rate Percentage assignment is used, and the given node does not
have a clock domain, a warning is issued and the assignment is ignored.
f
For more information about how to use the Assignment Editor in the Quartus II
software, refer to the Assignment Editor chapter in volume 2 of the Quartus II Handbook.
Assigning specific toggle rates and static probabilities to individual nodes and entities
is appropriate for signals in which you have specific knowledge of the signal or entity
being analyzed. For example, if you know that a 100 MHz data bus or memory output
produces data that is essentially random (uncorrelated in time), you can directly enter
a 0.5 static probability and a toggle rate of 50 million transitions per second.
Bidirectional I/O pins are treated specially. The combinational input port and the
output pad for a given pin share the same name. However, those ports might not
share the same signal activities. For the purpose of reading signal-activity
assignments, the PowerPlay Power Analyzer creates a distinct name
<node_name~output> when the bidirectional signal is configured as an output and
<node_name~result> when the signal is configured as an input. For example, if a
design has a bidirectional pin named MYPIN, assignments for the combinational input
use the name MYPIN~result, and the assignments for the output pad use the name
MYPIN~output.
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
12–16
Chapter 12: PowerPlay Power Analysis
Using Simulation Files in Modular Design Flows
1
When creating the logic assignment in the Assignment Editor, you will not find the
MYPIN~result and MYPIN~output node names in the Node Finder. Therefore, to
create the logic assignment, you must manually enter the two differentiating node
names to create the specific assignment for the input and output port of the
bidirectional pin.
Timing Assignments to Clock Nodes
For clock nodes, the PowerPlay Power Analyzer uses the timing requirements to
derive the toggle rate when neither simulation data nor user-entered signal-activity
data is available. fMAX requirements specify full cycles per second, but each cycle
represents a rising transition and a falling transition. For example, a clock fMAX
requirement of 100 MHz corresponds to 200 million transitions per second.
Default Toggle Rate Assignment
You can specify a default toggle rate for primary inputs and all other nodes in the
design. The default toggle rate is used when no other method has specified the
signal-activity data.
The toggle rate is specified in absolute terms (transitions per second) or as a fraction
of the clock rate in effect for each particular node. The toggle rate for a given clock
derives from the timing settings for the clock. For example, if a clock is specified with
an fMAX constraint of 100 MHz and a default relative toggle rate of 20%, nodes in this
clock domain transition in 20% of the clock periods, or 20 million transitions occur per
second. In some cases, the PowerPlay Power Analyzer cannot determine the clock
domain for a given node because there is either no clock domain for the node or it is
ambiguous. In these cases, the PowerPlay Power Analyzer substitutes and reports a
toggle rate of zero.
Vectorless Estimation
For some device families, the PowerPlay Power Analyzer automatically derives
estimates for signal activity on nodes with no simulation or user-entered
signal-activity data. Vectorless estimation is available and enabled by default for
Arria II GX, Arria GX, Cyclone II, Cyclone III series, Cyclone IV series, MAX II,
Stratix II, Stratix II GX, Stratix III, Stratix IV, and Stratix V device families. Vectorless
estimation statistically estimates the signal activity of a node based on the signal
activities of all nodes feeding that node, and on the actual logic function implemented
by the node. The PowerPlay Power Analyzer Settings dialog box lets you disable
vectorless estimation. When enabled, vectorless estimation takes priority over default
toggle rates. Vectorless estimation does not override clock assignments.
1
Vectorless estimation cannot derive signal activities for primary inputs. Vectorless
estimation is generally accurate for combinational nodes, but not for registered nodes.
Therefore, simulation data for at least the registered nodes and I/O nodes is required
for accuracy.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 12: PowerPlay Power Analysis
Using the PowerPlay Power Analyzer
12–17
Using the PowerPlay Power Analyzer
For all the flows that use the PowerPlay Power Analyzer, synthesize your design first
and then fit it to the target device. You must either provide timing assignments for all
the clocks in the design or use a simulation-based flow to generate activity data. The
I/O standard used on each device input or output and the capacitive load on each
output must be specified in the design.
f
For more information about using the PowerPlay Power Analyzer, refer to Performing
Power Analysis with the PowerPlay Power Analyzer in Quartus II Help.
Common Analysis Flows
You can use the analysis flows in this section with the PowerPlay Power Analyzer.
However, vectorless activity estimation is only available for some device families.
Signal Activities from Full Post-Fit Netlist (Timing) Simulation
This flow provides the most accuracy because all node activities reflect actual design
behavior, provided that supplied input vectors are representative of typical design
operation. Results are better if the simulation filters glitches. The disadvantage of this
method is that the simulation time is long.
Signal Activities from Full Post-Fit Netlist (Zero Delay) Simulation
The zero delay simulation flow is used with designs for which signal activities from a
full post-fit netlist (timing) simulation are not available. Zero delay simulation is as
accurate as timing simulation in 95% of designs with no glitches.
1
If your design has glitches, power may be underestimated. Altera recommends using
the signal activities from a full post-fit netlist (timing) simulation to achieve accurate
power estimation of your design.
The following designs might exhibit glitches:
■
Designs with many XOR gates (for example, an encryption core)
■
Designs with arithmetic blocks without input and output registers (DSPs and
carry chains)
For more information about creating zero delay simulation signal activities, refer
to “Generating a .vcd from Full Post-Fit Netlist (Zero Delay) Simulation” on
page 12–20.
Signal Activities from RTL (Functional) Simulation, Supplemented by Vectorless
Estimation
In this flow, simulation provides toggle rates and static probabilities for all pins and
registers in the design. Vectorless estimation fills in the values for all the
combinational nodes between pins and registers, giving good results. This flow
usually provides a compilation time benefit to the user in the third-party RTL
simulator.
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
12–18
Chapter 12: PowerPlay Power Analysis
Using the PowerPlay Power Analyzer
1
RTL simulation may not provide signal activities for all registers in the post-fitting
netlist because some register names might be lost during synthesis. For example,
synthesis might automatically transform state machines and counters, thus changing
the names of registers in those structures.
Signal Activities from Vectorless Estimation and User-Supplied Input Pin Activities
This flow provides a low level of accuracy, because vectorless estimation for registers
is not entirely accurate.
Signal Activities from User Defaults Only
This flow provides the lowest degree of accuracy.
Generating a .vcd
In previous versions of the Quartus II software, you could use either the Quartus II
simulator or an EDA simulator to perform your simulation. The Quartus II software
no longer supports a built-in simulator, and you must use EDA simulators to perform
simulation. Use the .vcd as the input to the PowerPlay Power Analyzer to estimate
power for your design.
f
For more information about the supported third-party simulators, refer to
“Simulation Results” on page 12–9.
To create a .vcd for your design, follow these steps:
1. On the Assignments menu, click Settings. The Settings dialog box appears.
2. In the Category list, under EDA Tool Settings, click Simulation. The Simulation
page appears.
3. In the Tool name list, select your preferred EDA simulator.
4. In the Format for output netlist list, select Verilog HDL, or SystemVerilog HDL,
or VHDL.
5. Turn on Generate Value Change Dump (VCD) file script.
1
This turns on the Map illegal HDL characters and Enable glitch filtering
options. The Map illegal HDL characters option ensures that all signals
have legal names and that signal toggle rates are available later in the
PowerPlay Power Analyzer.
6. By turning on Enable glitch filtering, glitch filtering logic is the output when you
generate an EDA netlist for simulation. This option is available regardless of
whether or not you want to generate the .vcd scripts. For more information about
glitch filtering, refer to “Glitch Filtering” on page 12–14.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 12: PowerPlay Power Analysis
Using the PowerPlay Power Analyzer
1
12–19
When performing simulation using ModelSim, the +nospecify option for
the vsim command disables the specify path delays and timing checks
option in ModelSim. By enabling glitch filtering on the Simulation page,
the simulation models include specified path delays. Thus, ModelSim
might fail to simulate a design if glitch filtering is enabled, and the
+nospecify option is specified. Altera recommends removing the
+nospecify option from the ModelSim vsim command to ensure accurate
simulation for power estimation.
7. Click Script Settings. The Script Settings dialog box appears.
Select which signals must be output to the .vcd. With All signals selected, the
generated script instructs the third-party simulator to write all connected output
signals to the .vcd. With All signals except combinational lcell outputs selected,
the generated script tells the third-party simulator to write all connected output
signals to the .vcd, except logic cell combinational outputs.
1
The file can become extremely large if you write all output signals to the file
because its size depends on the number of output signals being monitored
and the number of transitions that occur.
9. Click OK.
10. Type a name for your testbench in the Design instance name box.
11. Compile your design with the Quartus II software and generate the necessary
EDA netlist and script that instructs the third-party simulator to generate a .vcd.
f
For more information about the NativeLink feature, refer to Section I.
Simulation in volume 3 of the Quartus II Handbook.
12. Perform a simulation with the third-party EDA simulation tool. Call the generated
script in the simulation tool before running the simulation. The simulation tool
generates the .vcd and places it in the project directory.
Generating a .vcd from ModelSim Software
To successfully produce a .vcd with the ModelSim software, follow these steps:
1. In the Quartus II software, on the Assignments menu, click Settings. The Settings
dialog box appears.
2. In the Category list, under EDA Tool Settings, click Simulation. The Simulation
page appears.
3. In the Tool name list, select your preferred EDA simulator.
4. In the Format for output netlist list, select Verilog HDL, or SystemVerilog HDL,
or VHDL.
5. Turn on Generate Value Change Dump (VCD) file script.
6. To generate the .vcd, perform a full compilation.
7. In the ModelSim software, compile the files necessary for simulation.
8. Load your design by clicking Start Simulation on the Tools menu, or use the vsim
command.
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
12–20
Chapter 12: PowerPlay Power Analysis
Using the PowerPlay Power Analyzer
9. Use the .vcd script created in step 6 using the following command:
source <design>_dump_all_vcd_nodes.tcl
10. Run the simulation (for example, run 2000ns or run -all).
11. Quit the simulation using the quit -sim command, if required.
12. Exit the ModelSim software. If you do not exit the software, the ModelSim
software might end the writing process of the .vcd improperly, resulting in a
corrupt .vcd.
Generating a .vcd from Full Post-Fit Netlist (Zero Delay) Simulation
To successfully generate a .vcd from the full post-fit Netlist (zero delay) simulation,
follow these steps:
1. Compile your deisgn in the Quartus II software to generate the Netlist
<project_name>.vo.
2. In <project_name>.vo, search for the include statement for <project_name>.sdo,
comment the statement out, and save the file.
3. Generate a .vcd for power estimation by performing the steps in “Generating a
.vcd” on page 12–18.
1
Altera recommends using the Standard Delay Format Output File (.sdo) for
gate-level timing simulation. The .sdo contains the delay information of
each architecture primitive and routing element specific to your design;
however, you must exclude the .sdo for zero delay simulation.
f
For more information about how to create a .vcd in other third-party EDA
simulation tools, refer to Section I. Simulation in volume 3 of the Quartus II
Handbook.
Running the PowerPlay Power Analyzer Using the Quartus II GUI
To run the PowerPlay Power Analyzer using the Quartus II GUI, follow these steps:
1. On the Assignments menu, click Settings. The Settings dialog box appears.
2. In the Category list, click PowerPlay Power Analyzer Settings.
3. If you want to use .vcd as an input to the PowerPlay Power Analyzer, turn on Use
input file(s) to initialize toggle rates and static probabilities during power
analysis.
4. Click Add. The Add Power Input File dialog box appears.
5. Browse to your .vcd.
6. Type the entity name into the Entity box, or browse to your entity. The Entity box
enables you to specify the design entity (hierarchy) to which the entered power
input file applies. In the Select Hierarchy dialog box, you can specify multiple
entities in the entity text box with comma delimiters. Under Simulation period,
you can specify either a Signal Activity File or a VCD file. The Limit VCD period
option is available only when VCD file is selected. Turning on the Limit VCD
period option enables you to specify the simulation period when calculating the
signal activities.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 12: PowerPlay Power Analysis
Using the PowerPlay Power Analyzer
12–21
7. Click OK.
8. Turn on the Write out signal activities used during power analysis option. In the
Output file name box, browse to the output file name. The output file contains all
the signal activities information used during the power estimation of your design.
Turning on the Write out signal activities used during power analysis option
reduces the run time of any subsequent power estimation.
9. Turn on the Write signal activities to report file option (optional).
10. Turn on the Write power dissipation by block to report file option to enable the
output of detailed thermal power dissipation by block to be included in the
PowerPlay Power Analyzer report (optional).
11. Use the Assignment Editor to enter the Power Toggle Rate or Power Toggle Rate
Percentage, and the Power Static Probability assignments for a node or entity in
your design, shown in Figure 12–7 (optional).
Figure 12–7. Assignment Editor (Notes 1), (2)
Notes to Figure 12–7:
(1) The assignments made with the Assignment Editor override the existing values in the vcd.
(2) You can also use Tcl script commands to create these assignments.
f
For more information about how to use the Assignment Editor in the
Quartus II software, refer to the Assignment Editor chapter in volume 2 of
the Quartus II Handbook. For information about scripting, refer to the Tcl
Scripting chapter in volume 2 of the Quartus II Handbook.
12. Specify the toggle rate in the Default toggle rate used for input I/O signals field.
This toggle rate is used for all unspecified input I/O signal toggle rates regardless
of whether or not the device family supports vectorless estimation. By default, its
value is set to 12.5%. The default static probability for unspecified input I/O
signals is 0.5 and cannot be changed.
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
12–22
Chapter 12: PowerPlay Power Analysis
Using the PowerPlay Power Analyzer
13. Select either Use default value or Use vectorless estimation for Arria II GX,
Arria GX, Cyclone II, Cyclone III series, Cyclone IV series, MAX II, Stratix II,
Stratix II GX, Stratix III, Stratix IV, and Stratix V device families. For all other
device families, only Use default value is available. This setting controls how the
remainder of the unspecified signal activities are calculated. For more information,
refer to “Vectorless Estimation” on page 12–16 and “Default Toggle Rate
Assignment” on page 12–16.
14. In the Category list, click Operating Settings and Conditions. This page is only
available for the Arria II GX, Arria GX, Cyclone II, Cyclone III series, Cyclone IV
series, HardCopy series, MAX II, Stratix II, Stratix II GX, Stratix III, Stratix IV, and
Stratix V device families.
15. In the Device power characteristics list, select Typical or Maximum, depending
on the options available.
16. In the Category list, click Voltage under Operating Settings and Conditions. The
Voltage page appears.
17. For the devices with selectable core voltage support, in the Core supply voltage
list, select the core supply voltage for your device. This option is available for the
latest devices with variable voltage selection.
18. In the Category list, click Temperature under Operating Settings and Conditions.
The Temperature page appears.
19. Under Junction temperature range, specify the Low temperature and High
temperature range for your selected device.
20. Under Junction temperature and cooling solution settings for PowerPlay power
pnalysis, select Specify junction temperature or Auto compute junction
temperature using cooling solution, and then specify the junction temperature of
Ambient temperature.
21. Under Board thermal modeling, select the Board thermal model and type the
Board temperature (optional). This feature is available only when you select Auto
compute junction temperature using cooling solution.
f
For more information about how to use the operating condition settings,
refer to “Operating Conditions” on page 12–7.
26. Click OK.
27. On the Processing menu, click PowerPlay Power Analyzer Tool. The PowerPlay
Power Analyzer Tool dialog box appears.
28. Click Start to run the PowerPlay Power Analyzer. Verify all the settings.
1
You can also change some of your settings in the PowerPlay Power
Analyzer Tool dialog box. For example, click Add Power Input File(s) to
make changes to your input files, or click Cooling Solution and
Temperature to make changes to your design temperature and cooling
solution selection.
29. Click OK.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 12: PowerPlay Power Analysis
Using the PowerPlay Power Analyzer
12–23
30. In the PowerPlay Power Analyzer Tool dialog box, click Report to open the
PowerPlay Power Analyzer Summary window. You can also view the summary in
the PowerPlay Power Analyzer Summary page of the Compilation Report
(Figure 12–8).
Figure 12–8. PowerPlay Power Analyzer Summary
PowerPlay Power Analyzer Compilation Report
The PowerPlay Power Analyzer section of the Compilation Report consists of the
following sections.
Summary
This section of the report shows the estimated total thermal power consumption of
your design. This includes dynamic, static, and I/O thermal power consumption. The
I/O thermal power consumption is the total I/O power contributed by both the VCCIO
power supplies and some portion of the VCCINT. The report also includes a confidence
metric that reflects the overall quality of the data sources for the signal activities. For
example, a Low power estimation confidence value reflects that you have provided
insufficient toggle rate data, or most of the signal-activity information used for power
estimation is from default or vectorless estimation settings. For more information
about the input data, refer to the PowerPlay Power Analyzer Confidence Metric
report.
Settings
This section of the report shows the PowerPlay Power Analyzer settings information
of your design, including the default input toggle rates, operating conditions, and
other relevant setting information.
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
12–24
Chapter 12: PowerPlay Power Analysis
Using the PowerPlay Power Analyzer
Simulation Files Read
This section of the report lists the simulation output file (.vcd) used for power
estimation. This section also includes the file ID, file type, entity, VCD start time, VCD
end time, the unknown percentage, and the toggle percentage. The unknown
percentage indicates the portion of the design module that is not exercised by the
simulation vectors.
Operating Conditions Used
This section of the report shows device characteristics, voltages, temperature, and
cooling solution, if any, that were used during the power estimation. This section also
shows the entered junction temperature or auto-computed junction temperature that
was used during the power analysis. This report is generated only for Arria II GX,
Arria GX, Cyclone II, Cyclone III series, Cyclone IV series, HardCopy series, MAX II,
Stratix II, Stratix II GX, Stratix III, Stratix IV, and Stratix V device families.
Thermal Power Dissipated by Block
This section of the report shows estimated thermal dynamic power and thermal static
power consumption categorized by atoms. This information provides you with
estimated power consumption for each atom in your design.
Thermal Power Dissipation by Block Type (Device Resource Type)
This section of the report shows the estimated thermal dynamic power and thermal
static power consumption categorized by block types. This information is further
categorized by estimated dynamic and static power that was used, as well as
providing an average toggle rate by block type. Thermal power is the power
dissipated as heat from the FPGA device.
Thermal Power Dissipation by Hierarchy
This section of the report shows estimated thermal dynamic power and thermal static
power consumption categorized by design hierarchy. This information is further
categorized by the dynamic and static power that was used by the blocks and routing
in that hierarchy. This information is very useful when locating problem modules in
your design.
Core Dynamic Thermal Power Dissipation by Clock Domain
This section of the report shows the estimated total core dynamic power dissipation
by each clock domain, which provides designs with estimated power consumption
for each clock domain in the design. If the clock frequency for a domain is unspecified
by a constraint, the clock frequency is listed as “unspecified.” For all the
combinational logic, the clock domain is listed as no clock with zero MHz.
Current Drawn from Voltage Supplies
This section of the report lists the current that was drawn from each voltage supply.
The VCCIO voltage supply is further categorized by I/O bank and by voltage. The
minimum safe power supply size (current supply ability) is also listed for each supply
voltage. This report is generated only for Arria II GX, Cyclone III, Cyclone III LS,
Cyclone IV series, MAX II, Stratix III, Stratix IV series, and Stratix V device families.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 12: PowerPlay Power Analysis
Using the PowerPlay Power Analyzer
12–25
Transceiver-based devices have multiple voltage supplies, which are VCCH, VCCT, VCCR,
VCCA, and VCCP. The report also shows the static and dynamic current (in mA) drawn
from each voltage supply. Total static and dynamic power consumed by the
transceivers on all voltage supplies is listed under the “Thermal Power Dissipation by
Block Type” report section, which contains a row that starts with “GXB Transceiver.”
The I/O thermal power dissipation, which is listed on the summary page, does not
correlate directly to the power drawn from the VCCIO voltage supply listed in this
report. This is because the I/O thermal power dissipation value also includes portions
of the VCCINT power, such as the I/O element (IOE) registers, which are modeled as
I/O power, but do not draw from the VCCIO supply.
Confidence Metric Details
The confidence metric indicates the quality of the signal toggle rate data used to
compute a power estimate. The confidence metric is low if the signal toggle rate data
comes from sources that are considered poor predictors of real signal toggle rates in
the device during an operation. Toggle rate data that comes from simulation,
user-entered assignments on specific signals, or entities are considered reliable.
Toggle rate data from default toggle rates (for example, 12.5% of the clock period) or
vectorless estimation are considered relatively inaccurate. This section gives an
overall confidence rating in the toggle rate data, from low to high. This section also
summarizes how many pins, registers, and combinational nodes obtained their toggle
rates from each of simulation, user entry, vectorless estimation, or default toggle rate
estimations. This detailed information helps you understand how to increase the
confidence metric, letting you determine your own confidence in the toggle rate data.
Signal Activities
This section lists toggle rates and static probabilities assumed by power analysis for
all signals with fan-out and pins. The signal type is provided (pin, registered, or
combinational), as well as the data source for the toggle rate and static probability. By
default, all signal activities are reported, but can be turned off by turning off the Write
signal activities to report file option on the PowerPlay Power Analyzer Settings
page.
1
Altera recommends turning off the Write signal activities to report file option for a
large design because of the large number of signals present. You can use the
Assignment Editor to specify that activities for individual nodes or entities are
reported by assigning an on value to those nodes for the Power Report Signal
Activities assignment.
Messages
This section lists the messages generated by the Quartus II software during the
analysis.
Specific Rules for Reporting
In a Stratix GX device, the XGM II state machine block is always used together with
GXB transceivers, so its power is lumped into the power for the transceivers.
Therefore, the power for the XGM II state machine block is reported as zero Watts.
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
12–26
Chapter 12: PowerPlay Power Analysis
Using the PowerPlay Power Analyzer
Scripting Support
You can run procedures and create settings described in this chapter in a Tcl script.
You can also run some procedures at a command prompt. For more information about
scripting command options, refer to the Quartus II Command-Line and Tcl API Help
browser. To run the Help browser, type the following command at the command
prompt:
quartus_sh --qhelpr
f
For more information about Tcl scripting, refer to the Tcl Scripting chapter in volume 2
of the Quartus II Handbook and API Functions for Tcl in Quartus II Help.. For more
information about all settings and constraints in the Quartus II software, refer to the
Quartus II Settings File Reference Manual. For more information about command-line
scripting, refer to the Command-Line Scripting chapter in volume 2 of the Quartus II
Handbook.
Running the PowerPlay Power Analyzer from the Command–Line
The separate executable used to run the PowerPlay Power Analyzer is quartus_pow.
For a complete listing of all command–line options supported by quartus_pow, type
the following command at a system command prompt:
quartus_pow --help or quartus_sh --qhelp r
The following is an example of using the quartus_pow executable with project
sample.qpf:
■
To instruct the PowerPlay Power Analyzer to generate a PowerPlay EPE File, type
the following command at a system command prompt:
quartus_pow sample --output_epe=sample.csv r
■
To instruct the PowerPlay Power Analyzer to generate a PowerPlay EPE File
without performing the power estimate, type the following command at a system
command prompt:
quartus_pow sample --output_epe=sample.csv -estimate_power=off r
■
To instruct the PowerPlay Power Analyzer to use a .vcd as input (sample.vcd),
type the following command at a system command prompt:
quartus_pow sample --input_vcd=sample.vcd r
■
To instruct the PowerPlay Power Analyzer to use two .vcd files as input files
(sample1.vcd and sample2.vcd), perform glitch filtering on the .vcd and use a
default input I/O toggle rate of 10,000 transitions per second, type the following
command at a system command prompt:
quartus_pow sample --input_vcd=sample1.vcd -input_vcd=sample2.vcd \
--vcd_filter_glitches=on --\
default_input_io_toggle_rate=10000transitions/s r
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 12: PowerPlay Power Analysis
Conclusion
■
12–27
To instruct the PowerPlay Power Analyzer to not use any input file, a default input
I/O toggle rate of 60%, no vectorless estimation, and a default toggle rate of 20%
on all remaining signals, type the following command at a system command
prompt:
quartus_pow sample --no_input_file -default_input_io_toggle_rate=60% \
--use_vectorless_estimation=off --default_toggle_rate=20% r
1
There are no command–line options to specify the information found on the
PowerPlay Power Analyzer Settings Operating Conditions page. You can
use the Quartus II GUI to specify these options.
The quartus_pow executable creates a report file, <revision name>.pow.rpt. You
can locate the report file in the main project directory. The report file contains the
same information in “PowerPlay Power Analyzer Compilation Report” on
page 12–23.
Conclusion
PowerPlay power analysis tools are designed for accurate estimation of power
consumption from early design concept through design implementation. You can use
the PowerPlay EPE to estimate power consumption during the design concept stage.
You can use the PowerPlay Power Analyzer tool to refine power estimations during
design implementation. The PowerPlay Power Analyzer produces detailed reports
that you can use to optimize designs for lower power consumption and verify that the
design is in your power budget.
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
12–28
Chapter 12: PowerPlay Power Analysis
Document Revision History
Document Revision History
Table 12–5 shows the revision history for this chapter.
Table 12–5. Document Revision History
Date
Version
July 2010
10.0.0
November 2009
March 2009
9.1.0
9.0.0
November 2008
May 2008
8.1.0
8.0.0
Changes Made
■
Removed references to the Quartus II Simulator.
■
Updated Table 12–1 on page 12–3, Table 12–2 on page 12–12, and
Table 12–3 on page 12–12.
■
Updated Figure 12–3 on page 12–7, Figure 12–4 on page 12–9, and
Figure 12–5 on page 12–10.
■
Updated “Creating PowerPlay EPE Spreadsheets” on page 12–2 and
“Simulation Results” on page 12–9.
■
Added “Signal Activities from Full Post-Fit Netlist (Zero Delay)
Simulation” on page 12–17 and “Generating a .vcd from Full Post-Fit
Netlist (Zero Delay) Simulation” on page 12–20.
■
Minor changes to “Generating a .vcd from ModelSim Software” on
page 12–19.
■
Updated Figure 12–2 on page 12–2 and Figure 12–8 on page 12–23.
■
This chapter was chapter 11 in version 8.1.
■
Removed Figures 11-10, 11-11, 11-13, 11-14, and 11-17 from 8.1
version.
■
Updated for the Quartus II software version 8.1.
■
Replaced Figure 11-3.
■
Replaced Figure 11-14.
■
Updated Figure 11–5.
■
Updated “Types of Power Analyses” on page 11–5.
■
Updated “Operating Conditions” on page 11–9.
■
Updated “PowerPlay Power Analyzer Compilation Report” on
page 11–31.
■
Updated “Current Drawn from Voltage Supplies” on page 11–32.
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 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Section IV. System Debugging Tools
The Altera® Quartus® II design software provides a complete design debugging
environment that easily adapts to your specific design requirements. This handbook
is arranged in chapters, sections, and volumes that correspond to the major tools
available for debugging your designs. For a general introduction to features and the
standard design flow in the software, refer to the Introduction to the Quartus II Software
manual.
This section is an introduction to System Debugging Tools and includes the following
chapters:
■
Chapter 13, System Debugging Tools Overview
This chapter compares the various system debugging tools and explains when to
use each of them.
■
Chapter 14, Analyzing and Debugging Designs with the System Console
This chapter describes the System Console Toolkit and compares the different
capabilities within the toolkit.
Chapter 15, Transceiver Link Debugging Using the Quartus II Software
This chapter explains what functions are available within the Transceiver Toolkit
and helps you decide which tool best meets your debugging needs.
■
Chapter 16, Quick Design Debugging Using SignalProbe
This chapter provides detailed instructions about how to use SignalProbe to
quickly debug your design.
Use this chapter to verify your design more efficiently by routing internal signals
to I/O pins quickly without affecting the design.
■
Chapter 17, Design Debugging Using the SignalTap II Logic Analyzer
This chapter describes how to debug your FPGA design during normal device
operation without the need for external lab equipment. Use this chapter to learn
how to examine the behavior of internal signals, without using extra I/O pins,
while the design is running at full speed on an FPGA device.
■
Chapter 18, In-System Debugging Using External Logic Analyzers
This chapter explains how to use external logic analyzers to debug designs on
Altera devices.
■
Chapter 19, In-System Modification of Memory and Constants
This chapter explains how to use the Quartus II In-System Memory Content Editor
as part of your FPGA design and verification flow to easily view and debug your
design in the hardware lab.
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
IV–2
Section IV: System Debugging Tools
■
Chapter 20, Design Debugging Using In-System Sources and Probes
This chapter provides detailed instructions about how to use the In-System
Sources and Probes Editor and Tcl scripting in the Quartus® II software to debug
your design.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
13. System Debugging Tools Overview
QII53027-10.0.0
Debugging today’s FPGA designs can be a daunting task. As your product
requirements continue to increase in complexity, the time you spend on design
verification continues to rise. Altera provides a set of verification tools that are
powerful and easy to use, allowing you to get your product to market quickly by
minimizing design verification time.
The Quartus® II software provides a portfolio of system design debugging tools for
real-time verification of your design. Each tool in the system debugging portfolio uses
a combination of available memory, logic, and routing resources to assist in the
debugging process. The tools provide visibility by routing (or “tapping”) signals in
your design to debugging logic. The debugging logic is then compiled with your
design and downloaded into the FPGA or CPLD for analysis. Because different
designs can have different constraints and requirements, such as the number of spare
pins available or the amount of logic or memory resources remaining in the physical
device, you can choose a tool from the available debugging tools that matches the
specific requirements for your design.
This section provides a quick overview of the tools available in the system debugging
suite and discusses the criteria for selecting the best tool for your design.
System Debugging Tools
Table 12–1 summarizes the tools in the system debugging tool suite that are covered
in this section of the Quartus II Handbook.
Table 12–1. Available Tools in the In-System Verification Tools Suite (Part 1 of 2)
Tool
Description
Typical Usage
System Console
This is a Tcl console that communicates to
hardware modules instantiated into your design.
You can use it with the Transceiver Toolkit to
monitor or debug your design.
You need to perform system-level debugging.
For example, if you have an Avalon-MM slave or
Avalon-ST interfaces, you can debug your
design at a transaction level. The tool supports
JTAG connectivity, but also supports PLI
connectivity to a simulation model, as well as
TCP/IP connectivity to the target FPGA you wish
to debug.
Transceiver Toolkit
This toolkit allows you to calibrate PMA settings You need to debug or optimize transceiver link
so that you can optimize settings for your board. channels in your design.
SignalTap® II Logic
Analyzer
This logic analyzer uses FPGA resources to
sample tests nodes and outputs the information
to the Quartus II software for display and
analysis.
You have spare on-chip memory and you want
functional verification of your design running in
hardware.
SignalProbe
This tool incrementally routes internal signals to
I/O pins while preserving results from your last
place-and-routed design.
You have spare I/O pins and you would like to
check the operation of a small set of control pins
using either an external logic analyzer or an
oscilloscope.
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
13–2
Chapter 13: System Debugging Tools Overview
System Debugging Tools
Table 12–1. Available Tools in the In-System Verification Tools Suite (Part 2 of 2)
Tool
Description
Typical Usage
Logic Analyzer
Interface (LAI)
This tool multiplexes a larger set of signals to a
smaller number of spare I/O pins. LAI allows you
to select which signals are switched onto the I/O
pins over a JTAG connection.
You have limited on-chip memory, and have a
large set of internal data buses that you would
like to verify using an external logic analyzer.
Logic analyzer vendors, such as Tektronics and
Agilent, provide integration with the tool to
improve the usability of the tool.
In-System Sources
and Probes
This tool provides an easy way to drive and
sample logic values to and from internal nodes
using the JTAG interface.
You want to prototype a front panel with virtual
buttons for your FPGA design.
In-System Memory
Content Editor
This tool displays and allows you to edit on-chip
memory.
You would like to view and edit the contents of
on-chip memory that is not connected to a
Nios II processor. You can also use the tool
when you do not want to have a Nios II debug
core in your system.
Virtual JTAG
Interface
This megafunction allows you to communicate
with the JTAG interface so that you can develop
your own custom applications.
You have custom signals in your design that you
want to be able to communicate with.
With the exception of SignalProbe, each of the on-chip debugging tools uses the JTAG
port to control and read back data from debugging logic and signals under test.
System Console uses JTAG and other interfaces as well. The JTAG resource is shared
among all of the on-chip debugging tools.
For all system debugging tools except System Console, the Quartus II software
compiles logic into your design automatically to distinguish between data and control
information and each of the debugging logic blocks when the JTAG resource is
required. This arbitration logic, also known as the System-Level Debugging (SLD)
infrastructure, is shown in the design hierarchy of your compiled project as
sld_hub:sld_hub_inst. The SLD logic allows you to instantiate multiple debugging
blocks into your design and run them simultaneously. For System Console, you must
explicitly insert IP cores into your design to enable debugging.
To maximize debugging closure, the Quartus II software allows you to use a
combination of the debugging tools in tandem to fully exercise and analyze the logic
under test. All of the tools described in Table 12–1 have basic analysis features built in;
that is, all of the tools enable you to read back information collected from the design
nodes that are connected to the debugging logic. Out of the set of debugging tools, the
SignalTap II Logic Analyzer, the LAI, and the SignalProbe feature are general purpose
debugging tools optimized for probing signals in your RTL netlist. In-System Sources
and Probes, the Virtual JTAG Interface, System Console, Transceiver Toolkit, and
In-System Memory Content Editor, in addition to being able to read back data from
the debugging points, allow you to input values into your design during runtime.
Taken together, the set of on-chip debugging tools form a debugging ecosystem. The
set of tools can generate a stimulus to and solicit a response from the logic under test,
providing a complete debugging solution (Figure 12–1).
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 13: System Debugging Tools Overview
System Debugging Tools
13–3
Figure 12–1. Quartus II Debugging Ecosystem (Note 1)
Quartus II Software
FPGA
JTAG
SignalTap II Logic Analyzer
In-System Memory Content Editor
Transceiver Toolkit - System Console
LAI
In-System Sources and Probes
In-System Memory Content Editor
VJI
Design
Under Test
Note to Figure 12–1:
(1) The set of debugging tools offer end-to-end debugging coverage.
The tools in the toolchain offer different advantages and different trade-offs. To
understand the selection criteria between the different tools, the following sections
analyze the tools according to their typical applications.
The first section, “Analysis Tools for RTL Nodes”, compares the SignalTap II Logic
Analyzer, SignalProbe, and the LAI. These three tools are logically grouped since they
are intended for debugging nodes from your RTL netlist at system speed.
The second section, “Stimulus-Capable Tools” on page 13–8, compares System
Console, In-System Memory Content Editor, Virtual JTAG Interface Megafunction,
and In-System Sources and Probes. These tools are logically grouped since they offer
the ability to both read and write transactions through the JTAG port.
Analysis Tools for RTL Nodes
The SignalTap II Logic Analyzer, the SignalProbe feature, and the LAI are designed
specifically for probing and debugging RTL signals at system speed. They are
general-purpose analysis tools that enable you to tap and analyze any routable node
from the FPGA or CPLD. If you have spare logic and memory resources, the
SignalTap II Logic Analyzer is useful for providing fast functional verification of your
design running on actual hardware.
Conversely, if logic and memory resources are tight and you require the large sample
depths associated with external logic analyzers, both the LAI and the SignalProbe
feature make it easy to view internal design signals using external equipment.
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
13–4
Chapter 13: System Debugging Tools Overview
System Debugging Tools
The most important selection criteria for these three tools are the available resources
remaining on your device after implementing your design and the number of spare
pins available. You should evaluate your preferred debugging option early on in the
design planning process to ensure that your board, your Quartus II project, and your
design are all set up to support the appropriate options. Planning early can reduce
time spent during debugging and eliminate the necessary late changes to
accommodate your preferred debugging methodologies. The following two sections
provide information to assist you in choosing the appropriate tool by comparing the
tools according to their resource usage and their pin consumption.
1
The SignalTap II Logic Analyzer is not supported on CPLDs, because there are no
memory resources available on these devices.
Resource Usage
Any debugging tool that requires the use of a JTAG connection requires the SLD
infrastructure logic mentioned earlier, for communication with the JTAG interface and
arbitration between any instantiated debugging modules. This overhead logic uses
around 200 logic elements (LEs), a small fraction of the resources available in any of
the supported devices. The overhead logic is shared between all available debugging
modules in your design. Both the SignalTap II Logic Analyzer and the LAI use a JTAG
connection.
SignalProbe requires very few on-chip resources. Because it requires no JTAG
connection, SignalProbe uses no logic or memory resources. SignalProbe uses only
routing resources to route an internal signal to a debugging test point.
The LAI requires a small amount of logic to implement the multiplexing function
between the signals under test, in addition to the SLD infrastructure logic. Because no
data samples are stored on the chip, the LAI uses no memory resources.
The SignalTap II Logic Analyzer requires both logic and memory resources. The
number of logic resources used depends on the number of signals tapped and the
complexity of the trigger logic. However, the amount of logic resources that the
SignalTap II Logic Analyzer uses is typically a small percentage of most designs. A
baseline configuration consisting of the SLD arbitration logic and a single node with
basic triggering logic contains approximately 300 to 400 Logic Elements (LEs). Each
additional node you add to the baseline configuration adds about 11 LEs. Compared
with logic resources, memory resources are a more important factor to consider for
your design. Memory usage can be significant and depends on how you configure
your SignalTap II Logic Analyzer instance to capture data and the sample depth that
your design requires for debugging. For the SignalTap II Logic Analyzer, there is the
added benefit of requiring no external equipment, as all of the triggering logic and
storage is on the chip.
Figure 12–2 shows a conceptual graph of the resource usage of the three analysis tools
relative to each other.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 13: System Debugging Tools Overview
System Debugging Tools
13–5
Figure 12–2.Resource Usage per Debugging Tool (Note 1)
Logic Analyzer
Interface
Logic
SignalTap II
Signal
Probe
Memory
Note to Figure 12–2:
(1) Though resource usage is highly dependent on the design, this graph provides a rough guideline for tool selection.
The resource estimation feature for the SignalTap II Logic Analyzer and the LAI
allows you to quickly judge if enough on-chip resources are available before
compiling the tool with your design. Figure 12–3 shows the resource estimation
feature for the SignalTap II Logic Analyzer and the LAI.
Figure 12–3.Resource Estimator
Pin Usage
The ratio of the number of pins used to the number of signals tapped for the
SignalProbe feature is one-to-one. Because this feature can consume free pins quickly,
a typical application for this feature is routing control signals to spare debugging pins
for debugging.
The ratio of the number of pins used to the number of signals tapped for the LAI is
many-to-one. It can map up to 256 signals to each debugging pin, depending on
available routing resources. The control of the active signals that are mapped to the
spare I/O pins is performed via the JTAG port. The LAI is ideal for routing data buses
to a set of test pins for analysis.
Other than the JTAG test pins, the SignalTap II Logic Analyzer uses no additional
pins. All data is buffered using on-chip memory and communicated to the
SignalTap II Logic Analyzer GUI via the JTAG test port.
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
13–6
Chapter 13: System Debugging Tools Overview
System Debugging Tools
Usability Enhancements
The SignalTap II Logic Analyzer, the SignalProbe feature, and the LAI tools can be
added to your existing design with minimal effects. With the node finder, you can find
signals to route to a debugging module without making any changes to your HDL
files. SignalProbe inserts signals directly from your post-fit database. The SignalTap II
Logic Analyzer and LAI support inserting signals from both pre-synthesis and post-fit
netlists. All three tools allow you to find and configure your debugging setup quickly.
In addition, the Quartus II incremental compilation feature and the Quartus II
incremental routing feature allow for a fast turnaround time for your programming
file, increasing productivity and enabling fast debugging closure.
Both LAI and the SignalTap II Logic Analyzer support incremental compilation. With
incremental compilation, you can add a SignalTap II Logic Analyzer instance or an
LAI instance incrementally into your placed-and-routed design. This has the benefit
of both preserving your timing and area optimizations from your existing design, and
decreasing the overall compilation time when any changes are necessary during the
debugging process. With incremental compilation, you can save up to 70% compile
time of a full compilation.
SignalProbe uses the incremental routing feature. The incremental routing feature
runs only the Fitter stage of the compilation. This also leaves your compiled design
untouched, except for the newly routed node or nodes. With SignalProbe, you can
save as much as 90% compile time of a full compilation.
As another productivity enhancement, all tools in the on-chip debugging tool set
support scripting via the quartus_stp Tcl package. For the SignalTap II Logic
Analyzer and the LAI, scripting enables user-defined automation for data collection
while debugging in the lab.
In addition, the JTAG server allows you to debug a design that is running on a device
attached to a PC in a remote location. This allows you to set up your hardware in the
lab environment, download any new .sof files, and perform any analysis from your
desktop.
Table 12–2 compares common debugging features between these tools and provides
suggestions about which is the best tool to use for a given feature.
Table 12–2.Suggested On-Chip Debugging Tools for Common Debugging Features (Part 1 of 2)
Feature
Large Sample
Depth
Ease in Debugging
Timing Issue
SignalProbe
Logic Analyzer
Interface
(LAI)
N/A
v
Quartus II Handbook Version 10.0 Volume 3: Verification
v
v
SignalTap II
Logic
Analyzer
(Note 1)
Description
—
An external logic analyzer used with the LAI has
a bigger buffer to store more captured data
than the SignalTap II Logic Analyzer. No data is
captured or stored with SignalProbe.
—
External equipment, such as oscilloscopes and
Mixed Signal Oscilloscopes (MSOs), can be
used with either LAI or SignalProbe. When
used with the LAI to provide you with access to
timing mode, you can debug combined streams
of data.
© July 2010 Altera Corporation
Chapter 13: System Debugging Tools Overview
System Debugging Tools
13–7
Table 12–2.Suggested On-Chip Debugging Tools for Common Debugging Features (Part 2 of 2)
Feature
SignalProbe
Minimal Effect
on Logic Design
Short Compile and
Recompile Time
Triggering
Capability
I/O Usage
Acquisition
Speed
v
Logic Analyzer
Interface
(LAI)
v(2)
SignalTap II
Logic
Analyzer
v (2)
SignalProbe attaches incrementally routed
signals to previously reserved pins, requiring
very little recompilation time to make changes
to source signal selections. The SignalTap II
Logic Analyzer and the LAI can take advantage
of incremental compilation to refit their own
design partitions to decrease recompilation
time.
v
v (2)
v (2)
N/A
N/A
v
The SignalTap II Logic Analyzer offers
triggering capabilities that are comparable to
commercial logic analyzers.
—
—
v
No additional output pins are required with the
SignalTap II Logic Analyzer. Both the LAI and
SignalProbe require I/O pin assignments.
v
The SignalTap II Logic Analyzer can acquire
data at speeds of over 200 MHz. The same
acquisition speeds are obtainable with an
external logic analyzer used with the LAI, but
may be limited by signal integrity issues.
—
An FPGA design with the SignalTap II Logic
Analyzer or the LAI requires an active JTAG
connection to a host running the Quartus II
software. SignalProbe does not require a host
for debugging purposes.
v
The SignalTap II Logic Analyzer logic is
completely internal to the programmed FPGA
device. No extra equipment is required other
than a JTAG connection from a host running
the Quartus II software or the stand-alone
SignalTap II Logic Analyzer software.
SignalProbe and the LAI require the use of
external debugging equipment, such as
multimeters, oscilloscopes, or logic analyzers.
N/A
—
v
—
Required
No External
Equipment Required
Description
The LAI adds minimal logic to a design,
requiring fewer device resources. The
SignalTap II Logic Analyzer has little effect on
the design, because it is set as a separate
design partition. SignalProbe incrementally
routes nodes to pins, not affecting the design at
all.
No JTAG
Connection
(Note 1)
—
—
Notes to Table 12–2:
(1) v indicates the recommended tools for the feature.
— indicates that while the tool is available for that feature, that tool may not give the best results.
N/A indicates that the feature is not applicable for the selected tool.
(2) When used with incremental compilation.
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
13–8
Chapter 13: System Debugging Tools Overview
System Debugging Tools
Stimulus-Capable Tools
The In-System Memory Content Editor, the In-System Sources and Probes, and the
Virtual JTAG interface each enable you to use the JTAG interface as a general-purpose
communication port. Though all three tools can be used to achieve the same results,
there are some considerations that make one tool easier to use in certain applications
than others. In-System Sources and Probes is ideal for toggling control signals. The
In-System Memory Content Editor is useful for inputting large sets of test data.
Finally, the Virtual JTAG interface is well suited for more advanced users who want to
develop their own customized JTAG solution.
System Console provides system-level debugging at a transaction level, such as with
Avalon-MM slave or Avalon-ST interfaces. You can communicate to a chip through
JTAG, PLI connectivity for simulation models, and TCP/IP protocols. System Console
is a Tcl console that you use to communicate with hardware modules that you have
instantiated into your design.
In-System Sources and Probes
In-System Sources and Probes is an easy way to access JTAG resources to both read
and write to your design. You can start by instantiating a megafunction into your
HDL code. The megafunction contains source ports and probe ports for driving
values into and sampling values from the signals that are connected to the ports,
respectively. Transaction details of the JTAG interface are abstracted away by the
megafunction. During runtime, a GUI displays each source and probe port by
instance and allows you to read from each probe port and drive to each source port.
The GUI makes this tool ideal for toggling a set of control signals during the
debugging process.
A good application of In-System Sources and Probes is to use the GUI as a
replacement for the push buttons and LEDs used during the development phase of a
project. Furthermore, In-System Sources and Probes supports a set of scripting
commands for reading and writing using quartus_stp. When used with the Tk
toolkit, you can build your own graphical interfaces. This feature is ideal for building
a virtual front panel during the prototyping phase of the design.
In-System Memory Content Editor
The In-System Memory Content Editor allows you to quickly view and modify
memory content either through a GUI interface or through Tcl scripting commands.
The In-System Memory Content Editor works by turning single-port RAM blocks into
dual-port RAM blocks. One port is connected to your clock domain and data signals,
and the other port is connected to the JTAG clock and data signals for editing or
viewing.
Because you can modify a large set of data easily, a useful application for the
In-System Memory Content Editor is to generate test vectors for your design. For
example, you can instantiate a free memory block, connect the output ports to the
logic under test (using the same clock as your logic under test on the system side), and
create the glue logic for the address generation and control of the memory. At
runtime, you can modify the contents of the memory using either a script or the
In-System Memory Content Editor GUI and perform a burst transaction of the data
contents in the modified RAM block synchronous to the logic being tested.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 13: System Debugging Tools Overview
Conclusion
13–9
Virtual JTAG Interface Megafunction
The Virtual JTAG Interface megafunction provides the finest level of granularity for
manipulating the JTAG resource. This megafunction allows you to build your own
JTAG scan chain by exposing all of the JTAG control signals and configuring your
JTAG Instruction Registers (IRs) and JTAG Data Registers (DRs). During runtime, you
control the IR/DR chain through a Tcl API, or with System Console. This feature is
meant for users who have a thorough understanding of the JTAG interface and want
precise control over the number and type of resources used.
System Console
System Console is a framework that you can launch from the Quartus II software to
start services for performing different kinds of tasks. System Console provides you
with Tcl scripts and a GUI to access SOPC Builder modules to perform low-level
hardware debugging of your design, as well as identify a module by its path, and
open and close a connection to an SOPC module. You can access your design at a
system level for purposes of loading, unloading, and transferring designs to multiple
devices.
System Console also allows you to access commands that allow you to control how
you generate test patterns, as well as verify the accuracy of data generated by test
patterns. You can use JTAG debug commands in System Console to verify the
functionality and signal integrity of your JTAG chain. You can test clock and reset
signals.
You can use System Console to access programmable logic devices on your
development board, as well as bring up a board and verify stages of setup. You can
also access software running on a Nios II processor, as well as access modules that
produce or consume a stream of bytes.
Transceiver Toolkit runs from the System Console framework, and allows you to run
automatic tests of your transceiver links for debugging and optimizing your
transceiver designs. You can use the Transceiver Toolkit GUI to set up channel links in
your transceiver devices, and then automatically run Eye-Q and Auto Sweep testing
to view a graphical representation of your test data.
Conclusion
The Quartus II on-chip debugging tool suite allows you to reach debugging closure
quickly by providing you a with set of powerful analysis tools and a set of tools that
open up the JTAG port as a general purpose communication interface. The Quartus II
software further broadens the scope of applications by giving you a comprehensive
Tcl/Tk API. With the Tcl/Tk API, you can increase the level of automation for all of
the analysis tools. You can also build virtual front panel applications quickly during
the early prototyping phase.
In addition, all of the on-chip debugging tools have a tight integration with the rest of
the productivity features within the Quartus II software. The incremental compilation
and incremental routing features enable a fast turnaround time for programming file
generation. The cross-probing feature allows you to find and identify nodes quickly.
The SignalTap II Logic Analyzer, when used with the TimeQuest Timing Analyzer, is
a best-in-class timing verification suite that allows fast functional and timing
verification.
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
13–10
Chapter 13: System Debugging Tools Overview
Document Revision History
Document Revision History
Table 12–3shows the revision history for this application note.
Table 12–3. Document Revision History
Date
July 2010
Version
10.0.0
Changes Made
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.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
14. Analyzing and Debugging Designs
with the System Console
QII53028-10.0.0
The System Console performs low-level hardware debugging of SOPC Builder
systems. You can use the System Console to access IP cores instantiated in your SOPC
Builder system, and for initial bring-up of your printed circuit board and low-level
testing. You access the System Console by clicking Tools on the main menu of SOPC
Builder, and then clicking System Console.You can use the System Console in
command-line mode or with the GUI.
Command-line mode allows you to run Tcl scripts from the Tcl Console pane, located
in the System Console window. You can also run Tcl scripts from the System Console
GUI.
The System Console GUI allows you to view a main window with separate panes,
including System Explorer, TCL Console, Messages, and Tools panes.
f
For further details on how to use the System Console GUI, refer to About Console in
Quartus II Help.
This chapter contains the following sections:
■
“Setting Up the System Console”
■
“Interactive Help”
■
“Using the System Console” on page 14–2
■
“System Console Examples” on page 14–17
■
“Device Support” on page 14–26
Setting Up the System Console
You set up the System Console according to the hardware you have available in your
system. You can access available debugging IP on your system with the System
Console. The debug IP allows you to access the running state of your system. The
following sections discuss setting up and using debug IP in further detail.
“System Console Examples” on page 14–17 provides you with detailed examples of
using the System Console in conjunction with SOPC Builder components. You can
download the design examples described in this section from the Altera® website.
These design examples demonstrate how to add debug IP blocks to your design and
how to connect them before you can use the host application.
Interactive Help
Typing help help into the System Console lists all available commands. Typing
help <command name> provides the syntax of individual commands. The System
Console provides command completion if you type the beginning letters of a
command and then press the Tab key.
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
14–2
Chapter 14: Analyzing and Debugging Designs with the System Console
Using the System Console
1
The System Console interactive help commands only provide help for enabled
services; consequently, typing help help does not display help for a plug-in unless
you have enabled it.
Using the System Console
The Quartus® II software expands the framework of the System Console by allowing
you to start services for performing different types of tasks, as described in the
following paragraphs of this chapter. These paragraphs provide Tcl scripting
commands, arguments, and a brief description of the command functions.
1
Many of the System Console commands do not work unless you connect to a system
with a programming cable and with the proper debug IP.
SOPC Builder Communications
Table 14–1 describes four SOPC Builder components you can use to facilitate
debugging with the System Console. When connected to the System Console, these
components enable you to send commands and receive data..
Table 14–1. SOPC Builder Components for Communication with the System Console (Note 1)
Component Name
Debugs Components with the Following Interface Types
The Nios® II processor with JTAG debug
enabled
Components that include an Avalon® Memory-Mapped (Avalon-MM)
slave interface. The JTAG debug module can also control the Nios II
processor for debug functionality, including starting, stopping, and
stepping the processor.
JTAG to Avalon master bridge
Components that include an Avalon-MM slave interface
Avalon Streaming (Avalon-ST) JTAG Interface
Components that include an Avalon-ST interface
JTAG UART
The JTAG UART is an Avalon-MM slave device that can be used in
conjunction with the System Console to send and receive byte streams.
Note to Table 14–1:
(1) The System Console can also send and receive byte streams from any SLD node whether it is instantiated in SOPC Builder component provided
by Altera®, a custom component, or part of your Quartus II project; however, this approach requires detailed knowledge of the JTAG commands.
f
For further information about SOPC Builder components, refer to the following web
pages and documents:
■
The Nios II Processor product web page
■
SPI Slave/JTAG to Avalon Master Bridge Cores chapter in volume 5 of the Quartus II
Handbook
■
Avalon-ST JTAG Interface Core chapter in volume 5 of the Quartus II Handbook
■
SLD Virtual JTAG MegaFunction User Guide
■
JTAG UART Core chapter in volume 5 of the Quartus II Handbook
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 14: Analyzing and Debugging Designs with the System Console
Using the System Console
14–3
Figure 14–1 illustrates examples of interfaces of the components that the System
Console can use.
Figure 14–1. Example Interfaces (Paths) the System Console Can Use to Send Commands
Connections You Make
in SOPC Builder
Transparent Connections
Nios II Processor
Avalon-MM
Master
JTAG Avalon Master Bridge
User Component
Avalon-MM
Slave
Virtual JTAG
Interface
or
Avalon-MM
Master
Virtual JTAG
Interface
Avalon-ST JTAG Interface
User Component
Avalon-ST
Source
and Sink
Avalon-ST
Source and
Sink
Quartus II JTAG Logic
Virtual
JTAG Hub
(Soft IP)
JTAG TAP
Controller
(Hard IP)
To
Host PC
Running
System Console
Virtual JTAG
Interface
JTAG UART
Avalon-MM
Slave
Legacy
JTAG
Interface
Altera recommends that you also include the following components in your system:
■
On-chip memory
■
JTAG UART
■
System ID core
The System Console provides many different types of services. Different modules can
provide the same type of service. For example, both the Nios II processor and the
JTAG to Avalon Bridge master provide the master service; consequently, you can use
the master commands to access both of these modules.
If your system includes a Nios II/f core with a data cache it may complicate the
debugging process. If you suspect that writes to memory from the data cache at
nondeterministic intervals are overwriting data written by the System Console, you
can disable the cache of the Nios II/f core while debugging.
You can start the System Console from a Nios II command shell.
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
14–4
Chapter 14: Analyzing and Debugging Designs with the System Console
Using the System Console
1. Choose All Programs > Altera > Nios II EDS <version> Command Shell
(Windows Start menu) to run a Nios II command shell.
2. To start the System Console, type the following command:
system-console r
You can customize your System Console environment by adding commands to the
configuration file called system_console_rc.tcl. This file can be located in either of
two places:
■
<quartus_install_dir>/sopc_builder/system_console_macros/system_console_rc.tcl,
known as the global configuration file, which affects all users of the system
■
<$HOME>/system_console/system_console_rc.tcl, known as the user
configuration file, which only affects the owner of that home directory
On startup, the System Console automatically runs any Tcl commands in these files.
The commands in the global configuration file runs first, followed by the commands
in the user configuration file.
Console Commands
The console commands enable testing. You can use console commands to identify a
module by its path, and to open and close a connection to it. The path that identifies
a module is the first argument to most of the other System Console commands. To
exercise a module, follow these steps:
1. Identify a module by specifying the path to it, using the get_service_paths
command.
2. Open a connection to the module using the open_service command.
3. Run Tcl and System Console commands to use a debug module that you insert to
test another module of interest.
4. Close a connection to a module using the close_service command.
Table 14–2 describes the syntax of the console commands.
Table 14–2. Console Commands (Part 1 of 2)
Command
Arguments
Function
-
Returns a list of service types that the System Console
manages. Examples of service types include master,
bytestream, processor, sld, jtag_debug, device, and
plug-in.
get_service_types
get_service_paths
<service_type_name>
Returns a list of paths to nodes that implement the
requested service type.
open_service
<service_type_name>
<service_path>
Opens the service type specified.
close_service
<service_type_name>
<service_path>
Closes the service type specified.
is_service_open
<service_type_name>
<service_path>
Returns 1 if the service type provided by the path is
open, 0 if the service type is closed.
get_services_to_add
-
Returns a list of all services that are instantiable with the
add_service command.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 14: Analyzing and Debugging Designs with the System Console
Using the System Console
14–5
Table 14–2. Console Commands (Part 2 of 2)
Command
add_service
Arguments
Function
<service-type>
<instance-name>
<optional-parameters>
Add a service of the specified service type with the given
instance name. Run get_services_to_add to retrieve a
list of instantiable services. This command returns the
path where the service was added.
Run help add_service <service-type> to get specific
help about that service-type, including any arguments
that might be required for that service.
get_version
-
Returns the current System Console version and build
number.
add_help
<command>
<help-text>
Adds help text for a given command. Use this when you
write a Tcl script and then want to provide help for
others to use the script.
Plug-ins
Plug-in commands allow you to customize how you use the System Console services,
and are enabled by default. Table 14–3 lists Plug-in commands.
Table 14–3. Plug-in Commands
Command
Arguments
Function
Plug-in Service Type Commands
plugin_enable
<plugin-path>
Enables the plug-in specified by the path.
After a plug-in is enabled, you can retrieve
the <service-path> and
<service_type_name> for additional
services using the
get_service_paths and
get_service_types commands,
respectively.
plugin_disable
<plugin-path>
Disables the plug-in specified by the path.
is_plugin_enabled
<plugin-path>
Returns a non-zero value when the plug-in
at the specified path is enabled.
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
14–6
Chapter 14: Analyzing and Debugging Designs with the System Console
Using the System Console
Design Service Commands
Design Service commands allow you to use the System Console services to load and
work with your design at a system level. Table 14–4 lists Design Service commands.
Table 14–4. Design Service Commands
Command
Arguments
Function
Loads a model of a Quartus II design into
the System Console. For example, if your
.qpf file is in c:/projects/loopback, type the
following command: design_load
design_load
<quartus-project-path>
or
<qpf-file-path>
design_instantiate
<design-path>
<instance-name>
Allows you to apply the same design to
multiple devices.
design_link
<design-instance-path>
<device-service-path>
Links a Quartus II logical design with a
physical device. For example, you can link a
Quartus II design called
2c35_quartus_design to a 2c35 device.
After you create this link, the System
Console creates the appropriate
correspondences between the logical and
physical submodules of the Quartus II
project. Example 14–1 on page 14–17
shows a transcript illustrating the
design_load and design_link
commands.
{c:\projects\loopback\}
Note that the System Console does not
verify that the link is valid, so that if you
create an incorrect link, the System
Console does not report an error.
Data Pattern Generator Commands
Data Pattern Generator commands allow you control data patterns that you generate
for testing, debugging, and optimizing your design. You must first insert debug IP to
enable these commands.Table 14–5 lists Data Pattern Generator commands.
Table 14–5. Data Pattern Generator Commands (Part 1 of 3)
Command
Arguments
Function
data_pattern_generator_start
<service-path>
Starts the data pattern
generator.
data_pattern_generator_stop
<service-path>
Stops the data pattern
generator.
data_pattern_generator_is_generating
<service-path>
Returns non-zero if the
generator is running.
data_pattern_generator_inject_error
<service-path>
Injects a 1-bit error into
the generator's output.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 14: Analyzing and Debugging Designs with the System Console
Using the System Console
14–7
Table 14–5. Data Pattern Generator Commands (Part 2 of 3)
Command
data_pattern_generator_set_pattern
Arguments
<service-path>
<pattern-name>
Function
Sets the output pattern
specified by the
<pattern-name>. In
all, 6 patterns are
available, 4 are
pseudo-random binary
sequences (PRBS) and
2 are high and low
frequency. The
following pattern names
are defined:
■
PRBS7
■
PRBS15
■
PRBS23
■
PRBS31
■
HF–outputs a high
frequency, constant
pattern of alternating
0s and 1s
■
LF–outputs a low
frequency, constant
pattern of
10b’1111100000 for
10-bit symbols and
8b’11110000 for
8-bit symbols
data_pattern_generator_get_pattern
<service-path>
Returns currently
selected output pattern.
data_pattern_generator_get_available_patterns
<service-path>
Returns a list of
available data patterns
by name.
data_pattern_generator_enable_preamble
<service-path>
Enables the preamble
mode at the beginning
of generation.
data_pattern_generator_disable_preamble
<service-path>
Disables the preamble
mode at the beginning
of generation.
data_pattern_generator_is_preamble_enabled
<service-path>
Returns a non-zero
value if preamble mode
is enabled.
data_pattern_generator_set_preamble_word
<service-path>
<preamble-word>
Sets the preamble word.
(Could be 32-bit or
40-bit).
data_pattern_generator_get_preamble_word
<service-path>
Gets the preamble
word.
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
14–8
Chapter 14: Analyzing and Debugging Designs with the System Console
Using the System Console
Table 14–5. Data Pattern Generator Commands (Part 3 of 3)
Command
Arguments
Function
data_pattern_generator_set_preamble_beats
<service-path>
<number-of-prea
mble-beats>
Sets the number of
beats to send out the in
the preamble word.
data_pattern_generator_get_preamble_beats
<service-path>
Returns the currently
set number of beats to
send out in the
preamble word.
Data Pattern Checker Commands
Data Pattern Checker commands allow you verify the data patterns that you generate.
You must first insert debug IP to enable these commands. Table 14–6 lists Data Pattern
Checker commands.
Table 14–6. Data Pattern Checker Commands
Command
Arguments
data_pattern_checker_start
<service-path>
Starts the data pattern
checker.
data_pattern_checker_stop
<service-path>
Stops the data pattern
checker.
data_pattern_checker_is_checking
<service-path>
Returns a non-zero
value if the checker is
running.
data_pattern_checker_is_locked
<service-path>
Returns non-zero if the
checker is locked onto
the incoming data.
data_pattern_checker_set_pattern
<service-path>
<pattern-name>
Sets the expected
pattern to the one
specified by the
<pattern-name>.
data_pattern_checker_get_pattern
<service-path>
Returns the currently
selected expected
pattern by name.
data_pattern_checker_get_available_patterns
<service-path>
Returns a list of
available data patterns
by name.
data_pattern_checker_get_data
<service-path>
Returns the correct and
incorrect_counts
_of_data received,
providing the number of
bits and the number of
errors.
data_pattern_checker_reset_counters
<service-path>
Resets the bit and error
counters inside the
checker.
Quartus II Handbook Version 10.0 Volume 3: Verification
Function
© July 2010 Altera Corporation
Chapter 14: Analyzing and Debugging Designs with the System Console
Using the System Console
14–9
Programmable Logic Device (PLD) Commands
The PLD commands provide access to programmable logic devices on your board.
Before using these commands, you must identify the path to the programmable logic
device on your board using the get_service_paths command described in
Table 14–2.
Table 14–7 describes the PLD commands.
Table 14–7. PLD Commands
Command
Arguments
Function
device_download_sof
<device_path>
<sof_file>
This command loads the specified SRAM object file
(.sof) file to the device specified by the path.
device_load_jdi
<device_path>
<jdi_file>
This command renames the Tcl interface layer's
nodes to the names specified in the JTAG debug
interface (.jdi) file, making your design easier to
understand.
Board Bring-Up Commands
The board bring-up commands allow you to test your system. These commands are
presented in the order that you would use them during board bring-up, including the
following setup work flow:
1. Verify JTAG connectivity
2. Verify the clock and reset signals
3. Verify memory and other peripheral interfaces
4. Verify basic Nios II processor functionality
1
The System Console is intended for debugging the basic hardware functionality of
your Nios II processor, including its memories and pinout. Once the hardware is
functioning correctly, you can refer to the Nios II Software Build Tool Reference in the
Nios II Software Developer’s Handbook for further software debugging. If you are writing
device drivers, you may want to use the System Console and the Nios II software
build tools together to debug your code.
JTAG Debug Commands
You can use these commands to verify the functionality and signal integrity of your
JTAG chain. Your JTAG chain must be functioning correctly to debug the rest of your
system. To verify signal integrity of your JTAG chain, Altera recommends that you
provide an extensive list of byte values. Table 14–8 lists these commands.
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
14–10
Chapter 14: Analyzing and Debugging Designs with the System Console
Using the System Console
Table 14–8. JTAG Commands
Command
jtag_debug_loop
jtag_debug_rese
t_system
Arguments
Function
values>
Loops the specified list of bytes through a loopback of tdi and
tdo of a system-level debug (SLD) node. Returns the list of byte
values in the order that they were received. Blocks until all bytes
are received. Byte values are given with the 0x (hexadecimal)
prefix and delineated by spaces.
<service-path>
Issues a reset request to the system.
<path>
<list_of_byte_
Clock and Reset Signal Commands
The next stage of board bring-up tests the clock and reset signals. Table 14–9 lists the
three commands to verify these signals. You can use these commands to verify that
your clock is toggling and that the reset signal has the expected value.
Table 14–9. Clock and Reset Commands
Command
Argument
Function
jtag_debug_sample_clock <service-path>
Returns the value of the clock signal of the system clock that
drives the module's system interface. The clock value is
sampled asynchronously; consequently, you may need to
sample the clock several times to guarantee that it is
toggling.
jtag_debug_sample_reset <service-path>
Returns the value of the reset signal of the system reset that
drives the module's system interface.
jtag_debug_sense_clock
Returns the result of a sticky bit that monitors for system
clock activity. If the clock has ever toggled, the bit is 1.
Returns true if the bit has ever toggled and otherwise
returns false. The sticky bit is reset to 0 on read.
<service-path>
Avalon-MM Commands
These commands allow you to access the memory-mapped or SLD modules that
include Avalon-ST slave interfaces. You can read or write the Avalon-MM interfaces
using the master read and write commands, but the Avalon-MM Slave must be
connected to an Avalon MM-Master that you can control from the host.
PLI Master commands listed in Table 14–12 provide bytestream and master services
over a PLI connection to a simulator. TCL Master commands provide bytestream and
master services over TCP IP.
Additionally, you can use the SLD commands to shift values into the instruction and
data registers of SLD nodes and read the previous value. Table 14–10 lists these
commands.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 14: Analyzing and Debugging Designs with the System Console
Using the System Console
14–11
Table 14–10. Module Commands (Note 1)
Command
Arguments
Function
Avalon-MM Master Commands
master_write_memory <service-path>
<address>
<list_of_byte_values>
master_write_8
<service-path>
<address>
<list_of_byte_values>
master_write_16
<service-path>
<address>
<list_of_16_bit_words>
master_write_32
<service-path>
<address>
<list_of_32_bit_words>
master_read_memory
<service-path>
<base_address>
<size_in_bytes>
master_read_8
<service-path>
<base_address>
<size_in_bytes>
master_read_16
<service-path>
<base_address>
<size_in_multiples_of_
16_bits>
master_read_32
<service-path>
<base_address>
<size_in_multiples_of_
32_bits>
Writes the specified data to the specified path and
address. Values are given in hexadecimal format with
the 0x prefix and delineated by spaces.
Returns a list of read values.
SLD Commands
sld_access_ir
<service-path> <value>
<timeout> (in µseconds)
Shifts the instruction value into the instruction register
of the specified node. Returns the previous value of the
instruction. If the timeout value is set to 0, the operation
never times out. A suggested starting value for
timeout is 1000 µseconds.
sld_access_dr
<service-path>
<size_in_bits>
<timeout> (in µseconds),
<list_of_byte_values>
Shifts the byte values into the data register of the SLD
node up to the size in bits specified. If the timeout
value is set to 0, the operation never times out. Returns
the previous contents of the data register. A suggested
starting value for timeout is 1000 µseconds.
sld_lock
sld_lock
<service-path>
<timeout> (in mseconds)
Locks the SLD chain to guarantee exclusive access. If
the SLD chain is already locked, tries for <timeout>
mseconds before returning -1, indicating an error.
Returns 0 if successful.
sld_unlock
sld_unlock
<service-path>
Unlocks the SLD chain.
Note to Table 14–10:
(1) Transfers performed in 16- and 32-bit sizes are packed in little endian format.
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
14–12
Chapter 14: Analyzing and Debugging Designs with the System Console
Using the System Console
Processor Commands
These commands allow you to start, stop, and step through software running on a
Nios II processor. They also allow you to read and write the processor’s registers.
Table 14–11 lists the commands.
Table 14–11. Processor Commands
Command
Arguments
elf_download
<processor-servicepath>
<master-service-pat
h>
<elf-file-path>
Function
Downloads the given executable and loadable format
(ELF) file to memory using the specified master
service. Sets the processor's program counter to the
.elf entry point.
processor_in_debug_mod <service-path>
e
Returns a non-zero value if the processor is in debug
mode.
processor_reset
<service-path>
Resets the processor and places it in debug mode.
processor_run
<service-path>
Puts the processor into existing debug mode.
processor_stop
<service-path>
Puts the processor into debug mode.
processor_step
<service-path>
Executes one assembly instruction.
processor_get_register <service-path>
_names
Returns a list with the names of all of the processor's
accessible registers.
processor_get_register <service-path>
<register_name>
Returns the value of the specified register.
processor_set_register <service-path>
<register_name>
Sets the value of the specified register.
Bytestream Commands
These commands provide access to modules that produce or consume a stream of
bytes. You can use the bytestream service to communicate directly to IP that provides
bytestream interfaces, such as the Altera JTAG UART. Table 14–12 lists the commands.
Table 14–12. Bytestream Commands
Command
Arguments
Function
bytestream_send
<service-path>
<list_of_byte_values>
Sends the list of byte values on the specified path.
Values are in hexadecimal format and delineated by
spaces.
bytestream_receive
<service-path>
<number_of_bytes>
Limits the maximum number of bytes to return.
Transceiver Toolkit Commands
You run the Transceiver Toolkit from the System Console window. Alternatively, you
can open the Transceiver Toolkit from the Tools menu in the Quartus II software. You
can debug, monitor, and optimize the transceiver channel links in your design with
either Tcl scripts, or you can launch the Transceiver Toolkit GUI from the System
Console Tools menu. The GUI for the Transceiver Toolkit provides a graphical
representation of automatic tests that you run. It also presents graphical control
panels to change PMA settings of channels, start and stop generators, and checkers.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 14: Analyzing and Debugging Designs with the System Console
Using the System Console
14–13
Table 14–13 through Table 14–17 lists the Transceiver Toolkit commands..
Table 14–13. Transceiver Toolkit Channel_rx Commands
Command
Arguments
Function
transceiver_channel_rx_get_data
<service-path>
Returns a list of the current
checker data.The results are in
the order: number of bits,
number of errors, bit error rate.
transceiver_channel_rx_get_dcgain
<service-path>
Gets the DC gain value on the
receiver channel.
transceiver_channel_rx_get_eqctrl
<service-path>
Gets the equalization control
value on the receiver channel.
transceiver_channel_rx_get_pattern
<service-path>
Returns the current data
checker pattern by name.
transceiver_channel_rx_is_checking
<service-path>
Returns non-zero if the checker
is running.
transceiver_channel_rx_is_locked
<service-path>
Returns non-zero if the checker
is locked onto the incoming
data.
transceiver_channel_rx_reset_counters
<service-path>
Resets the bit and error
counters inside the checker.
transceiver_channel_rx_set_dcgain
<service-path>
Sets the DC gain value on the
receiver channel.
<dc_gain
setting>
transceiver_channel_rx_set_eqctrl
<service-path>
<eqctrl
setting>
Sets the equalization control
value on the receiver channel.
transceiver_channel_rx_start_checking
<service-path>
Starts the checker.
transceiver_channel_rx_stop_checking
<service-path>
Stops the checker.
transceiver_channel_rx_get_eyeq_phase_step <service-path>
Get the current phase step of
the specified channel.
transceiver_channel_rx_is_eyeq_enabled
<service-path>
Get whether the EyeQ feature is
enabled on the specified
channel.
transceiver_channel_rx_set_eyeq_enabled
<service-path> Enable/disable the EyeQ feature
<disable(0)/ena on the specified channel.
ble(1)>
transceiver_channel_rx_set_eyeq_phase_step <service-path>
<phase step>
Set the phase step of the
specified channel.
transceiver_channel_rx_set_word_aligner_en <service-path> Enable/disable the word aligner
abled
<disable(0)/ena of the specified channel.
ble(1)>
transceiver_channel_rx_is_word_aligner_ena <service-path> Enable/disable the word aligner
bled
<disable(0)/ena of the specified channel.
ble(1)>
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
14–14
Chapter 14: Analyzing and Debugging Designs with the System Console
Using the System Console
Table 14–14. Transceiver Toolkit Channel _tx Commands (Part 1 of 2)
Command
Arguments
Function
transceiver_channel_tx_disable_preamble
<service-path>
Disables the preamble mode at
the beginning of generation.
transceiver_channel_tx_enable_preamble
<service-path>
Enables the preamble mode at
the beginning of generation.
transceiver_channel_tx_get_number_of_pream <service-path>
ble_beats
Returns the number of
preamble beats.
transceiver_channel_tx_get_pattern
<service-path>
Returns the currently set
pattern.
transceiver_channel_tx_get_preamble_word
<service-path>
Returns the currently set
preamble word.
transceiver_channel_tx_get_preemph0t
<service-path>
Gets the pre-emphasis pre-tap
value on the transmitter
channel.
transceiver_channel_tx_get_preemph1t
<service-path>
Gets the pre-emphasis first
post-tap value on the
transmitter channel.
transceiver_channel_tx_get_preemph2t
<service-path>
Gets the pre-emphasis second
post-tap value on the
transmitter channel.
transceiver_channel_tx_get_vodctrl
<service-path>
Gets the VOD control value on
the transmitter channel.
transceiver_channel_tx_inject_error
<service-path>
Injects a 1-bit error into the
generator's output.
transceiver_channel_tx_is_generating
<service-path>
Returns non-zero if the
generator is running.
transceiver_channel_tx_is_preamble_enabled <service-path>
Returns non-zero if preamble
mode is enabled.
transceiver_channel_tx_set_number_of_pream <service-path> Sets the number of beats to
ble_beats
<number-of-prea send out the preamble word.
mble-beats>
Sets the output pattern to the
one specified by the pattern
name.
transceiver_channel_tx_set_pattern
<service-path>
<pattern-name>
transceiver_channel_tx_set_preamble_word
<service-path> Sets the preamble word to be
<preamble-word> sent out.
transceiver_channel_tx_set_preemph0t
<service-path>
<preemph0t
value>
transceiver_channel_tx_set_preemph1t
<service-path>
<preemph1t
value>
transceiver_channel_tx_set_preemph2t
<service-path>
<preemph2t
value>
Quartus II Handbook Version 10.0 Volume 3: Verification
Sets the pre-emphasis pre-tap
value on the transmitter
channel.
Sets the pre-emphasis first
post-tap value on the
transmitter channel.
Sets the pre-emphasis second
post-tap value on the
transmitter channel.
© July 2010 Altera Corporation
Chapter 14: Analyzing and Debugging Designs with the System Console
Using the System Console
14–15
Table 14–14. Transceiver Toolkit Channel _tx Commands (Part 2 of 2)
Command
transceiver_channel_tx_set_vodctrl
Arguments
Function
Sets the VOD control value on
<vodctrl value> the transmitter channel.
<service-path>
transceiver_channel_tx_start_generation
<service-path>
Starts the generator.
transceiver_channel_tx_stop_generation
<service-path>
Stops the generator.
Table 14–15. Transceiver Toolkit Debug_Link Commands
Command
Arguments
Function
transceiver_debug_link_get_pattern
<service-path>
Gets the currently set pattern
the link uses to run the test.
transceiver_debug_link_is_running
<service-path>
Returns non-zero if the test is
running on the link.
transceiver_debug_link_set_pattern
<service-path>< Sets the pattern the link uses to
data pattern>
run the test.
transceiver_debug_link_start_running
<service-path>
Starts running a test with the
currently selected test pattern.
transceiver_debugf_link_stop_running
<service-path>
Stops running the test.
Table 14–16. Transceiver Toolkit Reconfig_analog Commands (Part 1 of 2)
Command
Arguments
Function
transceiver_reconfig_analog_get_logical_ch <service-path>
annel_address
Gets the transceiver logical
channel address currently set.
transceiver_reconfig_analog_get_rx_dcgain
<service-path>
Gets the DC gain value on the
receiver channel specified by
the current logical channel
address.
transceiver_reconfig_analog_get_rx_eqctrl
<service-path>
Gets the equalization control
value on the receiver channel
specified by the current logical
channel address.
transceiver_reconfig_analog_get_tx_preemph <service-path>
0t
Gets the pre-emphasis pre-tap
value on the transmitter
channel specified by the current
logical channel address.
transceiver_reconfig_analog_get_tx_preemph <service-path>
1t
Gets the pre-emphasis first
post-tap value on the
transmitter channel specified
by the current logical channel
address.
transceiver_reconfig_analog_get_tx_preemph <service-path>
2t
Gets the pre-emphasis second
post-tap value on the
transmitter channel specified
by the current logical channel
address.
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
14–16
Chapter 14: Analyzing and Debugging Designs with the System Console
Using the System Console
Table 14–16. Transceiver Toolkit Reconfig_analog Commands (Part 2 of 2)
Command
Arguments
Function
transceiver_reconfig_analog_get_tx_vodctrl <service-path>
Gets the VOD control value on
the transmitter channel
specified by the current logical
channel address.
transceiver_reconfig_analog_set_logical_ch <service-path>
annel_address
<logical
channel
address>
Sets the transceiver logical
channel address.
transceiver_reconfig_analog_set_rx_dcgain
Sets the transceiver logical
<dc_gain value> channel address.
<service-path>
<eqctrl value>
Sets the equalization control
value on the receiver channel
specified by the current logical
channel address.
transceiver_reconfig_analog_set_tx_preemph <service-path>
0t
<preemph0t
value>
Sets the pre-emphasis pre-tap
value on the transmitter
channel specified by the current
logical channel address.
transceiver_reconfig_analog_set_tx_preemph <service-path>
1t
<preemph1t
value>
Sets the pre-emphasis first
post-tap value on the
transmitter channel specified
by the current logical channel
address.
transceiver_reconfig_analog_set_tx_preemph <service-path>
2t
<preemph2t
value>
Sets the pre-emphasis second
post-tap value on the
transmitter channel specified
by the current logical channel
address.
transceiver_reconfig_analog_set_rx_eqctrl
<service-path>
Sets the VOD control value on
<vodctrl value> the transmitter channel
specified by the current logical
channel address.
transceiver_reconfig_analog_set_tx_vodctrl <service-path>
Table 14–17. Eye Monitor Tcl Commands (Part 1 of 2)
Command
Arguments
Function
alt_xcvr_custom_is_word_aligner_enabled
<service-path> Enable/disable the word aligner
<disable(0)/ena of the previously specified
channel.
ble(1)>
alt_xcvr_custom_set_word_aligner_enabled
Enable/disable the word aligner
<disable(0)/ena of the previously specified
channel.
ble(1)>
<service-path>
alt_xcvr_reconfig_eye_viewer_get_logical_c <service-path>
hannel_address
Quartus II Handbook Version 10.0 Volume 3: Verification
Gets the logical channel
address on which other
alt_reconfig_eye_viewer
commands will use to apply.
© July 2010 Altera Corporation
Chapter 14: Analyzing and Debugging Designs with the System Console
System Console Examples
14–17
Table 14–17. Eye Monitor Tcl Commands (Part 2 of 2)
Command
Arguments
Function
alt_xcvr_reconfig_eye_viewer_get_phase_ste <service-path>
p
Get the current phase step of
the previously specified
channel.
alt_xcvr_reconfig_eye_viewer_is_enabled
<service-path>
Get whether the EyeQ feature is
enabled on the previously
specified channel.
alt_xcvr_reconfig_eye_viewer_set_enabled
Enable/disable the EyeQ feature
<disable(0)/ena on the previously specified
channel.
ble(1)>
<service-path>
__
alt_xcvr_reconfig_eye_viewer_set_logical_c <service-path>
hannel_address
alt_xcvr_reconfig_eye_viewer_set_phase_ste <service-path>
p
<phase step>
Set the phase step of the
previously specified channel.
Example 14–1 shows how to load and link a Quartus II design set.
Example 14–1. Loading and Linking a Design
% get_service_paths device
{/connections/USB-Blaster [USB-0]/EP2C35}
% set device_path [lindex [get_service_paths device] 0]
/connections/USB-Blaster [USB-0]/EP2C35
% design_load /projects/9.1/standard
QuartusDesignFactory elaborating \projects\9.1\standard
QuartusDesignFactory found SOF File at NiosII_cycloneII_2c35_standard.sof
QuartusDesignFactory found JDI File at NiosII_cycloneII_2c35_standard.jdi
QuartusDesignFactory found SOPC Info File at
\projects\9.1\standard\NiosII_cycloneII_2c35_standard_sopc.sopcinfo
% set design_path [lindex [get_service_paths design] 0]
/designs/standard
% design_link $design_path $device_path
Created a link from /designs/standard to /connections/USB-Blaster [USB-0]/EP2C35.
Created a link from /designs/standard/NiosII
cycloneII_2c35_standard_sopc.sopcinfo/cpu.data_master to /connections/USB-Blaster
[USB-0]/EP2C35/cpu.
Created a link from
/designs/standard/NiosII_cycloneII_2c35_standard_sopc.sopcinfo/cpu.data_master/jtag_
uart.avalon_jtag_slave to /connections/USB-Blaster [USB-0]/EP2C35/jtag_uart
System Console Examples
This section provides three SOPC Builder system examples to show you how to use
the System Console. The System-Console.zip file contains design files for the first
two example systems. This zip file includes files for both the Nios II Development Kit
Cyclone® II Edition and the Nios II Development Kit Stratix® II Edition.
f
© July 2010
You can download the design files for the example designs from the Altera website. A
link to the design files appears next to this document on the User Guide web page.
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
14–18
Chapter 14: Analyzing and Debugging Designs with the System Console
System Console Examples
The first example Tcl script creates a LED light show on your board. The SOPC
Builder system for this example includes two modules: a JTAG to Avalon master
bridge and a PIO core. The JTAG to Avalon master bridge provides a connection
between your development board and SOPC Builder system via serial peripheral
interface (SPI). The PIO module provides a memory-mapped interface between an
Avalon-MM slave port and general-purpose IO ports.
f
For more information about these components refer to the Embedded Peripherals IP
User Guide.
The first example program sends a series of master_write_8 commands to the
JTAG Avalon master bridge. The JTAG Avalon master sends these commands to the
Avalon-MM slave port of the PIO module. The PIO I/O ports connect to FPGA pins
that are, in turn, connected to the LEDs on your development board. The write
commands to the PIO Avalon-MM slave port result in the light show.
1
The instructions for these examples assume some familiarity with the Quartus II and
SOPC Builder software.
LED Light Show Example
Figure 14–2 illustrates the SOPC Builder system for the first example.
Figure 14–2. SOPC Builder System for Light Show Example
JTAG
Avalon-MM
Master
System
Interconnect
Fabric
PIO LED
(Avalon-MM
Slave)
Conduit
Interface
LEDs
To build this example system, complete the following steps:
1. On your host computer file system, locate the following directory: <Nios II EDS
install path>\examples\<verilog or vhdl>\<board version>\standard. Each
development board has a VHDL and Verilog HDL version of the design. You can
use either of these design examples.
2. Copy the standard directory to a new location. By copying the design files, you
avoid corrupting the original design and avoid issues with file permissions. This
document refers to the newly created directory as the c:\<projects>\standard
directory.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 14: Analyzing and Debugging Designs with the System Console
System Console Examples
f
14–19
Refer to the Altera website for information on different board kits
available from Altera.
3. Copy the System_Console.zip file to the c:\< projects>\standard directory and
unzip it. Specific directories may be created for specific Altera development
boards.
4. Choose All Programs > Altera > Nios II EDS <version> Command Shell
(Windows Start menu) to run a Nios II command shell.
5. Change to the directory for your board.
6. To program your board with the .sof file, type the following command in the
Nios II command shell:
nios2-configure-sof <sof_name>.sof r
If your development board includes more than one JTAG cable, you must specify
which cable you are communicating with as an argument to the
nios2-configure-sof <sof_name>.sof command. To do so, type the
following commands:
a. jtagconfig r
Figure 14–3. jtagconfig Output
Figure 14–3 gives sample output from the jtagconfig command. This output
shows that the active JTAG cable is number 2. Substitute the number of your JTAG
for the <cable_number> variable in the following command:
b. nios2-configure-sof -c <cable_number> <sof_name>.sof r
7. You can then run the LED light show example by typing the following command:
system-console --script=led_lightshow.tcl r
8. You can see the LEDs performing a running light demonstration. Press Ctrl+C to
stop the LED light show.
9. To see the commands that this script runs, open the led_lightshow.tcl file in your
\jtag_pio_<cii_or_sii> directory.
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
14–20
Chapter 14: Analyzing and Debugging Designs with the System Console
System Console Examples
JTAG Examples
Two JTAG examples are described below. The first JTAG example gives you some
practice working with the System Console as an interactive tool. The second example
verifies that the clock is toggling.
Verify JTAG Chain
In this example, you verify the JTAG chain on you board. To run this example,
complete the following steps:
1. Choose All Programs > Altera > Quartus II <version> (Windows Start menu) to
run the Quartus II software. Open the Quartus II project file, jtag_pio.qpf or
jtag_pio_sii.qpf.
2. On the Tools menu, click SOPC Builder.
3. On the SOPC Builder Tools menu, click System Console.
4. Set the path to the jtag_debug service by typing the following command:
set jd_path [lindex [get_service_paths jtag_debug] 0] r
The get_service_paths command always returns a list, even if the list has a
single item; consequently, you must index into the list using the lindex
command. In this case, the variable jd_path is assigned the string that is the 0th
element of the list.
5. Open the jtag_debug service by typing the following command:
open_service jtag_debug $jd_path r
6. Set up a list of byte values to test the chain by typing the following command:
set values [list 0xaa 0x55 0xaa 0x55 0xaa 0x55 0xaa 0x55 0xaa 0x55
0xaa 0x55 0xaa 0x55 0xaa 0x55 0xaa 0x55]r
7. Loop the values by typing the following command:
jtag_debug_loop $jd_path $values r
If the jtag_debug_loop command is successful, you should see the values that
you sent reflected in the System Console. Figure 14–4 shows the transcript from
this interactive session.
Figure 14–4. The jtag_debug_loop Command
8. Close the jtag_debug service by typing the following command:
close_service jtag_debug $jd_pathr
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 14: Analyzing and Debugging Designs with the System Console
System Console Examples
14–21
This example provides the beginnings of a JTAG chain validation workflow.
Depending on the number of devices and FPGAs in your JTAG chain, you can expand
upon this test by performing more operations, in which you can interleave access to
JTAG chains with larger data sets, and potentially multiple devices.
Verify Clock
The command to verify that your clock is toggling samples the clock asynchronously.
Consequently, you may need to use this command several times to determine if the
clock is toggling. The jtag_debug_sample_clock.tcl script samples the clock 10 times.
To run this script, type source jtag_debug_sample_clock.tcl at the System
Console prompt. You should see 10 values for the JTAG clock printed to the System
Console as Figure 14–5 illustrates.
Figure 14–5. The jtag_debug_sample_clock Command
Checksum Example
In this example, you add an on-chip memory and hardware accelerator to the
previous SOPC Builder system. The hardware accelerator calculates a checksum.
Figure 14–6 illustrates this system.
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
14–22
Chapter 14: Analyzing and Debugging Designs with the System Console
System Console Examples
Figure 14–6. SOPC Builder System for Checksum Accelerator Example
JTAG
Avalon-MM
Master
System Interconnect Fabric
LEDs
On-Chip
Memory
Checksum
Accelerator
PIO LED
To build this example system, complete the following steps:
1. In the System Contents tab in SOPC Builder, double-click On-Chip Memory
(RAM or ROM) in the On-Chip subfolder of the Memories and Memory
Controllers folder to add this component to your system.
2. In the On-Chip Memory (RAM or ROM) wizard, for Total memory size type 128
to change the memory size to 128 bytes. Click Finish to accept the other default
values.
3. To connect the on-chip memory to the master, click the open dot at the intersection
of the onchip_mem s1 Avalon slave port and the JTAG to Avalon Master Bridge
master port.
4. In the System Contents tab, double-click Checksum Accelerator in the Custom
Component folder to add this component to your system.
5. To connect the checksum accelerator Slave port, click on the open dot at the
intersection of the accelerator Slave and the master master port.
6. To connect the checksum accelerator Master port, click on the open dot at the
intersection of the accelerator Master and the onchip_mem s1 port.
7. In the Base column, enter the base addresses for the slaves in your system.
■
Onchip_mem s1 port—0x00000080
■
Accelerator Slave port—0x00000020
Click on the lock icon next to each address to lock these values.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 14: Analyzing and Debugging Designs with the System Console
System Console Examples
14–23
Figure 14–7 illustrates the completed system.
Figure 14–7. Checksum Accelerator Module Connections
8. Save your system.
9. In the System Contents tab, click Next.
10. In the System Generation tab, click Generate.
11. On the Quartus II Processing menu, click Start Compilation.
12. When compilation completes, re-program your board by typing the following
command in the Nios II command shell:
nios2-configure-sof jtag_pio.sof r
13. Type system-console r in the Nios II command shell to start the System
Console.
1
If you reprogram your board, you must start a new System Console to
receive the changes.
14. To run the checksum example, in the System Console, type:
source set_memory_and_run_checksum.tcl r
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
14–24
Chapter 14: Analyzing and Debugging Designs with the System Console
System Console Examples
Figure 14–8. System Console Output
Figure 14–8 shows the output from a successful run.
1. You can change the value written into the RAM by changing the value given in the
fill_memory routine in the set_memory_and_run_checksum.tcl file. Save the
Tcl file after editing and rerun the command. (Because the system command uses
master_write_32, if you use values that are less than 32 bits, they are filled with
leading 0s.)
Nios II Processor Example
In this example you program the Nios II processor on your board to run the count
binary software example that is included in the Nios II installation. This is a simple
program that, using an 8-bit variable, repeatedly counts from 0 to 0xFF. The output of
this variable is displayed on the LEDs on your board. After programming the Nios II
processor, you use the System Console processor commands to start and stop the
processor.
To run this example, complete the following steps:
1. Download the Nios II Ethernet Standard Design Example for your board from the
Altera website.
2. Create a folder to extract the design. For this example, use C:\Count_binary.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 14: Analyzing and Debugging Designs with the System Console
System Console Examples
14–25
3. Unzip the Nios II Ethernet Standard Design Example into C:\Count_binary.
4. In a Nios II command shell, change to the directory of your new project.
5. To program your board, type the following command in a Nios II command shell:
nios2-configure-sof niosii_ethernet_standard_<board_version>.sof r
6. Using Nios II Software Build Tools for Eclipse, create a new Nios II Application
and BSP from Template using the Count Binary template and targeting the Nios II
Ethernet Standard Design Example.
7. To build the executable and linkable format (ELF) file (.elf) for this application,
right-click the Count Binary project and select Build Project.
f
For more information about creating Nios II applications, refer to the Using the Nios II
Software Build Tools chapter in the Nios II Software Developer’s Handbook.
8. Download the .elf file to your board by right-clicking Count Binary project and
selecting Run As, Nios II Hardware.
The LEDs on your board provide a new light show.
9. Start the System Console by typing system-console in your Nios II command
shell.
10. Set the processor service path to the Nios II processor by typing the following
command:
set niosii_proc [lindex [get_service_paths processor] 0] r
11. Open both services by typing the following commands:
open_service processor $niosii_proc r
12. Stop the processor by typing the following command:
processor_stop $niosii_proc r
The LEDs on your board freeze.
13. Start the processor by typing the following command:
processor_run $niosii_proc r
The LEDs on your board resume their previous activity.
14. Stop the processor by typing the following command:
processor_stop $niosii_proc r
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
14–26
Chapter 14: Analyzing and Debugging Designs with the System Console
Device Support
15. Close the services by typing the following command:
close_service processor $niosii_proc r
The processor_step, processor_set_register and
processor_get_register provide additional control over the Nios II
processor.
Device Support
You can target all Altera device families with the System Console. Transceiver Toolkit
commands, however, can only be targeted for Arria II GX and Stratix IV GX devices.
Conclusion
The System Console offers you a wide variety of options for communicating with
modules in your design at a low level. You can use either Tcl scripting commands or
GUI to access and run services for setting up, running tests, optimizing design
parameters, and debugging designs you have programmed into Altera supported
device families without having to recompile you designs.
Document Revision History
Table 14–18 shows the revision history for this chapter.
Table 14–18. Document Revision History
Date
Version
July 2010
10.0.0
Changes Made
Initial release. Previously released as the System Console User Guide, which is being
obsoleted. This new chapter adds new commands.
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 10.0 Volume 3: Verification
© July 2010 Altera Corporation
15. Transceiver Link Debugging Using the
Quartus II Software
QII53029-10.0.1
This chapter describes how to use the transceiver link debugging examples with the
Transceiver Toolkit in the Quartus®II software. The Transceiver Toolkit in the
Quartus II software allows you to quickly test the functionality of transceiver
channels and help you improve the signal integrity of transceiver links in your design.
You can use the Transceiver Toolkit before your design is complete to verify that your
transceiver link can perform at the required speed within your error tolerances.
You can use an example design available on the Altera® website if you want to quickly
start using the Transceiver Toolkit. You also can create a custom design to use the
Transceiver Toolkit, or you can port one of the the design examples. In today's high
speed interfaces, stringent Bit Error Ratio (BER) requirements are not easy to meet and
debug. You can use the Transceiver Toolkit in the Quartus II software with design
examples that you download from the Altera website that allow you to check and
improve the signal integrity of transceiver links on your board before you complete
the final design, saving you time and helping you find the best PMA settings for your
high speed interfaces.
Transceiver Toolkit Overview
To launch the Transceiver Toolkit, in the main Quartus II window, on the Tools menu,
select Transceiver Toolkit. The underlying framework for the Transceiver Toolkit is
the System Console. The System Console performs low-level hardware debugging of
your design. The System Console provides read and write access to the IP cores
instantiated in your design. You can use the System Console for the initial bring-up of
your PCB and low-level testing.
f
For information about the System Console, refer to the Analyzing and Debugging
Designs with the System Console chapter in volume 3 of the Quartus II Handbook.
The Transceiver Toolkit allows you to perform run-time tasks. You can use the
Transceiver Toolkit to perform high speed link tests for the transceivers in your
devices. The Transceiver Toolkit allows you to easily test your high-speed interfaces in
real-time. Various features and controls in the Transceiver Toolkit are described in the
following paragraphs.
Auto Sweep
Auto Sweep, a feature in the Transceiver Toolkit, allows you to input sweep ranges for
your transceiver physical medium attachment (PMA) settings and run tests in
automatic mode. Auto Sweep can store a history of the test runs and keep a record of
the best PMA settings. These settings can then be used in your final design.
f
© August 2010
For more information, refer to Transceiver Toolkit Auto Sweep Panel in Quartus II Help.
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
15–2
Chapter 15: Transceiver Link Debugging Using the Quartus II Software
Transceiver Link Debugging Examples
EyeQ
The EyeQ feature helps you to determine signal integrity. The EyeQ feature in the
Transceiver Toolkit allows you to chart eye-width data and view the data in a bathtub
curve. After you run the EyeQ feature you can view the data in the Report pane of the
Transceiver Toolkit and export the data in comma-separated value (.csv) format for
further analysis.
f
For further details on the EyeQ feature, refer to Transceiver Toolkit EyeQ Panel in
Quartus II Help.
Control Links
The Transceiver Toolkit Channel Control panels allow you to run tests in manual
mode. The Channel Control panels allow you to view and manually modify settings
for transmitter and receiver channels at run-time.
f
For more information about how to set up the Transceiver Toolkit, refer to Working
with the Transceiver Toolkit in Quartus II Help.
Transceiver Link Debugging Examples
Altera provides design examples to assist you with setting up and using the
Transceiver Toolkit. To learn more about the Quartus II software version used to
create these design examples, the target device, and development board details, refer
to the readme.txt of each example. Each example is verified and tested with the
Quartus II software version referenced in the readme.txt. However, you may be able
to use these examples with a later version of the Quartus II software.
If you are recompiling the design examples for a different board, refer to the
“Changing Pin Assignments” on page 15–6 section to determine which pin
assignments you must edit.
f
To download design examples, go to the Transciever Toolkit Examples located on the
Altera website.
Test Setup for Link Debugging
Testing signal integrity for high-speed transceiver links involves using data patterns,
such as pseudo-random binary sequences (PRBS). Although the sequences appear to
be random, they have specific properties that you can use to measure the quality of a
link. In the example designs available on the Altera website, data patterns are
generated by a pattern generator and are then transmitted by the transmitter. The
transceiver on the far end can then be looped back so that the same data is then
received by the receiver of the transceiver. The data obtained is then checked by a data
checker to verify any bit errors.
Figure 15–1 and Figure 15–2 show examples of the test setup for the transceiver link
debugger. The first design example described in this section has a structure similar to
the design shown in Figure 15–1. This figure represents only one possible
configuration for your design. You can also have the transmitter on one FPGA and the
receiver on a different FPGA.
Quartus II Handbook Version 10.0 Volume 3: Verification
© August 2010 Altera Corporation
Chapter 15: Transceiver Link Debugging Using the Quartus II Software
Transceiver Link Debugging Examples
15–3
Figure 15–2 shows a similar test setup for the second design example described in this
section, except that there are four sets of transceivers and receivers rather than one.
Figure 15–1. Transceiver Link Debugger Test Setup
Stratix IV GX Signal Integrity Board on your board
Top-Level Design (FPGA)
Custom_phy
Avalon-ST Data
Pattern Generator
System Console
(in SOPC Builder)
Host Computer
JTAG
to Avalon
Master Bridge
Loopback
on board
Avalon-ST Data
Pattern Checker
Figure 15–2. Transceiver Link Debugger Test Setup (Four Channels)
Stratix IV GX Signal Integrity Board on your board
Top-Level Design (FPGA)
Custom_phy
Avalon-ST Data
Pattern Generator
System Console
(in SOPC Builder)
Host Computer
JTAG
to Avalon
Master Bridge
Avalon-ST Data
Pattern Checker
Avalon-ST Data
Pattern Generator
Avalon-ST Data
Pattern Checker
Avalon-ST Data
Pattern Generator
Loopback
on board
Loopback
on board
Loopback
on board
Avalon-ST Data
Pattern Checker
Avalon-ST Data
Pattern Generator
Avalon-ST Data
Pattern Checker
© August 2010
Altera Corporation
Loopback
on board
Transceiver Link Debugging Using the Quartus II Software
15–4
Chapter 15: Transceiver Link Debugging Using the Quartus II Software
Transceiver Link Debugging Examples
The design examples include the SOPC Builder system, which contains the following
components:
■
Custom Phy channel(s)
■
Avalon-ST Data Pattern Generator
■
Avalon-ST Data Pattern Checker
■
JTAG to Avalon Master Master Bridge
Custom_phy
You can test all possible parallel data widths of the transceivers in these design
examples. You can configure the Custom_phy IP core as 8-bit, 10-bit, 16-bit, 20-bit,
32-bit or 40-bit. The sweep tools disable word alignment during sweep. This mode is
enabled to simplify timing closure. You can also use the Data Format Adapter IP
component as required. You can have one or multiple channels in your design.
You use SOPC Builder to generate the Custom_phy. The Custom_phy IP core in the
design examples are generated for Stratix IV GX devices.
To use the Custom_phy IP core with the Transceiver Toolkit, perform the following:
■
f
Set the following parameters to meet your project requirements:
■
Number of lanes
■
Bonded group size
■
Serialization factor
■
Data rate
■
Input clock frequency
■
Disable 8B/10B
■
Set Word alignment mode to manual
■
Disable rate match FIFO
■
Disable byte ordering block
■
Change only the following Analog Options:
■
Transmitter termination resistance
■
Receiver common mode voltage
■
Receiver termination resistance
For more information about the components used in the Custom_phy IP core, refer to
the Custom PHY IP User Guide.
Data Pattern Generator
This component produces data patterns in the test flow. You can use a variety of
popular patterns to test transceiver signal integrity. The data pattern generator
component is provided as an Altera IP component. You can use any pattern, but you
must have a checker to verify that you receive that pattern properly.
Quartus II Handbook Version 10.0 Volume 3: Verification
© August 2010 Altera Corporation
Chapter 15: Transceiver Link Debugging Using the Quartus II Software
Transceiver Link Debugging Examples
15–5
When you use the Avalon®-ST Data Pattern Generator, the width may be different in
the pattern that you use, and you may need to use a data format adaptor. The
Avalon-ST Data Pattern Generator component is available in the SOPC Builder library
tree. The adaptor, however, does not form a new data generation component package,
but serves as a data formatter.
The Avalon-ST Data Pattern Generator can generate industry-standard data patterns.
Data patterns are generated on a 32-bit or 40-bit wide Avalon streaming source port.
f
For more information, refer to the System Interconnect Fabric for Streaming Interfaces
chapter in volume 4 of the Quartus II Handbook.
Figure 15–3 shows the page in the wizard you use to set parameters for the Avalon-ST
Data Format Adapter.
Figure 15–3. Avalon-ST Data Format Adapter
Data Checker
The Avalon-ST Data Pattern Checker components are provided as SOPC components.
These components include Avalon-ST Data Pattern Checker, Avalon-ST Data Format
Adapter, and Avalon-ST Timing Adapter. When the data checker runs, it attempts to
find the selected data pattern in the incoming data by comparing the incoming
pattern with the expected pattern.
© August 2010
Altera Corporation
Transceiver Link Debugging Using the Quartus II Software
15–6
Chapter 15: Transceiver Link Debugging Using the Quartus II Software
Transceiver Link Debugging Examples
The Avalon-ST Data Pattern Checker is available under Debug and Performance in
the SOPC Builder component library tree. The checker is the core logic for data
pattern checking. Data patterns are accepted on 32-bit or 40-bit wide Avalon
streaming sink ports.
f
For more information, refer to Avalon Streaming Data Pattern Generator and Checker
Cores.
You can use the design examples primarily to quickly test the functionality of receiver
and transmitter channels in your design without needing to create any custom
designs with data generators and checkers. When working with these examples,
assume that your design is not complete, and that you want to check the transceiver
link signal integrity. You can quickly change transceiver settings in the design
examples to see how they affect transceiver link performance. You can also use the
design examples to isolate and verify transceiver links without having to debug other
logic in your design.
Compiling Design Examples
Once you have downloaded the design examples, open the Quartus II software
version 10.0 or later and unarchive the project in the example. If you have access to the
same development board with the same device as mentioned in the readme.txt of the
example, you can directly program your device with the provided programming file
in that example. If you want to recompile the design, you must regenerate the system
in SOPC builder and recompile the design in the Quartus II software to get a new
programming file.
If you have the same board as mentioned in readme.txt but a different device on your
board, then you must choose the appropriate device and recompile the design. For
example some early development boards are shipped with the engineering sample
devices.
If you have a different board, you must edit the necessary pin assignments and
recompile the design examples provided here.
Changing Pin Assignments
This section explains how to edit pin assignments for the first design example below.
Design example named (first design example) is developed for the Stratix IV
Transceiver Signal Integrity Development Kit (DK-SI-4SGX230N). This kit has a
Stratix IV GX device. Table 15–1 lists the top-level pins in this design.
Table 15–1. Stratix IV GX Top-Level Pin Assignments (DK-SI-4SGX230N)
Top-Level Signal Name
I/O Standard
Pin Number on
DK-SI-4SGX230N Board
REFCLK_GXB2_156M25 (input)
2.5 V LVTTL/LVCMOS
PIN_G38
S4GX_50M_CLK4P (input)
2.5 V LVTTL/LVCMOS
PIN_AR22
GXB1_RX1 (input)
1.4-V PCML
PIN_R38
GXB1_TX1 (output)
1.4-V PCML
PIN_P36
Quartus II Handbook Version 10.0 Volume 3: Verification
© August 2010 Altera Corporation
Chapter 15: Transceiver Link Debugging Using the Quartus II Software
Transceiver Toolkit Link Test Setup
15–7
To change this example for a Stratix IV GX development kit (DK-DEV-4SGX230N), the
pin assignments shown in Table 15–2 you must make before recompiling the design.
Table 15–2. Stratix IV GX Top-Level Pin Assignments (DK-DEV-4SGX230N)
Top-Level Signal Name
I/O Standard
Pin Number on
DK-DEV-4SGX230N Board
REFCLK_GXB2_156M25 (input)
LVDS
PIN_AA2
S4GX_50M_CLK4P (input)
2.5 V LVTTL/LVCMOS
PIN_AC34
GXB1_RX1 (input)
1.4-V PCML
PIN_AU2
GXB1_TX1 (output)
1.4-V PCML
PIN_AT4
Similarly, you can change the pin assignment for your own board and recompile the
design examples for use on your own board.
Transceiver Toolkit Link Test Setup
The following steps describe how to set up testing with the Transceiver Toolkit:
1. Program the device either with the programming file provided with the .zip file or
with the new programming file after you recompile your project.
2. Open the Transceiver Toolkit from the Tools menu in the Quartus II software.
3. Make sure that the .sof of the device you use is programmed and that board
settings, such as jumper settings, are correct.
Loading the Project in System Console
From the Transceiver Toolkit, load the Quartus project file (*.qpf) by going to the File
menu and selecting Load Project. Whether you have recompiled the design or not, the
unzipped contents of the examples contain this file. Once the project is loaded, you
can see the design information under System Explorer in the System Console.
Linking the Hardware Resource
Make sure the device board is turned ON and is available before you start the System
Console or the Transceiver Toolkit. The connections are detected at startup of the tool.
You can right click on a Design Instance under the System Explorer and link that
instance to the device you want. Each design example contains one transceiver
Custom_phy instance, the first one configured as one channel and the second one
configured with four channels in bonded mode. Right-click on the design instance
and click on the device to link that design instance with your device. If you are
designing your own design example with more than one design instance and your
board has more than one device, then you have the option of linking a certain device
to a certain design instance. This is useful when you want to perform a link test
between a transmitter and receiver on two separate devices.
To set up the transmitter channels, receiver channels, and transceiver links, go to the
Tools menu and select Transceiver Toolkit, or from the Welcome to the Transceiver
Toolkit tab, click on the Transceiver Toolkit.
© August 2010
Altera Corporation
Transceiver Link Debugging Using the Quartus II Software
15–8
Chapter 15: Transceiver Link Debugging Using the Quartus II Software
Transceiver Toolkit Link Test Setup
Creating the Channels
When you open the Transceiver Toolkit you can view three tabs in the System
Console, including Transmitter Channels, Receiver Channels, and Transceiver Links
tabs.
The Transmitter and Receiver Channel tabs are automatically populated with the
existing transmitter and receiver channels in the design example, respectively.
However, you can create your own additional transmitter and receiver channels in a
situation where the expected configuration was not automatically populated. In the
Link Channel tab you can create the link between a transmitter and receiver channel
for which you want to perform the test. Links are automatically created when a
receiver channel and transmitter channel share a transceiver channel. However, if
you are not actually looping data back, but using it to transmit or receive to another
transceiver channel, this is where you would define and create a new link. For
example, in Figure 15–4 a link is created in the Link tab between a transmitter and
receiver channel of the same device.
Figure 15–4. Creating a Link Channel in Transceiver Toolkit
You can also perform a physical link test without loopback by connecting one device
transmitter to another device receiver. This panel is where you would define that
connection into a link, and tests would run off that link. For example, as depicted in
Figure 15–1, you typically use the transmitter and receiver channels of the same
device and loop them back on the far side of the board trace to check the signal
integrity of your high speed interface on the board trace. The link that you create in
Transceiver Toolkit can be selected and has different buttons that you can use to start
and control link tests.
1
You can also communicate with other devices that have the capability to generate and
verify test patterns that Altera supports.
Quartus II Handbook Version 10.0 Volume 3: Verification
© August 2010 Altera Corporation
Chapter 15: Transceiver Link Debugging Using the Quartus II Software
Transceiver Toolkit Link Test Setup
15–9
Running the Link Tests
You can click buttons in the Link Channel tab that control how you how you want to
test the link. For example, you can use the Auto Sweep feature to sweep various
transceiver settings parameters through a range of values, looking for the one that
gives the best BER value. You can also open Transmitter, Receiver and Link Control
panels to manually control PMA settings and run individual tests. You can change
various controls in the panels to suit your requirements. To perform an auto sweep
link test, perform the following steps:
1.
Select the link to test and click Auto Sweep to open the auto sweep panel for the
selected link.
2. Set the test pattern to test.
3. Select either Smart Autosweep or Full AutoSweep. Full AutoSweep runs a test
of every combination of settings that falls within the bounds that you set. Smart
AutoSweep tries to minimize the number of tests run to reach a good setting,
which saves you time. Smart Autosweep will not test every possible setting, so
may not achieve the very best setting possible; however, it can quickly find a good
setting.
4. Set up run lengths for each test iteration. The run length limits you set are ignored
in smart sweep mode.
5. Set up PMA sweep limits within the range you want to test.
6. Press Start and let the sweep run until complete.
When an Auto Sweep run has finished at least one iteration, you can create a report by
clicking Create Reports, which opens the Reports tab. The report shows data from all
runs that have completed so far. You can sort by columns and filter data by regular
expression in the Reports tab. You can also export the reports to a comma-separated
value (.csv) file by right clicking on a report. If you found a setting with the Smart
Sweep mode, you can use the reported best case PMA settings, and apply a +/- 1
setting to them, returning the test to Full Auto Sweep mode. This can help you
determine if the settings you chose are the best, by seeing if settings near those that
you chose are also any better. You can then choose your own runtime conditions, reset
t he Auto Sweep feature by pressing Reset, and re-run to generate BER data based on
your own run length conditions. This procedure allows you to obtain a good setting
for PMA in a shorter amount of time. You can then look at the BER column at the end
of the full sweep to determine the best case.
1
When setting smart sweep ranges, try to include the 0 setting as often as possible, as
that setting often provides the best results.
Viewing Results in the EyeQ Feature
Advanced FPGA devices such as Stratix IV have built-in EyeQ circuitry, which is used
with the EyeQ feature in Transceiver Toolkit. The EyeQ feature allows you to estimate
the horizontal eye opening at the receiver of the transceiver. With this feature, you can
tune the PMA settings of your transceiver, which results in the best eye and BER at
high data rates.
f
© August 2010
To understand the EyeQ circuit and how it works, refer to AN 605: Using the EyeQ
Feature in Stratix IV devices.
Altera Corporation
Transceiver Link Debugging Using the Quartus II Software
15–10
Chapter 15: Transceiver Link Debugging Using the Quartus II Software
Transceiver Toolkit Link Test Setup
The following paragraph describes how to use the EyeQ feature in the Transceiver
Toolkit to view the results of the link tests that you run.
1. Select a Transceiver Link or Receiver Channel in the main Transceiver Toolkit
panel that you want to run EyeQ against.
2. Click Control Link or Control Channel to open control panels. Use these control
panels to set the PMA settings and test pattern that you want the EyeQ feature to
run against. You can check the report panel or Best Case column from an
Autosweep run for the settings with the best BER value and enter those PMA
values through the Transmitter and Receiver control panels.
3. Click EyeQ to open the EyeQ feature.
4. Review the test stop conditions and set them to your preference.
5. Click Run, which allows the EyeQ feature to gather current settings of the channel
and use those settings to start a phase sweep. 32 iterations of the phase sweep will
run.
6. As the run progresses, you can view the status, which is displayed on the top
section of the feature. You can read current progress and the chart is updated with
values each time a run completes. When the run is completed, you should see a
bathtub curve.
7. Any time at least one run has completed, you can click Create Report to view past
data runs in a report panel.
8. When the run finishes, if the bathtub curve looks like a hill instead, click the center
eye button, which then reorganizes the data into a bathtub curve.
9.
If the data does not display on the chart, you can right-click and choose
Auto-Range, which should make the data appear.
10. If you want to change PMA settings and re-run the EyeQ feature, make sure you
first stop and reset the EyeQ feature. If you do not reset, the EyeQ feature
continues testing based on the original PMA settings of the current test that it had
begun, and overwrites any setting you may have changed through the control
panel.
11. After you stop and reset the EyeQ feature, change settings in the link or receiver
channel control panel. Then click Start on the EyeQ feature to start a new set of
tests.
When you can see that you are running good PMA settings, the bathtub curve is wide,
with sharp slopes near the edges. The curve may be up to 30 units wide. If the bathtub
is narrow, maybe as small as two units wide, then the signal quality may be poor. The
wider the bathtub curve, the wider the eye you have. Conversely, the smaller the
bathtub curve, the smaller the eye.
f
For more information about how to use the EyeQ feature, refer to Working with the
Transceiver Toolkit in Quartus II Help.
Quartus II Handbook Version 10.0 Volume 3: Verification
© August 2010 Altera Corporation
Chapter 15: Transceiver Link Debugging Using the Quartus II Software
Tcl Script in System Console
15–11
Tcl Script in System Console
System Console is the framework in the Quartus II software that supports the
Transceiver Toolkit. System Console provides a number of Tcl commands that you can
use to build a custom test routine script to test the transceiver link using the data
generator and checker. System Console allows you to tune PMA parameter, such as
those for changing DC gain. To get help on the Tcl commands available, type help in
the Tcl console in System Console. The following steps describe a transceiver link test
flow. You can perform all the tasks with Tcl commands in System Console.
1. Load the Quartus II project.
2. Find and link the design and service path.
3. Find and open links to transmitter channels and receiver channels.
4. Set up PRBS patterns to run on the link.
5. Set up PMA settings on transmitter and receiver channels.
6. Use PIO logic to generate a rising edge to enable the word aligner.
7. Start the link test.
8. Poll the receiver for BER data.
9. When the test is finished, stop the link test.
10. Close the link.
f
For more information about Tcl commands and their usage, refer to the Analyzing and
Debugging Designs with the System Console chapter in volume 3 of the Quartus II
Handbook.
The Tcl scripts provided with the design examples help you understand Tcl
commands associated with each task.
Running Tcl Scripts
The tasks that you perform with the Transceiver Toolkit GUI for setting up your test
environment you can also save as Tcl scripts. For example, you can save the steps you
perform for loading your project in the Transceiver Toolkit by clicking Create Tcl
setup script on the File menu.
You can save your steps at various stages when you add projects, create design
instances, link designs to devices, and create transceiver links., so that you do not
have to redo all the steps in the GUI to reach the initial setup you created to get your
specific configuration ready for debugging. All the saved scripts are shown under the
Scripts in the System Explorer.You can execute the script by right-clicking on Scripts
under the System Explorer in the Transceiver Toolkit, and then clicking Run, or you
can double-click on the script. You can also execute the script from the System
Console command line.
© August 2010
Altera Corporation
Transceiver Link Debugging Using the Quartus II Software
15–12
Chapter 15: Transceiver Link Debugging Using the Quartus II Software
Conclusion
Conclusion
You gain productivity when optimizing high speed transceiver links in your board
designs with the Transceiver Toolkit and design examples provided from Altera. You
can easily set up automatic testing of your transceiver channels so that you can
monitor, debug, and optimize transceiver link channels in your board design quicker
than before. You then know the optimal PMA settings to use for each channel in your
final FPGA design. You can use standard design examples that you download from
Altera’s website, and then customize the examples to match your own requirements.
Document Revision History
Table 15–3 shows the revision history for this handbook chapter.
Table 15–3. Document Revision History
Date
Version
Changes Made
August 2010
10.0.1
Corrected links
July 2010
10.0.0
Initial release
f
For previous versions of the Quartus II Handbook, refer to the Quartus II Handbook
Archive.
f
Take an online survey to provide feedback about this handbook chapter.
Quartus II Handbook Version 10.0 Volume 3: Verification
© August 2010 Altera Corporation
16. Quick Design Debugging Using
SignalProbe
QII53008-10.0.0
This chapter provides detailed instructions about how to use SignalProbe to quickly
debug your design. The SignalProbe incremental routing feature helps reduce the
hardware verification process and time-to-market for
system-on-a-programmable-chip (SOPC) designs.
Easy access to internal device signals is important in the design or debugging process.
The SignalProbe feature makes design verification more efficient by routing internal
signals to I/O pins quickly without affecting the design. When you start with a fully
routed design, you can select and route signals for debugging to either previously
reserved or currently unused I/O pins.
The SignalProbe feature is supported with the Arria® GX, Stratix® series, Cyclone®
series, and MAX® II, device families.
f
The Quartus® II software provides a portfolio of on-chip debugging solutions. For an
overview and comparison of all of the tools available in the Quartus II software
on-chip debugging tool suite, refer to Section V. In-System Design Debugging in
volume 3 of the Quartus II Handbook.
Debugging Using the SignalProbe Feature
The SignalProbe feature allows you to reserve available pins and route internal
signals to those reserved pins, while preserving the behavior of your design.
SignalProbe is an effective debugging tool that provides visibility into your FPGA.
You can reserve pins for SignalProbe and assign I/O standards before or after a full
compilation. Each SignalProbe-source to SignalProbe-pin connection is implemented
as an engineering change order (ECO) change that is applied to your netlist after a full
compilation.
To route the internal signals to the device’s reserved pins for SignalProbe, perform the
following tasks:
1. Reserve the SignalProbe Pins, described on page 16–1.
2. Perform a Full Compilation, described on page 16–2.
3. Assign a SignalProbe Source, described on page 16–2.
4. Add Registers to the Pipeline Path to SignalProbe Pin, described on page 16–2.
5. Perform a SignalProbe Compilation, described on page 16–3.
6. Analyze the Results of the SignalProbe Compilation, described on page 16–3.
Reserve the SignalProbe Pins
SignalProbe pins can only be reserved after compiling your design. You can also
reserve any unused I/Os of the device for SignalProbe pins after compilation.
Assigning sources is a simple process after reserving SignalProbe pins. The sources
for SignalProbe pins are the internal nodes and registers in the post-compilation
netlist that you want to probe.
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
16–2
Chapter 16: Quick Design Debugging Using SignalProbe
Debugging Using the SignalProbe Feature
1
Although you can reserve SignalProbe pins using many features within the Quartus II
software, including the Pin Planner and the Tcl interface, you should use the
SignalProbe Pins dialog box to create and edit your SignalProbe pins. For more
information, refer to About SignalProbe in Quartus II Help.
Perform a Full Compilation
You must complete a full compilation to generate an internal netlist containing a list of
internal nodes to probe to a SignalProbe output pin.
To perform a full compilation, on the Processing menu, click Start Compilation.
Assign a SignalProbe Source
A SignalProbe source can be any combinational node, register, or pin in your
post-compilation netlist. To find a SignalProbe source, in the Node Finder, use the
SignalProbe filter to remove all sources that cannot be probed. You might not be able
to find a particular internal node because the node can be optimized away during
synthesis, or the node cannot be routed to the SignalProbe pin. For example, nodes
and registers within Gigabit transceivers in Stratix IV devices cannot be probed
because there are no physical routes available to the pins.
1
To probe virtual I/O pins generated in low-level partitions in an incremental
compilation flow, select the source of the logic that feeds the virtual pin as your
SignalProbe source pin. For more information, refer to SignalProbe Pins Dialog Box and
Add SignalProbe Pins Dialog Box in Quartus II Help.
Because SignalProbe pins are implemented and routed as ECOs, turning the
SignalProbe enable option on or off is the same as selecting Apply Selected Change
or Restore Selected Change in the Change Manager window. (If the Change Manager
window is not visible at the bottom of your screen, on the View menu, point to Utility
Windows and click Change Manager.)
f
For more information about the Change Manager for the Chip Planner and Resource
Property Editor, refer to the Engineering Change Management with the Chip Planner
chapter in volume 2 of the Quartus II Handbook.
Add Registers to the Pipeline Path to SignalProbe Pin
You can specify the number of registers placed between a SignalProbe source and a
SignalProbe pin to synchronize the data with a clock and to control the latency of the
SignalProbe outputs. The SignalProbe feature automatically inserts the number of
registers specified into the SignalProbe path.
Figure 16–1 shows a single register between the SignalProbe source Reg_b_1 and
SignalProbe SignalProbe_Output_2 output pin added to synchronize the data
between the two SignalProbe output pins.
1
When you add a register to a SignalProbe pin, the SignalProbe compilation attempts
to place the register to best fit timing requirements. You can place SignalProbe
registers either near the SignalProbe source to meet fMAX requirements, or near the I/O
to meet tCO requirements.
Quartus II Handbook Version 10.0 Volume 3: Verification
© July 2010 Altera Corporation
Chapter 16: Quick Design Debugging Using SignalProbe
Debugging Using the SignalProbe Feature
16–3
Figure 16–1. Synchronizing SignalProbe Outputs with a SignalProbe Register
Reg_a_2
Reg_a_1
DFF
DFF
Logic
Logic
D
Q
D
Reg_b_1
Reg_b_2
DFF
DFF
D
Q
D
Q
Logic
Q
Logic
SignalProbe_Output_1
D
Q
SignalProbe_Output_2
SignalProbe
Pipeline
Register
1
To pipeline an existing SignalProbe connection, refer to Add SignalProbe Pins Dialog
Box in Quartus II Help.
In addition to clock input for pipeline registers, you can also specify a reset signal pin
for pipeline registers. To specify a reset pin for pipeline registers, use the Tcl command
make_sp, as described in “Scripting Support” on page 16–6.
Perform a SignalProbe Compilation
Perform a SignalProbe compilation to route your SignalProbe pins. A SignalProbe
compilation saves and checks all netlist changes without recompiling the other parts
of the design and completes compilation in a fraction of the time of a full compilation.
The design’s current placement and routing are preserved.
To perform a SignalProbe compilation, on the Processing menu, point to Start and
click Start SignalProbe Compilation.
Analyze the Results of the SignalProbe Compilation
After a SignalProbe compilation, the results are available in the compilation report
file. Each SignalProbe pin is displayed in the SignalProbe Fitting Result page in the
Fitter section of the Compilation Report. To view the status of each SignalProbe pin in
the SignalProbe Pins dialog box, on the Tools menu, click SignalProbe Pins.
The status of each SignalProbe pin appears in the Change Manager window
(Figure 16–2). (If the Change Manager window is not visible at the bottom of your
GUI, from the View menu, point to Utility Windows and click Change Manager.)
© July 2010
Altera Corporation
Quartus II Handbook Version 10.0 Volume 3: Verification
16–4
Chapter 16: Quick Design Debugging Using SignalProbe
Debugging Using the SignalProbe Feature
Figure 16–2. Change Manager Window with SignalProbe Pins
f
For more information about how to use the Change Manager, refer to the Engineering
Change Management with the Chip Planner chapter in volume 2 of the Quartus II
Handbook.
To view the timing results of each successfully routed SignalProbe pin, on the
Processing menu, point to Start and click Start Timing Analysis.
Performing a SignalProbe Compilation
After a full compilation, you can start a SignalProbe compilation either manually or
automatically. A SignalProbe compilation performs the following functions:
■
Validates SignalProbe pins
■
Validates your specified SignalProbe sources
■
If applicable, adds registers into SignalProbe paths
■
Attempts to route from SignalProbe sources through registers to SignalProbe pins
To run the SignalProbe compilation automatically after a full compilation, on the
Tools menu, click SignalProbe Pins. In the SignalProbe Pins dialog box, click Start
Check & Save All Netlist Changes.
To run a SignalProbe compilat