The Quartus Handbook Volume 1

The Quartus Handbook Volume 1
Quartus II Version 7.2 Handbook
Volume 1: Design and Synthesis
Preliminary Information
101 Innovation Drive
San Jose, CA 95134
www.altera.com
QII5V1-7.2
Copyright © 2007 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.
ii
Preliminary
Altera Corporation
Contents
Chapter Revision Dates .......................................................................... xv
About this Handbook ............................................................................ xvii
How to Contact Altera ......................................................................................................................... xvii
Third-Party Software Product Information ...................................................................................... xvii
Typographic Conventions .................................................................................................................. xviii
Section I. Design Flows
Chapter 1. Design Planning with the Quartus II Software
Introduction ............................................................................................................................................ 1–1
Device and Programming/
Configuration Method Selection ......................................................................................................... 1–2
Device Selection ................................................................................................................................ 1–2
Device Migration Planning ............................................................................................................. 1–3
Programming/Configuration Method Selection ......................................................................... 1–4
Early Planning Tools for Power and I/O ........................................................................................... 1–5
Early Power Estimation ................................................................................................................... 1–5
Early Pin Planning and I/O Analysis ........................................................................................... 1–6
Selecting Third-Party EDA Tool Flows ................................................................................................1–9
Synthesis Tools ................................................................................................................................. 1–9
Simulation Tools ............................................................................................................................. 1–10
Formal Verification Tools .............................................................................................................. 1–10
Planning for On-Chip Debugging Options ...................................................................................... 1–11
Planning for an Incremental Compilation Flow ............................................................................. 1–13
Flat Compilation Flow with No Design Partitions .................................................................... 1–13
Incremental Compilation with Design Partitions ...................................................................... 1–14
Top-Down Versus Bottom-Up Incremental Flows .................................................................... 1–15
Planning Design Partitions ........................................................................................................... 1–17
Creating a Design Floorplan ......................................................................................................... 1–18
Early Timing Estimation ..................................................................................................................... 1–19
Conclusion ............................................................................................................................................ 1–20
Referenced Documents ....................................................................................................................... 1–20
Document Revision History ............................................................................................................... 1–21
Chapter 2. Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Introduction ............................................................................................................................................ 2–1
Choosing a Quartus II Compilation Flow .......................................................................................... 2–3
Altera Corporation
iii
Preliminary
Quartus II Handbook, Volume 1
Flat Compilation Flow with No Design Partitions ...................................................................... 2–3
Incremental Compilation Flow with Design Partitions .............................................................. 2–5
Top-Down versus Bottom-Up Compilation Flows ..................................................................... 2–9
Quick Start Guide – Summary of Steps for an Incremental Compilation Flow ......................... 2–11
Top-Down Incremental Compilation Flow ................................................................................ 2–11
Bottom-Up Incremental Compilation .......................................................................................... 2–13
Design Partitions .................................................................................................................................. 2–17
Design Partition Assignments Compared to Physical Placement Assignments .................. 2–18
Creating Design Partitions ................................................................................................................. 2–19
Partition Name ................................................................................................................................ 2–21
Setting the Netlist Type for Design Partitions ................................................................................. 2–22
Fitter Preservation Level ............................................................................................................... 2–24
Empty Partitions ............................................................................................................................. 2–26
What Represents a Source Change for Incremental Compilation? ......................................... 2–27
Creating a Design Floorplan With LogicLock Location Assignments ......................................... 2–29
Taking Advantage of the Early Timing Estimator .................................................................... 2–31
Exporting and Importing Partitions for Bottom-Up Design Flows .............................................. 2–32
Quartus II Exported Partition File (.qxp) .................................................................................... 2–32
Exporting a Lower-Level Partition to be Used in a Top-Level Project ................................... 2–33
Exporting a Lower-Level Block within a Project ....................................................................... 2–35
Importing a Lower-Level Partition Into the Top-Level Project ............................................... 2–36
Importing Assignments and Advanced Import Settings ......................................................... 2–37
Generating Bottom-Up Design Partition Scripts for Project Management ............................ 2–40
Guidelines for Creating Good Design Partitions and LogicLock Regions .................................. 2–46
Creating Good Design Partitions ................................................................................................. 2–47
Partition Statistics Reports ............................................................................................................ 2–50
Resource Balancing ........................................................................................................................ 2–51
Timing Budgeting .......................................................................................................................... 2–53
Methodology to Check Partition Quality during Partition Planning ..................................... 2–54
The Importance of Floorplan Location Assignments in Incremental Compilation .............. 2–55
Creating Good Floorplan Location Assignments ...................................................................... 2–57
Incremental Compilation Advisor ............................................................................................... 2–60
Criteria for Successful Partition and Floorplan Schemes ......................................................... 2–61
Recommended Design Flows and Compilation Application Examples ..................................... 2–62
Top-Down Incremental Design Flows ........................................................................................ 2–62
Bottom-Up Incremental Design Flows ........................................................................................ 2–67
Incremental Compilation Restrictions .............................................................................................. 2–76
Using Incremental Synthesis Only Instead of Full Incremental Compilation ...................... 2–76
Preserving Exact Timing Performance ........................................................................................ 2–77
Using Incremental Compilation with Quartus II Archive Files .............................................. 2–77
Formal Verification Support ......................................................................................................... 2–78
OpenCore Plus MegaCore Functions in Bottom-Up Flows ..................................................... 2–78
Importing Encrypted IP Cores in Bottom-Up Flows ................................................................ 2–78
SignalProbe Pins and Engineering Change Management with the Chip Planner ............... 2–78
SignalTap II Embedded Logic Analyzer in Bottom-Up Compilation Flows ......................... 2–80
Logic Analyzer Interface in Bottom-Up Compilation Flows ................................................... 2–81
Migrating Projects with Design Partitions to Different Devices ............................................. 2–81
iv
Preliminary
Altera Corporation
Contents
HardCopy Compilation Flows ..................................................................................................... 2–82
Assignments Made in HDL Source Code in Bottom-Up Flows .............................................. 2–83
Compilation Time with Physical Synthesis Optimizations ..................................................... 2–83
Restrictions on Megafunction Partitions ..................................................................................... 2–84
Routing Preservation in Bottom-Up Compilation Flows ......................................................... 2–84
Bottom-Up Design Partition Script Limitations ......................................................................... 2–84
Register Packing and Partition Boundaries ................................................................................ 2–87
I/O Register Packing ..................................................................................................................... 2–87
Scripting Support ................................................................................................................................. 2–99
Generate Incremental Compilation Tcl Script Command ........................................................ 2–99
Preparing a Design for Incremental Compilation ................................................................... 2–100
Creating Design Partitions .......................................................................................................... 2–100
Setting Properties of Design Partitions ..................................................................................... 2–101
Creating Good Floorplan Location Assignments—Excluding or Filtering Certain Device
Elements (Such as RAM or DSP Blocks) ................................................................................... 2–102
Generating Bottom-Up Design Partition Scripts ..................................................................... 2–103
Exporting a Partition to be Used in a Top-Level Project ........................................................ 2–105
Importing a Lower-Level Partition into the Top-Level Project ............................................. 2–106
Makefiles ........................................................................................................................................ 2–106
Recommended Design Flows and Compilation Application Examples .............................. 2–107
Conclusion .......................................................................................................................................... 2–109
Referenced Documents ..................................................................................................................... 2–109
Document Revision History ............................................................................................................. 2–111
Chapter 3. Quartus II Design Flow for MAX+PLUS II Users
Introduction ............................................................................................................................................ 3–1
Chapter Overview ................................................................................................................................. 3–1
Typical Design Flow .............................................................................................................................. 3–2
Device Support ....................................................................................................................................... 3–3
Quartus II GUI Overview ..................................................................................................................... 3–4
Project Navigator .............................................................................................................................. 3–4
Node Finder ...................................................................................................................................... 3–4
Tcl Console ........................................................................................................................................ 3–4
Messages ............................................................................................................................................ 3–4
Status .................................................................................................................................................. 3–5
Setting Up MAX+PLUS II Look and Feel in Quartus II.....................................................................3–6
MAX+PLUS II Look and Feel ................................................................................................................3–7
Compiler Tool ..........................................................................................................................................3–9
Analysis and Synthesis .................................................................................................................. 3–10
Partition Merge ............................................................................................................................... 3–10
Fitter ................................................................................................................................................. 3–10
Assembler ........................................................................................................................................ 3–11
Timing Analyzer ............................................................................................................................. 3–11
EDA Netlist Writer ......................................................................................................................... 3–11
Design Assistant ............................................................................................................................. 3–11
MAX+PLUS II Design Conversion .....................................................................................................3–12
Converting an Existing MAX+PLUS II Design .......................................................................... 3–12
Altera Corporation
v
Preliminary
Quartus II Handbook, Volume 1
Converting MAX+PLUS II Graphic Design Files ...................................................................... 3–13
Importing MAX+PLUS II Assignments ...................................................................................... 3–14
Quartus II Design Flow ....................................................................................................................... 3–15
Creating a New Project .................................................................................................................. 3–16
Design Entry ................................................................................................................................... 3–16
Making Assignments ..................................................................................................................... 3–20
Synthesis .......................................................................................................................................... 3–23
Functional Simulation .................................................................................................................... 3–24
Place and Route .............................................................................................................................. 3–26
Timing Analysis .............................................................................................................................. 3–27
Timing Closure Floorplan ............................................................................................................. 3–29
Timing Simulation .......................................................................................................................... 3–31
Power Estimation ........................................................................................................................... 3–33
Programming .................................................................................................................................. 3–33
Conclusion ............................................................................................................................................ 3–34
Quick Menu Reference ........................................................................................................................ 3–35
Quartus II Command Reference for MAX+PLUS II Users..............................................................3–36
Referenced Documents ....................................................................................................................... 3–45
Document Revision History ............................................................................................................... 3–46
Chapter 4. Quartus II Support for HardCopy Series Devices
Introduction ............................................................................................................................................ 4–1
HardCopy II Device Support ............................................................................................................... 4–1
HardCopy II Design Benefits .......................................................................................................... 4–1
Quartus II Features for HardCopy II Planning ............................................................................ 4–2
HardCopy II Development Flow ......................................................................................................... 4–3
Designing the Stratix II FPGA First ............................................................................................... 4–4
Designing the HardCopy II Device First ...................................................................................... 4–6
HardCopy II Device Resource Guide ...................................................................................................4–8
HardCopy II Companion Device Selection ..................................................................................... 4–10
HardCopy II Recommended Settings in the Quartus II Software ................................................ 4–12
Limit DSP and RAM to HardCopy II Device Resources .......................................................... 4–12
Enable Design Assistant to Run During Compile ..................................................................... 4–12
Timing Settings ............................................................................................................................... 4–13
Constraints for Clock Effect Characteristics ............................................................................... 4–15
Quartus II Software Features Supported for HardCopy II Designs ....................................... 4–17
Performing ECOs with Quartus II Engineering Change Management with the Chip Planner ........
.................................................................................................................................................................. 4–20
Migrating One-to-One Changes ................................................................................................... 4–20
Migrating Changes that Must be Implemented Differently .................................................... 4–21
Changes that Cannot be Migrated ............................................................................................... 4–22
Overall Migration Flow ...................................................................................................................... 4–22
Preparing the Revisions ................................................................................................................. 4–22
Applying ECO Changes ................................................................................................................ 4–23
Formal Verification of Stratix II and HardCopy II Revisions ....................................................... 4–24
HardCopy II Utilities Menu ............................................................................................................... 4–25
Companion Revisions .................................................................................................................... 4–26
Compiling the HardCopy II Companion Revision ................................................................... 4–28
vi
Preliminary
Altera Corporation
Contents
Comparing HardCopy II and Stratix II Companion Revisions ...............................................
Generate a HardCopy II Handoff Report ...................................................................................
Archive HardCopy II Handoff Files ............................................................................................
HardCopy II Advisor .....................................................................................................................
HardCopy II Floorplan View ........................................................................................................
HardCopy Stratix Device Support ....................................................................................................
Features .................................................................................................................................................
HARDCOPY_FPGA_PROTOTYPE, HardCopy Stratix and Stratix Devices ..............................
HardCopy Design Flow ......................................................................................................................
The Design Flow Steps of the One-Step Process ........................................................................
How to Design HardCopy Stratix Devices ......................................................................................
Tcl Support for HardCopy Migration .........................................................................................
Design Optimization and Performance Estimation ........................................................................
Design Optimization ......................................................................................................................
Performance Estimation ................................................................................................................
Buffer Insertion ...............................................................................................................................
Placement Constraints ...................................................................................................................
Location Constraints ...........................................................................................................................
LAB Assignments ...........................................................................................................................
LogicLock Assignments ................................................................................................................
Checking Designs for HardCopy Design Guidelines ....................................................................
Altera-Recommended HDL Coding Guidelines .......................................................................
Design Assistant .............................................................................................................................
Reports and Summary ...................................................................................................................
Generating the HardCopy Design Database ...................................................................................
Static Timing Analysis ........................................................................................................................
Early Power Estimation ......................................................................................................................
HardCopy Stratix Early Power Estimation ................................................................................
HardCopy APEX Early Power Estimation .................................................................................
Tcl Support for HardCopy Stratix .....................................................................................................
Targeting Designs to HardCopy APEX Devices .............................................................................
Conclusion ............................................................................................................................................
Referenced Documents .......................................................................................................................
Document Revision History ...............................................................................................................
4–28
4–29
4–29
4–30
4–32
4–34
4–35
4–36
4–38
4–39
4–40
4–44
4–45
4–45
4–45
4–48
4–48
4–49
4–49
4–50
4–51
4–51
4–51
4–52
4–53
4–55
4–55
4–55
4–56
4–56
4–57
4–57
4–58
4–59
Section II. Design Guidelines
Chapter 5. Design Recommendations for Altera Devices and the Quartus II Design
Assistant
Introduction ............................................................................................................................................
Synchronous FPGA Design Practices .................................................................................................
Fundamentals of Synchronous Design .........................................................................................
Hazards of Asynchronous Design .................................................................................................
Design Guidelines .................................................................................................................................
Combinational Logic Structures .....................................................................................................
Altera Corporation
5–1
5–2
5–2
5–3
5–4
5–4
vii
Preliminary
Quartus II Handbook, Volume 1
Clocking Schemes ............................................................................................................................. 5–9
Checking Design Violations Using the Design Assistant .............................................................. 5–15
Quartus II Design Flow with the Design Assistant ................................................................... 5–15
The Design Assistant Settings Page ............................................................................................. 5–17
Message Severity Levels ................................................................................................................ 5–18
Design Assistant Rules .................................................................................................................. 5–18
Enabling and Disabling Design Assistant Rules ........................................................................ 5–37
Viewing Design Assistant Results ............................................................................................... 5–40
Targeting Clock and Register-Control Architectural Features ..................................................... 5–44
Clock Network Resources ............................................................................................................. 5–44
Reset Resources .............................................................................................................................. 5–45
Register Control Signals ................................................................................................................ 5–46
Conclusion ............................................................................................................................................ 5–46
Referenced Documents ....................................................................................................................... 5–46
Document Revision History.................................................................................................................5–47
Chapter 6. Recommended HDL Coding Styles
Introduction ............................................................................................................................................ 6–1
Quartus II Language Templates .......................................................................................................... 6–2
Using Altera Megafunctions ................................................................................................................ 6–3
Instantiating Altera Megafunctions in HDL Code ........................................................................... 6–4
Instantiating Megafunctions Using the MegaWizard Plug-In Manager .................................. 6–4
Creating a Netlist File for Other Synthesis Tools ........................................................................ 6–6
Instantiating Megafunctions Using the Port and Parameter Definition .................................. 6–7
Inferring Multiplier and DSP Functions from HDL Code ............................................................... 6–7
Multipliers—Inferring the lpm_mult Megafunction from HDL Code ..................................... 6–7
Multiply-Accumulators and Multiply-Adders—Inferring altmult_accum and altmult_add
Megafunctions from HDL Code .................................................................................................. 6–10
Inferring Memory Functions from HDL Code ................................................................................ 6–13
RAM Functions—Inferring altsyncram and altdpram Megafunctions from HDL Code .... 6–14
ROM Functions—Inferring altsyncram and lpm_rom Megafunctions from HDL Code .... 6–31
Shift Registers—Inferring the altshift_taps Megafunction from HDL Code ......................... 6–33
Coding Guidelines for Registers and Latches ................................................................................. 6–37
Register Power-Up Values in Altera Devices ............................................................................. 6–37
Secondary Register Control Signals Such as Clear and Clock Enable .................................... 6–39
Latches ............................................................................................................................................. 6–43
General Coding Guidelines ................................................................................................................ 6–48
Tri-State Signals .............................................................................................................................. 6–49
Adder Trees ..................................................................................................................................... 6–50
State Machines ................................................................................................................................ 6–52
Multiplexers .................................................................................................................................... 6–60
Cyclic Redundancy Check Functions .......................................................................................... 6–69
Comparators ................................................................................................................................... 6–71
Counters ........................................................................................................................................... 6–73
Designing with Low-Level Primitives .............................................................................................. 6–73
Conclusion ............................................................................................................................................ 6–74
Referenced Documents ....................................................................................................................... 6–74
Document Revision History ............................................................................................................... 6–75
viii
Preliminary
Altera Corporation
Contents
Section III. Synthesis
Chapter 7. Synplicity Synplify and Synplify Pro Support
Introduction ............................................................................................................................................ 7–1
Altera Device Family Support ...............................................................................................................7–2
Design Flow ............................................................................................................................................ 7–3
Output Netlist File Name and Result Format .............................................................................. 7–7
Synplify Optimization Strategies ........................................................................................................ 7–8
Implementations in Synplify Pro ................................................................................................... 7–8
Timing-Driven Synthesis Settings ................................................................................................. 7–9
FSM Compiler ................................................................................................................................. 7–11
Optimization Attributes and Options ......................................................................................... 7–12
Altera-Specific Attributes .............................................................................................................. 7–15
Exporting Designs to the Quartus II Software Using NativeLink Integration ........................... 7–17
Running the Quartus II Software from within the Synplify Software ................................... 7–18
Using the Quartus II Software to Run the Synplify Software .................................................. 7–19
Running the Quartus II Software Manually Using the Synplify-Generated Tcl Script ....... 7–19
Passing TimeQuest SDC Timing Constraints to the Quartus II Software in the .scf File .... 7–20
Passing Constraints to the Quartus II Software using Tcl Commands .................................. 7–22
Guidelines for Altera Megafunctions and Architecture-Specific Features ................................. 7–32
Instantiating Altera Megafunctions Using the MegaWizard Plug-In Manager .................... 7–33
Inferring Altera Megafunctions from HDL Code ...................................................................... 7–37
Incremental Compilation and Block-Based Design ........................................................................ 7–44
Hierarchy and Design Considerations with Multiple VQM Files .......................................... 7–46
Creating a Design with Separate Netlist Files ............................................................................ 7–46
Creating a Design with Multiple VQM Files Using Synplify Pro MultiPoint Synthesis ..... 7–47
Generating a Design with Multiple VQM Files Using Black Boxes ........................................ 7–54
Conclusion ............................................................................................................................................ 7–60
Referenced Documents .........................................................................................................................7–61
Document Revision History ............................................................................................................... 7–61
Chapter 8. Quartus II Integrated Synthesis
Introduction ............................................................................................................................................ 8–1
Design Flow ............................................................................................................................................ 8–2
Language Support ................................................................................................................................. 8–5
Verilog HDL Support ...................................................................................................................... 8–5
VHDL Support ................................................................................................................................ 8–10
AHDL Support ............................................................................................................................... 8–12
Schematic Design Entry Support ................................................................................................. 8–13
State Machine Editor ...................................................................................................................... 8–13
Design Libraries .............................................................................................................................. 8–14
Using Parameters/Generics ......................................................................................................... 8–18
Incremental Synthesis and Incremental Compilation .................................................................... 8–23
Partitions for Preserving Hierarchical Boundaries .................................................................... 8–23
Quartus II Synthesis Options ............................................................................................................. 8–24
Setting Synthesis Options ............................................................................................................. 8–25
Altera Corporation
ix
Preliminary
Quartus II Handbook, Volume 1
Optimization Technique ................................................................................................................ 8–30
Speed Optimization Technique for Clock Domains .................................................................. 8–30
PowerPlay Power Optimization .................................................................................................. 8–31
Restructure Multiplexers ............................................................................................................... 8–32
State Machine Processing .............................................................................................................. 8–34
Manually Specifying State Assignments Using the syn_encoding Attribute ....................... 8–35
Manually Specifying Enumerated Types Using the enum_encoding Attribute ................... 8–38
Safe State Machines ........................................................................................................................ 8–40
Power-Up Level .............................................................................................................................. 8–42
Power-Up Don’t Care .................................................................................................................... 8–43
Remove Duplicate Registers ......................................................................................................... 8–44
Remove Redundant Logic Cells ................................................................................................... 8–44
Preserve Registers .......................................................................................................................... 8–44
Disable Register Merging/Don’t Merge Register ...................................................................... 8–45
Noprune Synthesis Attribute/Preserve Fan-out Free Register Node .................................... 8–46
Keep Combinational Node/Implement as Output of Logic Cell ........................................... 8–47
Don't Retime, Disabling Synthesis Netlist Optimizations ....................................................... 8–48
Don't Replicate, Disabling Synthesis Netlist Optimizations .................................................... 8–49
Maximum Fan-Out ......................................................................................................................... 8–50
Controlling Clock Enable Signals with Auto Clock Enable Replacement and direct_enable ... ..
.............................................................................................................................................................8–51
Megafunction Inference Control .................................................................................................. 8–52
RAM Style and ROM Style—for Inferred Memory ................................................................... 8–55
Turning Off Add Pass-Through Logic to Inferred RAMs/ no_rw_check Attribute Setting .......
.............................................................................................................................................................8–57
RAM Initialization File—for Inferred Memory ......................................................................... 8–59
Multiplier Style—for Inferred Multipliers .................................................................................. 8–59
Full Case .......................................................................................................................................... 8–62
Parallel Case .................................................................................................................................... 8–63
Translate Off and On / Synthesis Off and On ........................................................................... 8–65
Ignore translate_off and synthesis_off Directives ..................................................................... 8–65
Read Comments as HDL ............................................................................................................... 8–66
Use I/O Flipflops ........................................................................................................................... 8–67
Specifying Pin Locations with chip_pin ..................................................................................... 8–68
Using altera_attribute to Set Quartus II Logic Options ............................................................ 8–70
Analyzing Synthesis Results .............................................................................................................. 8–73
Analysis and Synthesis Section of the Compilation Report ..................................................... 8–73
Project Navigator ............................................................................................................................ 8–74
Analyzing and Controlling Synthesis Messages ............................................................................. 8–74
Quartus II Messages ....................................................................................................................... 8–74
VHDL and Verilog HDL Messages ............................................................................................. 8–75
Node-Naming Conventions in Quartus II Integrated Synthesis .................................................. 8–79
Hierarchical Node-Naming Conventions ................................................................................... 8–79
Node-Naming Conventions for Registers (DFF or D Flipflop Atoms) .................................. 8–80
Register Changes During Synthesis ............................................................................................ 8–81
Preserving Register Names ........................................................................................................... 8–84
Node-Naming Conventions for Combinational Logic Cells ................................................... 8–84
x
Preliminary
Altera Corporation
Contents
Preserving Combinational Logic Names .................................................................................... 8–86
Scripting Support ................................................................................................................................. 8–86
Adding an HDL File to a Project and Setting the HDL Version .............................................. 8–87
Quartus II Synthesis Options ........................................................................................................ 8–88
Assigning a Pin ............................................................................................................................... 8–89
Creating Design Partitions for Incremental Compilation ........................................................ 8–90
Conclusion ............................................................................................................................................ 8–91
Referenced Documents ....................................................................................................................... 8–91
Document Revision History.................................................................................................................8–92
Chapter 9. Mentor Graphics LeonardoSpectrum Support
Introduction ............................................................................................................................................ 9–1
Design Flow ............................................................................................................................................ 9–2
Optimization Strategies ........................................................................................................................ 9–5
Timing-Driven Synthesis ................................................................................................................ 9–5
Other Constraints ............................................................................................................................. 9–6
Timing Analysis with the Leonardo-Spectrum Software ................................................................ 9–8
Exporting Designs Using NativeLink Integration ............................................................................ 9–9
Generating Netlist Files ................................................................................................................... 9–9
Including Design Files for Black-Boxed Modules ....................................................................... 9–9
Passing Constraints with Scripts .................................................................................................... 9–9
Integration with the Quartus II Software ................................................................................... 9–10
Guidelines for Altera Megafunctions and LPM Functions ........................................................... 9–10
Inferring Multipliers and DSP Functions ................................................................................... 9–12
Controlling DSP Block Inference ................................................................................................. 9–13
Block-Based Design with the Quartus II Software ......................................................................... 9–19
Hierarchy and Design Considerations ........................................................................................ 9–20
Creating a Design with Multiple EDIF Files .............................................................................. 9–21
Generating Multiple EDIF Files Using Black Boxes .................................................................. 9–25
Incremental Synthesis Flow .......................................................................................................... 9–31
Conclusion ............................................................................................................................................ 9–34
Referenced Documents ....................................................................................................................... 9–34
Document Revision History.................................................................................................................9–35
Chapter 10. Mentor Graphics Precision RTL Synthesis Support
Introduction .......................................................................................................................................... 10–1
Device Family Support .........................................................................................................................10–2
Design Flow .......................................................................................................................................... 10–2
Creating a Project and Compiling the Design ...................................................................................10–6
Creating a Project ........................................................................................................................... 10–6
Compiling the Design .................................................................................................................... 10–7
Mapping the Precision Synthesis Design ......................................................................................... 10–7
Setting Timing Constraints ........................................................................................................... 10–8
Setting Mapping Constraints ........................................................................................................ 10–9
Assigning Pin Numbers and I/O Settings .................................................................................. 10–9
Assigning I/O Registers .............................................................................................................. 10–10
Disabling I/O Pad Insertion ....................................................................................................... 10–11
Altera Corporation
xi
Preliminary
Quartus II Handbook, Volume 1
Controlling Fan-Out on Data Nets ............................................................................................ 10–12
Synthesizing the Design and Evaluating the Results ................................................................... 10–13
Obtaining Accurate Logic Utilization and Timing Analysis Reports ................................... 10–13
Exporting Designs to the Quartus II Software Using NativeLink Integration ......................... 10–14
Running the Quartus II Software from within the Precision RTL Software ....................... 10–14
Running the Quartus II Software Manually Using the Precision RTL Synthesis-Generated Tcl
Script .............................................................................................................................................. 10–16
Using Quartus II Software to Launch the Precision RTL Synthesis Software ..................... 10–17
Passing Constraints to the Quartus II Software ....................................................................... 10–17
Megafunctions and Architecture-Specific Features ...................................................................... 10–23
Instantiating Altera Megafunctions Using the MegaWizard Plug-In Manager .................. 10–24
Inferring Altera Megafunctions from HDL Code .................................................................... 10–25
Incremental Compilation and Block-Based Design ...................................................................... 10–32
Hierarchy and Design Considerations ...................................................................................... 10–34
Creating a Design with Separate Netlist Files .......................................................................... 10–34
Creating Quartus II Projects for Multiple EDIF Files .............................................................. 10–39
Conclusion .......................................................................................................................................... 10–41
Referenced Documents .......................................................................................................................10–42
Document Revision History ............................................................................................................. 10–42
Chapter 11. Synopsys Design Compiler FPGA Support
Introduction .......................................................................................................................................... 11–1
Design Flow Using the DC FPGA Software and the Quartus II Software .................................. 11–2
Setup of the DC FPGA Software Environment for Altera Device Families ................................ 11–3
Megafunctions and Architecture-Specific Features..........................................................................11–5
Instantiating Altera Megafunctions Using the MegaWizard Plug-In Manager ......................... 11–6
Clear Box Methodology ................................................................................................................. 11–6
Black Box Methodology ................................................................................................................. 11–9
Inferring Altera Megafunctions from HDL Code ......................................................................... 11–11
Reading Design Files into the DC FPGA Software ....................................................................... 11–13
Selecting a Target Device .................................................................................................................. 11–15
Timing and Synthesis Constraints .................................................................................................. 11–16
Compilation and Synthesis .............................................................................................................. 11–18
Reporting Design Information ......................................................................................................... 11–20
Saving Synthesis Results .................................................................................................................. 11–21
Exporting Designs to the Quartus II Software .............................................................................. 11–22
write_fpga Command .................................................................................................................. 11–22
write and write_par_constraint Commands ............................................................................ 11–23
Using Tcl Scripts with Quartus II Software ................................................................................... 11–23
Place and Route with the Quartus II Software .............................................................................. 11–25
Formality Software Support ............................................................................................................. 11–26
Conclusion .......................................................................................................................................... 11–26
Referenced Documents ..................................................................................................................... 11–26
Document Revision History...............................................................................................................11–27
Chapter 12. Analyzing Designs with Quartus II Netlist Viewers
Introduction .......................................................................................................................................... 12–1
xii
Preliminary
Altera Corporation
Contents
When to Use Viewers: Analyzing Design Problems ...................................................................... 12–2
Quartus II Design Flow with Netlist Viewers ................................................................................. 12–3
RTL Viewer Overview ........................................................................................................................ 12–4
State Machine Viewer Overview ....................................................................................................... 12–6
Technology Map Viewer Overview .................................................................................................. 12–6
Introduction to the User Interface ..................................................................................................... 12–7
Schematic View ............................................................................................................................... 12–8
Hierarchy List ............................................................................................................................... 12–16
State Machine Viewer .................................................................................................................. 12–18
Navigating the Schematic View ...................................................................................................... 12–21
Traversing and Viewing the Design Hierarchy ....................................................................... 12–21
Viewing Contents of Atom Primitives in the Technology Map Viewer .............................. 12–22
Viewing the Properties of Instances and Primitives ............................................................... 12–24
Viewing LUT Representations in the Technology Map Viewer ............................................ 12–24
Zooming and Magnification ....................................................................................................... 12–26
Partitioning the Schematic into Pages ....................................................................................... 12–28
Customizing the Schematic Display in the RTL Viewer .............................................................. 12–31
Grouping Combinational Logic into Logic Clouds ................................................................. 12–32
Filtering in the Schematic View ....................................................................................................... 12–34
Filter Sources Command ............................................................................................................. 12–35
Filter Destinations Command .................................................................................................... 12–35
Filter Sources and Destinations Command .............................................................................. 12–36
Filter Between Selected Nodes Command ............................................................................... 12–36
Filter Selected Nodes and Nets Command .............................................................................. 12–37
Filter Bus Index Command ......................................................................................................... 12–37
Filter Command Processing ........................................................................................................ 12–37
Filtering Across Hierarchies ....................................................................................................... 12–38
Expanding a Filtered Netlist ....................................................................................................... 12–40
Reducing a Filtered Netlist ......................................................................................................... 12–41
Probing to Source Design File and Other Quartus II Windows ................................................. 12–42
Moving Selected Nodes to Other Quartus II Windows .......................................................... 12–42
Probing to the Viewers from Other Quartus II Windows ........................................................... 12–44
Viewing a Timing Path ..................................................................................................................... 12–45
Other Features in the Schematic Viewer ........................................................................................ 12–47
Tooltips .......................................................................................................................................... 12–47
Radial Menu .................................................................................................................................. 12–50
Rollover .......................................................................................................................................... 12–52
Displaying Net Names ................................................................................................................ 12–53
Displaying Node Names ............................................................................................................. 12–53
Find Command ............................................................................................................................. 12–53
Exporting and Copying a Schematic Image ............................................................................. 12–55
Printing .......................................................................................................................................... 12–55
Debugging HDL Code with the State Machine Viewer ............................................................... 12–56
Simulation of State Machine Gives Unexpected Results ........................................................ 12–56
Conclusion .......................................................................................................................................... 12–60
Document Revision History...............................................................................................................12–60
Altera Corporation
xiii
Preliminary
Quartus II Handbook, Volume 1
xiv
Preliminary
Altera Corporation
Chapter Revision Dates
The chapters in this book, Quartus II Handbook, Volume 1, were revised on the following dates. Where
chapters or groups of chapters are available separately, part numbers are listed.
Chapter 1. Design Planning with the Quartus II Software
Revised:
October 2007
Part number: QII51016-7.2.0
Chapter 2. Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Revised:
October 2007
Part number: QII51015-7.2.0
Chapter 3. Quartus II Design Flow for MAX+PLUS II Users
Revised:
October 2007
Part number: QII51002-7.2.0
Chapter 4. Quartus II Support for HardCopy Series Devices
Revised:
October 2007
Part number: QII51004-7.2.0
Chapter 5. Design Recommendations for Altera Devices and the Quartus II Design Assistant
Revised:
October 2007
Part number: QII51006-7.2.0
Chapter 6. Recommended HDL Coding Styles
Revised:
October 2007
Part number: QII51007-7.2.0
Chapter 7. Synplicity Synplify and Synplify Pro Support
Revised:
October 2007
Part number: QII51009-7.2.0
Chapter 8. Quartus II Integrated Synthesis
Revised:
October 2007
Part number: QII51008-7.2.0
Chapter 9. Mentor Graphics LeonardoSpectrum Support
Revised:
October 2007
Part number: QII51010-7.2.0
Altera Corporation
xv
Preliminary
Chapter Revision Dates
Quartus II Handbook, Volume 1
Chapter 10. Mentor Graphics Precision RTL Synthesis Support
Revised:
October 2007
Part number: QII51011-7.2.0
Chapter 11. Synopsys Design Compiler FPGA Support
Revised:
October 2007
Part number: QII51014-7.2.0
Chapter 12. Analyzing Designs with Quartus II Netlist Viewers
Revised:
October 2007
Part number: QII51013-7.2.0
xvi
Preliminary
Altera Corporation
About this Handbook
This handbook provides comprehensive information about the Altera®
Quartus® II design software, version 7.2.
How to Contact
Altera
For the most up-to-date information about Altera products, refer to the
following table.
Information Type
Contact (1)
Technical support
www.altera.com/mysupport/
Technical training
www.altera.com/training/
[email protected]
Product literature
www.altera.com/literature/
Altera literature services
[email protected] (1)
FTP site
ftp.altera.com
Note to table:
(1)
Third-Party
Software
Product
Information
Altera Corporation
You can also contact your local Altera sales office or sales representative.
Third-party software products described in this handbook are not Altera
products, are licensed by Altera from third parties, and are subject to change
without notice. Updates to these third-party software products may not be
concurrent with Quartus II software releases. Altera has assumed
responsibility for the selection of such third-party software products and its
use in the Quartus II 7.2 software release. To the extent that the software
products described in this handbook are derived from third-party software, no
third party warrants the software, assumes any liability regarding use of the
software, or undertakes to furnish you any support or information relating to
the software. EXCEPT AS EXPRESSLY SET FORTH IN THE APPLICABLE
ALTERA PROGRAM LICENSE SUBSCRIPTION AGREEMENT UNDER
WHICH THIS SOFTWARE WAS PROVDED TO YOU, ALTERA AND
THIRD-PARTY LICENSORS DISCLAIM ALL WARRANTIES WITH
RESPECT TO THE USE OF SUCH THIRD-PARTY SOFTWARE CODE OR
DOCUMENTATION IN THE SOFTWARE, INCLUDING, WITHOUT
LIMITATION, ANY WARRANTIES OF MERCHANTABILITY, FITNESS FOR
A PARTICULAR PURPOSE, TITLE, AND NONINFRINGEMENT. For more
information, including the latest available version of specific third-party
software products, refer to the documentation for the software in question.
xvii
Preliminary
Typographic Conventions
Typographic
Conventions
Visual Cue
Quartus II Handbook, Volume 1
This document uses the typographic conventions shown below.
Meaning
Bold Type with Initial
Capital Letters
Command names, dialog box titles, checkbox options, and dialog box options are
shown in bold, initial capital letters. Example: Save As dialog box.
bold type
External timing parameters, directory names, project names, disk drive names,
filenames, filename extensions, and software utility names are shown in bold type.
Examples: fMAX, \qdesigns directory, d: drive, chiptrip.gdf file.
Italic Type with Initial
Capital Letters
Document titles are shown in italic type with initial capital letters. Example: AN 75: HighSpeed Board Design.
Italic type
Internal timing parameters and variables are shown in italic type.
Examples: tPIA, n + 1.
Variable names are enclosed in angle brackets (< >) and shown in italic type. Example:
<file name>, <project name>.pof file.
Initial Capital Letters
Keyboard keys and menu names are shown with initial capital letters. Examples: Delete
key, the Options menu.
“Subheading Title”
References to sections within a document and titles of on-line help topics are shown in
quotation marks. Example: “Typographic Conventions.”
Courier type
Signal and port names are shown in lowercase Courier type. Examples: data1, tdi,
input. Active-low signals are denoted by suffix n, e.g., resetn.
Anything that must be typed exactly as it appears is shown in Courier type. For
example: c:\qdesigns\tutorial\chiptrip.gdf. Also, sections of an actual
file, such as a Report File, references to parts of files (e.g., the AHDL keyword
SUBDESIGN), as well as logic function names (e.g., TRI) are shown in Courier.
1., 2., 3., and
a., b., c., etc.
Numbered steps are used in a list of items when the sequence of the items is important,
such as the steps listed in a procedure.
v, —, N/A
Used in table cells to indicate the following: v indicates a “Yes” or “Applicable”
statement; — indicates a “No” or “Not Supported” statement; N/A indicates that the
table cell entry is not applicable to the item of interest.
■
Bullets are used in a list of items when the sequence of the items is not important.
●
•
v
The checkmark indicates a procedure that consists of one step only.
1
The hand points to information that requires special attention.
c
A caution calls attention to a condition or possible situation that can damage or destroy
the product or the user’s work.
w
A warning calls attention to a condition or possible situation that can cause injury to the
user.
r
The angled arrow indicates you should press the Enter key.
f
The feet direct you to more information on a particular topic.
xviii
Preliminary
Altera Corporation
Section I. Design Flows
The Altera® Quartus® II, version 7.2 design software provides a complete
multi-platform design environment that easily adapts to your specific
design needs. The Quartus II software also allows you to use the
Quartus II graphical user interface, EDA tool interface, or command-line
interface for each phase of the design flow. This section explains the
Quartus II, version 7.2 software options that are available for each of
these flows.
This section includes the following chapters:
■
■
■
■
1
Altera Corporation
Chapter 1, Design Planning with the Quartus II Software
Chapter 2, Quartus II Incremental Compilation for Hierarchical and
Team-Based Design
Chapter 3, Quartus II Design Flow for MAX+PLUS II Users
Chapter 4, Quartus II Support for HardCopy Series Devices
For information about the revision history for chapters in this
section, refer to each individual chapter for that chapter’s
revision history.
Section I–i
Design Flows
Section I–ii
Quartus II Handbook, Volume 1
Altera Corporation
1. Design Planning with the
Quartus II Software
QII51016-7.2.0
Introduction
Due to the significant increase in FPGA device densities over the last few
years, designs are increasingly complex and may involve multiple
designers. The inherent flexibility of advanced FPGAs means that the pin
layout, power consumption, and timing performance for each design
block are all dependent on the final design implementation. The system
architect must resolve these design issues when integrating design
blocks, often leading to problems that affect the overall time to market
and thereby increase cost. Many potential problems can be solved earlier
in the design cycle by selecting the optimal device and programming
method, properly planning I/O pin locations, estimating power
consumption, selecting appropriate third-party tools, planning for
in-system debugging options, performing good design partitioning for
incremental compilation, and obtaining early timing estimates.
This chapter discusses these important FPGA design planning issues,
provides recommendations, and describes various tools available for
Altera® FPGAs to help you improve design productivity. This chapter
contains the following sections:
■
■
■
■
■
■
■
“Device and Programming/ Configuration Method Selection” on
page 1–2
“Early Planning Tools for Power and I/O” —“Early Power
Estimation” on page 1–5
“Early Pin Planning and I/O Analysis” on page 1–6
“Selecting Third-Party EDA Tool Flows” on page 1–9
“Planning for On-Chip Debugging Options” on page 1–11
“Planning for an Incremental Compilation Flow” on page 1–13
“Early Timing Estimation” on page 1–19
Before reading the design planning guidelines discussed in this chapter,
consider your design priorities: What are the important factors for your
design? More device features, density, or performance can increase
system cost. Signal integrity and board issues may impact I/O pin
locations. Power, timing performance, and area utilization affect each
other, and compilation time is affected by optimizations for these factors.
The Quartus® II software optimizes designs for the best average results,
but you can change settings to focus on one aspect of the design results
and trade off other aspects. Certain tools or debugging options can lead
to restrictions in your design flow. If you know what is important in a
particular design, this knowledge will help you choose the tools, features,
and methodologies that you should use with the design. This chapter
Altera Corporation
October 2007
1–1
Quartus II Handbook, Volume 1
cannot cover every possible consideration for planning a complex FPGA
design, but once you understand your design priorities, you can use the
design planning issues described here as a guide to help ensure a
productive and successful FPGA design flow.
f
Device and
Programming/
Configuration
Method
Selection
This chapter provides an introduction to various design and planning
features in the Quartus® II software. For a general overview of the
Quartus II design flow and features, refer to the Introduction to Quartus II
Manual. For more details about specific Quartus II features and
methodologies, this chapter provides references to other appropriate
chapters in the Quartus II Handbook.
The first stage in design planning is choosing the best device for your
application and determining how you want to program or configure the
device in your system. These factors affect the rest of your design cycle,
including board specification and layout. Most of this planning is
performed outside of the Quartus II software, but this section provides a
few suggestions to aid in the planning process.
Device Selection
It is important to choose the device family that best suits your design
needs. Different families offer different trade-offs, including cost,
performance, logic and memory density, I/O density, power utilization,
and packaging. You should also consider feature requirements such as
I/O standards support, high-speed transceivers, and the number of
phase-locked loops (PLLs) available in the device. You can review
important features of each device family in the Selector Guides available
on the Altera website (www.altera.com/literature/lit-sg.jsp). Each device
family also has a device handbook or set of data sheets that documents
the device features in detail.
Determining the required device density can be a challenging part of the
design planning process. Devices with more logic resources and higher
I/O counts can implement larger and potentially more complex designs,
but may have a higher cost. Select a device that meets your design needs
with some safety margin, in case you want to add more logic later in the
design cycle or reserve logic and memory for on-chip debugging (refer to
“Planning for On-Chip Debugging Options” on page 1–11). Consider
needs for specific types of dedicated logic blocks, such as memory blocks
of different sizes, or digital signal processing (DSP) blocks to implement
certain arithmetic functions.
If you have prior designs targeting Altera devices, you can use their
resource utilization as an estimate for your new design. You can compile
existing designs in the Quartus II software with the device selection set to
1–2
Altera Corporation
October 2007
Design Planning with the Quartus II Software
Auto to review the resource utilization and find out which device density
fits the design. Note that coding style, device architecture, and the
optimization options used in the Quartus II software can significantly
affect a design’s resource utilization.
To obtain resource utilization estimates for certain configurations of
Altera’s intellectual property (IP) designs, refer to the User Guides for
Altera Megafunctions and IP MegaCores on the IP Megafunctions page
on the Altera website (www.altera.com/literature/lit-ip.jsp). You can use
these numbers to help estimate the resource utilization of your design.
Device Migration Planning
Determine if you want the option of migrating your design to another
device density to allow flexibility when the design nears completion, or if
you want to migrate to a HardCopy® structured ASIC device when the
design reaches volume production. In some cases, designers may target a
smaller (and less expensive) device and then move to a larger device if
necessary to fit their design. Other designers may prototype their design
in a larger device to reduce optimization time and achieve timing closure
more quickly, and then migrate to a final smaller device after
prototyping. Similarly, many designers compile and optimize their
design for an FPGA device before moving to a HardCopy structured
ASIC when the design is complete and ready for higher-volume
production. If you would like this flexibility, you should specify these
migration options in the Quartus II software at the beginning of your
design cycle. Specify the target migration devices in the Migration
compatibility section of the Device page in the Settings dialog box.
Selecting a migration device has an impact on pin placement because
some pins may serve different functions in different device densities or
package sizes. When making pin assignments in the Quartus II software,
the Pin Migration View in the Pin Planner highlights pins that change
function between your migration devices. (Refer to “Early Pin Planning
and I/O Analysis” on page 1–6 for more details.) Selecting a migration
device may force you to restrict logic utilization to ensure that your
design is compatible with a selected HardCopy device. Adding migration
devices later in the design cycle is possible, but requires extra effort to
check pin assignments, and may require design changes to fit into the
new target device. It is much easier to consider these issues early in the
design cycle than at the end, when the design is near completion and
ready for migration.
Altera Corporation
October 2007
1–3
Quartus II Handbook, Volume 1
In addition, if you are planning to use a HardCopy device, review
HardCopy guidelines early in the design cycle for any Quartus II settings
that should be used or other restrictions you should consider. It is
especially important to use complete timing constraints if you want to
migrate to a HardCopy device because of the rigorous verification
requirements for structured ASICs.
f
For more information about timing requirements and analysis for
HardCopy designs, refer to the HardCopy Handbook.
Programming/Configuration Method Selection
Choosing your programming or configuration method up-front allows
system and board designers to determine what companion devices, if
any, are needed for your system. Your board layout also depends on the
type of programming or configuration method you plan to use for
programmable devices. Many programming options use a JTAG interface
to connect to the devices, so your design may require a JTAG chain be set
up on the board.
The device family handbooks describe the configuration options
available for a given device family. For more details about configuration
options, refer to the Configuration Handbook. For information about
programming CPLD devices, refer to your device data sheet or
handbook. Programming and configuration of Altera devices includes
the following options:
■
■
■
■
1–4
Using enhanced configuration devices—These devices combine
industry-standard flash memory with a feature-rich configuration
controller, including device features such as concurrent and dynamic
configuration, data compression, clock division, and an external
flash memory interface. You can also implement remote and local
system updates with enhanced configuration devices.
Using Flash memory devices with a memory controller, such as an
Altera MAX® device—The flash memory controller can interface
with a PC or microprocessor to receive configuration data via a
parallel port.
Using the Quartus II Serial Flash Loader (SFL)—This scheme allows
you to configure the FPGA and program serial configuration devices
using the same JTAG interface.
Using the Quartus II Parallel Flash Loader (PFL)—This solution
quickly retrieves data from a JTAG interface and generates data
formatted for the receiving target flash device, significantly reducing
the flash device programming time. If your system already contains
a common flash interface (CFI) flash memory, you can utilize it for
the FPGA configuration storage as well, because the PFL feature
supports many common industry-standard flash devices. If you
Altera Corporation
October 2007
Design Planning with the Quartus II Software
choose this method, you should check the list of supported flash
devices early in your system design cycle and plan accordingly.
Refer to AN 386: Using the MAX II Parallel Flash Loader with the
Quartus II Software for the list of supported Flash devices.
Early Planning
Tools for Power
and I/O
You can use the Quartus II early power and I/O planning tools to provide
information to PCB board and system designers. Providing FPGA device
information early in the design process enables earlier planning for
power and board design requirements. You can perform early power
estimation, as well as early pin planning and analysis, before you have
created any source code, or when you have a preliminary version of the
design, and then perform the most accurate analysis when the design is
complete.
Early Power Estimation
Device power consumption must be accurately estimated to develop an
appropriate power budget and to design the power supplies, voltage
regulators, heat sink, and cooling system. Power estimation and analysis
has two significant planning requirements:
■
■
Thermal planning—You must ensure that the cooling solution is
sufficient to dissipate the heat generated by the device. In particular,
the computed junction temperature must fall within normal device
specifications.
Power supply planning—Power supplies must provide adequate
current to support device operation.
Power consumption in FPGA devices is dependent on the design,
providing a challenge during early board specification and layout. The
Altera PowerPlay Early Power Estimator spreadsheet allows you to
estimate power utilization before the design is complete, by processing
information about the device resources that will be used in the design, as
well as the operating frequency, toggle rates, and environmental
considerations.
If you have an existing design or a partially-completed design, the power
estimator file generated by the Quartus II software can provide input to
the spreadsheet for your current design (refer to “Early Power Estimator
File” on page 1–6).
When the design is complete, the PowerPlay Power Analyzer tool in the
Quartus II software provides an accurate estimation of power to help
ensure that thermal and supply budgets are not violated.
Altera Corporation
October 2007
1–5
Quartus II Handbook, Volume 1
The PowerPlay Early Power Estimator spreadsheets for each supported
device family are available on the Altera website:
(www.altera.com/support/devices/estimator/pow-powerplay.jsp).
Estimating power consumption early in the design cycle allows planning
of power budgets and avoids surprises for designers developing the PCB.
f
For more information about power estimation and analysis, refer to the
PowerPlay Power Analysis chapter in volume 3 of the Quartus II Handbook.
Early Power Estimator File
When entering data into the Early Power Estimator spreadsheet, you
must include the device resources, operating frequency, toggle rates, and
other parameters. Specifying these values requires familiarity with the
design. If you do not have an existing design, estimate the number of
device resources used in your design and enter it manually. If you have
an existing design or a partially completed design, you can generate a
power estimator file.
First, compile your design in the Quartus II software. After compilation
is complete, on the Project menu, click Generate PowerPlay Early Power
Estimator File. This command instructs the Quartus II software to write
out a power estimator Comma-Separated Value (.csv) file (or a text [.txt]
file for older device families).
The PowerPlay Early Power Estimator spreadsheet includes the Import
Data macro, which parses the information in the power estimation file
and transfers it into the spreadsheet. If you do not want to use the macro,
you can transfer the data into the Early Power Estimator spreadsheet
manually.
If the existing Quartus II project represents only a portion of your full
design, you should enter the additional resources used in the final design
manually. You can edit the spreadsheet and add additional device
resources after importing the power estimation file information.
Early Pin Planning and I/O Analysis
It is important to plan top-level FPGA I/O pins early, so board designers
can start developing the PCB design and layout. The FPGA device’s I/O
capabilities influence pin locations and other types of assignments. In
cases where the board design team specifies an FPGA pin-out, it is crucial
that the pin locations be verified in the FPGA place-and-route software as
soon as possible to avoid the need for board design changes.
1–6
Altera Corporation
October 2007
Design Planning with the Quartus II Software
Traditionally, designers and system architects could not check the
validity of FPGA pin assignments until the design was complete. You can
now create a preliminary pin-out for an Altera FPGA using the Quartus
II Pin Planner before the source code is designed, based on standard I/O
interfaces (such as memory and bus interfaces) and any other I/O-related
assignments defined by system requirements. Refer to “Creating a TopLevel Design File for I/O Analysis” on page 1–8. Quartus II I/O
Assignment Analysis checks that the pin locations and assignments are
supported in the target FPGA architecture. You can use I/O Assignment
Analysis to validate I/O-related assignments that you make or modify
throughout the design process.
The Pin Planner enables easy I/O pin assignment planning, assignment,
and validation. Use the Pin Planner Package view to make pin location
and other assignments using a device package view instead of pin
numbers. The Pads view displays I/O pads in order around the silicon
die to help you follow pad distance and pin placement guidelines. With
the Pin Planner, you can identify I/O banks, voltage reference (VREF)
groups, and differential pin pairings to help you through the I/O
planning process. If migration devices are selected (including HardCopy
devices), as described in “Device Migration Planning” on page 1–3, the
Pin Migration view highlights pins that change function in the migration
device when compared to the currently selected device. Selecting pins in
the Device Migration view cross-probes to the rest of the Pin Planner, so
you can use device migration information when planning your pin
assignments. You can also configure board trace models of selected pins
for use in “board-aware” signal integrity reports generated with the
Enable Advanced I/O Timing option. You have the option to use a
Microsoft Excel spreadsheet to start the I/O planning process if you
normally use a spreadsheet in your design flow, and you can export a
Comma-Separated Value (.csv) file containing your I/O assignments for
spreadsheet use when all pins are assigned.
When planning is complete, the pin location information can be passed to
PCB designers. The Pin Planner is tightly integrated with certain PCB
design EDA tools, and can read pin location changes from these tools to
check the suggested changes. It is important that pin assignments match
between the Quartus II software and your schematic and board layout
tools to ensure the design works correctly on the board where it is placed,
especially if changes to the pin-out must be made. The system architect
can use the Quartus II software to pass pin information to team members
designing individual logic blocks, for better timing closure when they
compile their design. Once the design is complete, the Quartus II Fitter
reports should be used for the final sign-off of pin assignments.
Altera Corporation
October 2007
1–7
Quartus II Handbook, Volume 1
Starting FPGA pin planning early—before the HDL design is complete—
improves the confidence in early board layouts, reduces the chance of
error, and improves the design’s overall time to market.
f
For more information about I/O assignment and analysis, refer to the
I/O Management chapter in volume 2 of the Quartus II Handbook. For more
information about passing I/O information between the Quartus II
software and third-party EDA tools, refer to the Mentor Graphics PCB
Design Tools Support and Cadence PCB Design Tools Support chapters in
the I/O and PCB Tools section in volume 2 of the Quartus II Handbook.
Creating a Top-Level Design File for I/O Analysis
Early in the design process, before the source code is created, the system
architect typically has information about the I/O interfaces and IP cores
that to used in the design. You can use this information with the
Create/Import Megafunction feature in the Pin Planner to specify details
about the design I/O interfaces.
The Pin Planner interfaces with the MegaWizard® Plug-In Manager, and
allows you to create or import custom megafunctions and IP cores that
use I/O interfaces. Configure the way in which they are connected to
each other by specifying matching node names for selected ports in the
Set Up Top-Level Design File dialog box. Make any other I/O-related
assignments for these interfaces or other design I/O pins in the Pin
Planner.
When you have entered as much information as possible, generate a
top-level design netlist file using the Create Top-Level Design File
command. The Pin Planner creates virtual pin assignments for internal
nodes, so internal nodes will not be assigned to device pins during
compilation. Use the generated netlist to perform I/O Analysis with the
Start I/O Assignment Analysis command.
You can use the I/O analysis results to change pin assignments or IP
parameters and repeat the checking process until the I/O interface meets
your design requirements and passes the pin checks in the Quartus II
software. When this initial pin planning is complete, you can create a
Quartus II Revision based on the Quartus II-generated netlist. You then
have a choice for how to proceed: you can use the generated netlist to
develop the top-level file for the actual design, or disregard the generated
netlist and use the generated Quartus II Settings File (.qsf) with the actual
design.
1–8
Altera Corporation
October 2007
Design Planning with the Quartus II Software
Selecting ThirdParty EDA Tool
Flows
Your complete FPGA design flow may include third-party EDA tools in
addition to the Quartus II software. Determine which tools you want to
use with the Quartus II software to ensure that they are supported and set
up correctly, and that you are aware of any useful features or undesired
limitations.
Synthesis Tools
You can synthesize your design using the Quartus II software’s
integrated synthesis tool or your preferred third-party synthesis tool.
Different synthesis tools may give different results. If you want to select
the best-performing tool for your application, you can experiment by
synthesizing typical designs for your application and coding style and
comparing the results. Be sure to perform placement and routing in the
Quartus II software to get accurate timing analysis and logic utilization
results. Results from synthesis are estimates before place-and-route and
do not include logic that is treated as a black box for synthesis (such as
megafunctions or Altera IP cores in some synthesis tools). In addition,
these estimates do not take into account logic usage reduction achieved
in the Quartus II Fitter through register packing or other Quartus II
optimizations, such as Physical Synthesis, that may change both timing
and resource utilization results.
Altera recommends that you use the most recent version of third-party
synthesis tools, because tool vendors are continuously adding new
features, fixing tool issues, and enhancing performance for Altera
devices. The Quartus II Release Notes lists the version of each synthesis tool
that is officially supported by that version of the Quartus II software.
Specify your synthesis tool in the New Project Wizard or the EDA Tools
Settings page of the Settings dialog box to use the correct Library
Mapping File for your synthesis netlist.
Synthesis tools may offer the capability to create a Quartus II project and
pass constraints such as the EDA tool setting, device selection, and timing
requirements that you specified in your synthesis project. You can use
this capability to save time when setting up your Quartus II project for
placement and routing.
If you want to take advantage of an incremental compilation
methodology, you should partition your design for synthesis and
generate multiple output netlist files. Refer to “Incremental Compilation
with Design Partitions” on page 1–14 for more information.
f
Altera Corporation
October 2007
For more information about synthesis tool flows, refer to the appropriate
chapter in the Synthesis section in volume 1 of the Quartus II Handbook.
1–9
Quartus II Handbook, Volume 1
Simulation Tools
You can use the built-in Quartus II Simulator to perform quick and easy
functional and timing simulations. Altera also provides the
ModelSim-Altera simulator with Quartus II license subscriptions, which
allows you to take advantage of advanced testbench capabilities and
other features. In addition, the Quartus II software can generate timing
netlist files to support other third-party simulation tools.
If you use a third-party simulation tool, ensure that you use the software
version that is supported with your Quartus II version. The Quartus II
Release Notes list the version of each simulation tool that is officially
supported with that particular version of the Quartus II software. Also
ensure that you use the model libraries provided with your Quartus II
software version. Libraries can change between versions, which might
cause a mismatch with your simulation netlist.
Specify your simulation tool in the EDA Tools Settings page of the
Settings dialog box to generate the appropriate output simulation netlist.
f
For more information about simulation tool flows, refer to the
appropriate chapter in the Simulation section in volume 3 of the
Quartus II Handbook.
Formal Verification Tools
The Quartus II software supports some formal verification flows.
Consider whether your desired formal verification flow impacts the
design and compilation stages of your design.
Using a formal verification flow can impact performance results because
it requires that certain logic optimizations be turned off, such as register
retiming, and forces hierarchy blocks to be preserved, which can restrict
optimization. Formal verification treats memory blocks as black boxes.
Therefore, it is best to keep memory in a separate hierarchy block so that
other logic does not get incorporated into the black box for verification.
There are other restrictions that may also limit your design, so consult the
documentation for details. If formal verification is important to your
design, it is easier to plan for limitations and restrictions in the beginning
than to make changes later in the design flow.
Specify your formal verification tool in the EDA Tools Settings page of
the Settings dialog box to generate the appropriate output netlist.
f
1–10
For more information about formal verification flows, refer to the
appropriate chapter in the Formal Verification section in volume 3 of the
Quartus II Handbook.
Altera Corporation
October 2007
Design Planning with the Quartus II Software
Planning for
On-Chip
Debugging
Options
Altera’s in-system debugging tools offer different advantages and
trade-offs, so different debugging tools may work better for different
systems and different designers. It is beneficial to evaluate on-chip
debugging options early in your design process, to ensure that your
system board, Quartus II project, and design are all set up to support the
appropriate options. Planning can reduce time spent during debugging
and eliminate the need to make changes later to accommodate your
preferred debugging methodologies.
The Quartus II portfolio of verification tools includes the following
in-system debugging features:
■
■
■
■
■
Altera Corporation
October 2007
SignalProbe incremental routing—This feature makes design
verification more efficient by quickly routing internal signals to I/O
pins without affecting the design. Starting with a fully routed design,
you can select and route signals for debugging to either previously
reserved or currently unused I/O pins.
SignalTap® II Embedded Logic Analyzer—This logic analyzer helps
you debug an FPGA design by probing the state of the internal
signals in the design without the use of external equipment or extra
I/O pins, while the design is running at full speed in an FPGA
device. Defining custom trigger-condition logic provides greater
accuracy and improves the ability to isolate problems. The SignalTap
II Embedded Logic Analyzer does not require external probes or
changes to the design files to capture the state of the internal nodes
or I/O pins in the design; all captured signal data is conveniently
stored in device memory until you are ready to read and analyze the
data.
Logic Analyzer Interface—This interface enables you to connect and
transmit internal FPGA signals to an external logic analyzer for
analysis. You can use this feature to connect a large set of internal
device signals to a small number of output pins for debugging
purposes, and allows you to take advantage of advanced features in
your external logic analyzer or mixed signal oscilloscope.
In-System Memory Content Editor—This feature provides read and
write access to in-system FPGA memories and constants through the
JTAG interface, making it easy to test changes to memory contents
and constant values in the FPGA while the device is functioning in a
system.
In-System Sources and Probes—This feature sets up customized
register chains to drive or sample the instrumented nodes in your
logic design, providing an easy way to input simple virtual stimuli
and an easy way to capture the current value of instrumented nodes.
You can force trigger conditions set up using the SignalTap II Logic
Analyzer, create simple test vectors to exercise your design without
the use of external test equipment, and dynamically control run-time
control signals with the JTAG chain.
1–11
Quartus II Handbook, Volume 1
■
f
Virtual JTAG Megafunction—The sld_virtual_jtag megafunction
allows you to build your own system-level debugging infrastructure,
including both processor-based debugging solutions and debugging
tools in software for system-level debugging. The sld_virtual_jtag
megafunction can be instantiated directly in your HDL code to
provide one or more transparent communication channels to access
parts of your FPGA design using the JTAG interface of the device.
For more information about debugging tools, refer to “Referenced
Documents” on page 1–20.
If you intend to use any of these features, you may have to plan for the
features when developing your system board, Quartus II project, and
design. The following paragraphs describe various factors to consider
during your design planning stages.
The SignalTap II Embedded Logic Analyzer, Logic Analyzer Interface, InSystem Memory Content Editor, In-System Sources and Probes, and
Virtual JTAG Megafunction all require JTAG connections to perform insystem debugging. Plan your system and board with JTAG ports that are
available for debugging.
The JTAG debugging features also require a small amount of additional
logic resources to implement the JTAG hub logic. If you set up the
appropriate feature early in your design cycle, you can include these
device resources in your early resource estimations to ensure you do not
over-fill the device with logic.
The SignalTap II Embedded Logic Analyzer uses device memory to
capture data during system operation. Consider reserving device
memory to be used during debugging, to ensure that you have enough
memory resources to take advantage of this debugging technique.
To use incremental debugging with the SignalTap II Embedded Logic
Analyzer, the Full incremental compilation option must be turned on.
This option is on by default for projects created in the Quartus II software
version 6.1 or later, but is not turned on automatically for existing
projects. If incremental compilation is not enabled, you must recompile
the entire design when you want to add debugging functions, or when
you make certain changes to SignalTap II settings. Using incremental
compilation with the SignalTap II Embedded Logic Analyzer greatly
reduces the compilation time required for debugging.
SignalProbe and the Logic Analyzer Interface require I/O pins for
debugging. Consider reserving I/O pins for debugging so that you do not
have to change the design or board to accommodate debugging signals
later. Keep in mind that the Logic Analyzer Interface can multiplex
1–12
Altera Corporation
October 2007
Design Planning with the Quartus II Software
signals with design I/O pins if required. Ensure that your board supports
some kind of debugging mode, where debugging signals do not affect
system operation.
If you want to use the Virtual JTAG megafunction for custom debugging
applications, you must instantiate it and incorporate it as part of the
design process.
The In-System Sources and Probes feature also requires that you
instantiate a megafunction in your HDL code. In addition, you have the
option to instantiate the SignalTap II Embedded Logic Analyzer as a
megafunction so that you can connect it up to nodes in your design
manually and ensure that the tapped node names are not changed during
synthesis. You can add the debugging block as a separate design partition
for incremental compilation to minimize recompilation times.
To use the In-System Memory Content Editor for RAM or ROM blocks or
the LPM_CONSTANT megafunction, ensure that you turn on the option
Allow In-System Memory Content Editor to capture and update
content independently of the system clock when you create the memory
block in the MegaWizard Plug-In Manager.
Planning for an
Incremental
Compilation
Flow
If you want to take advantage of the compilation-time savings and
performance preservation of Quartus II incremental compilation, plan for
an incremental compilation flow from the beginning of your design cycle.
The following subsections describe the flat compilation flow, where the
design hierarchy is flattened without design partitions, and then the
incremental compilation flows that use design partitions in top-down,
bottom-up, or mixed design methodologies. Incremental compilation
flows offer several advantages but require more design planning to
ensure good quality of results. The last subsections discuss factors to
consider when planning an incremental compilation flow: planning
design partitions and creating a design floorplan.
f
For details about using the incremental compilation flows in the
Quartus II software, as well as important guidelines for creating design
partitions and a design floorplan, refer to the Quartus II Incremental
Compilation for Hierarchical and Team-Based Design chapter in volume 1 of
the Quartus II Handbook.
Flat Compilation Flow with No Design Partitions
In this compilation flow in the Quartus II software, the entire design is
compiled together in a “flat” netlist. This flow is used if you do not create
any design partitions. Your source code can have hierarchy, but the
design is flattened during compilation and all of the design source code
Altera Corporation
October 2007
1–13
Quartus II Handbook, Volume 1
is synthesized and fit in the target device whenever the design is
recompiled after any change in the design. By processing the entire
design, the software performs all available logic and placement
optimizations on the entire design to improve area and performance. You
can use debugging tools incrementally, such as the SignalTap II Logic
Analyzer, but you do not specify any design partitions to preserve design
hierarchy during compilation.
The flat compilation flow is easy to use; you do not have to plan any
design partitions. However, because the entire design is recompiled
whenever there are any changes to the design, compilation times can be
relatively long for large devices. In addition, you may find that the results
for one part of the design change when you change a different part of
your design.
1
The full incremental compilation option is turned on by default
in the Quartus II software (beginning with version 6.1), so the
project is ready for you to create design partitions for
incremental compilation. If you do not create any lower-level
design partitions, the entire design is considered as a single
design partition, and the software uses a flat compilation flow.
Incremental Compilation with Design Partitions
In an incremental compilation flow, the system architect splits a large
design into smaller partitions which can be designed separately. Team
members can work on partitions independently, which can simplify the
design process and reduce compilation time.
When hierarchical design partitions are well chosen and placed in the
device floorplan, you can speed up your design compilation time while
maintaining or even improving the quality of results.
You may want to use incremental compilation later in the design cycle
when you are not interested in improving the majority of the design any
further, and want to make changes to, or optimize, one specific block. In
this case, you may want to preserve the performance of modules that are
unmodified and reduce compilation time on subsequent iterations.
Incremental compilation may also be useful for both reducing
compilation time and achieving timing closure. For example, you may
want to specify which partitions should be preserved in subsequent
incremental compilations and then recompile the other partitions with
advanced optimizations turned on.
1–14
Altera Corporation
October 2007
Design Planning with the Quartus II Software
If a part of your design is not yet complete, you can create an empty
partition for the incomplete part of the design while compiling the
completed partitions. Then save the results for the complete partitions
while you work on the new part of the design.
Alternately, different designers or IP providers may be working on
different blocks of the design using a team-based methodology, and you
may want to combine these blocks in a bottom-up compilation flow.
In an incremental compilation flow, after you partition the design, the
software performs logic synthesis and technology mapping for each
partition individually. The Analysis and Synthesis stage reads the project
assignments to determine the partition boundaries. If any part of the
design changes, Analysis and Synthesis processes the changed partitions
and keeps the existing netlist for the unchanged partitions.
If you use a third-party synthesis tool, you should create separate VQM
or EDIF netlists for each design partition in your synthesis tool. You may
have to create separate projects within your synthesis tool so that the tool
synthesizes each partition separately and generates separate output
netlist files. Refer to your synthesis tool documentation for information
about support for Quartus II incremental compilation. The netlists are
then considered the “source files” for incremental compilation. After
completion of the Quartus II Analysis and Synthesis step, each partition
has one post-synthesis netlist.
The Quartus II Partition Merge step creates a complete netlist that
consists of post-synthesis netlists, post-fitting netlists, or both, or netlists
imported from lower-level projects, depending on the netlist type you
specify for each partition. The Fitter then processes the merged netlist,
preserving the placement or placement and routing of unchanged
partitions, and refitting only those partitions that have changed.
Top-Down Versus Bottom-Up Incremental Flows
The Quartus II incremental compilation feature supports both top-down
and bottom-up compilation flows that are suitable for different design
methodologies. You can also combine these flows in a mixed compilation
flow. The following subsections briefly describe each of these compilation
flows so that you can choose the flow that best meets your design needs.
Top-Down Incremental Compilation Flow
With top-down compilation, one designer or project lead compiles the
entire design in the software. Different designers or IP providers can
design and verify different parts of the design, and the project lead can
add design entities to the project as they are completed. You can also
Altera Corporation
October 2007
1–15
Quartus II Handbook, Volume 1
target optimizations on one part of the design while designating the rest
of the design as “empty.” Regardless of the source for all the design logic,
the project lead compiles and optimizes the top-level project as a whole.
Incremental compilation preserves the compilation results and
performance of unchanged partitions in your design, greatly reducing
design iteration time by focusing new compilations only on changed
design partitions. New compilation results are then merged with the
previous compilation results from unchanged design partitions.
Additionally, you can target optimization techniques, such as physical
synthesis, to specific design partitions while leaving other partitions
untouched. You can also use this flow with empty partitions if parts of
your design are incomplete or missing.
Bottom-Up and Team-Based Incremental Compilation Flow
Bottom-up design flows allow individual designers to complete the
optimization of their design in separate projects and then integrate each
lower-level project into one top-level project. Bottom-up methodologies
include team-based design flows in which design partitions are created
by team members in another location or by third-party IP providers.
Incremental compilation provides export and import features to enable
bottom-up design methodologies. Designers of lower-level blocks can
export the optimized netlist for their design, along with a set of
assignments, such as LogicLock™ regions. The system architect then
imports each design block as a design partition in a top-level project.
In bottom-up design flows, it is very important that the system architect
provide guidance to designers of lower-level blocks to ensure that each
partition uses the appropriate device resources. Because the designs are
developed independently, each lower-level designer has no information
about the overall design or how their partition connects with other
partitions. This lack of information can lead to problems during system
integration. The top-level project information, including pin locations,
physical constraints, and timing requirements, should be communicated
to the designers of lower-level partitions before they start their design.
The system architect can plan design partitions at the top level and use
Quartus II incremental compilation to communicate information to
lower-level designers through automatically-generated scripts. The
Quartus II option Generate bottom-up design partition scripts
automates the process of transferring top-level project information to
lower-level modules. The software provides a project manager interface
for managing project information in the top-level design.
1–16
Altera Corporation
October 2007
Design Planning with the Quartus II Software
The scripts can create Quartus II projects for all the lower-level design
blocks and pass all the relevant project assignments. Using these scripts
makes it easier for designers of lower-level modules to implement the
instructions from the project lead, and avoid conflicts between projects
when importing and incorporating the projects into the top-level design.
Using this methodology helps reduce the need to further optimize the
designs after integration and improves overall designer productivity and
team collaboration.
Mixed Incremental Compilation Flow
You can combine top-down and bottom-up compilation flows to take
advantage of top-down flows for part of your design, while importing
parts of the design that are developed independently.
The top-down flow is generally simpler to perform than its bottom-up
counterpart. For example, the need to export and import lower-level
designs is eliminated. A top-down approach also provides the design
software with information about the entire design, so it can perform
global placement optimizations when no part of the design is locked
down to a specific location.
In a bottom-up design methodology, you must perform very careful
resource balancing and time-budgeting, because the software does not
have any information about the other partitions in the top-level design
when it compiles individual lower-level partitions. Using bottom-up
compilation flows where required, in combination with top-down
compilation flows to reduce compilation time and preserve results for
other parts of the design, can be an effective way to improve your
productivity.
Planning Design Partitions
Partitioning a design for an FPGA requires planning to ensure optimal
results when the partitions are integrated, and ensure that each partition
is placed well relative to other partitions in the device. Following Altera’s
recommendations for creating design partitions improves the overall
quality of results. For example, registering partition I/O boundaries
keeps critical timing paths inside one partition that can be optimized
independently. When the design partitions are specified, you can use the
Incremental Compilation Advisor to ensure that partitions meet Altera’s
recommendations.
Determining a timing budget before designers develop their individual
blocks reduces the chance of timing problems during system integration.
If you optimize lower-level partitions separately, any unregistered paths
that cross between partitions are not optimized as an entire path. To
Altera Corporation
October 2007
1–17
Quartus II Handbook, Volume 1
ensure that the software correctly optimizes the input and output logic in
each partition, you may be required to perform some manual timing
budgeting. For each unregistered timing path that crosses between
partitions, you should make timing assignments on the corresponding
I/O path in each partition to constrain both ends of the path to the
budgeted timing delay. Assigning a timing budget for each part of the
connection ensures that the software optimizes paths appropriately so
they meet the top-level design requirements.
It is important to plan and balance resource utilization. When performing
incremental compilation, the software synthesizes each partition
separately, with no data about the resources used in other partitions.
Therefore, device resources can be overused in the individual partitions
during synthesis, and the design may not fit in the target device when the
partitions are merged.
In a bottom-up design flow in which designers optimize their lower-level
designs and export them to a top-level design, the software also places
and routes each partition separately. In some cases, partitions can use
conflicting resources when combined at the top level. Balancing resource
utilization between the design partitions avoids any problems with
conflicting resources when all the partitions are integrated.
Creating a Design Floorplan
To take full advantage of incremental compilation, you should create a
design floorplan to avoid conflicts between design partitions, and to
ensure that each partition is placed well relative to other partitions.
Creating location assignments for each partition ensures that no conflicts
occur for locations between different partitions. In addition, a design
floorplan helps to avoid a situation in which the Fitter is directed to place
or replace a portion of the design in an area of the device where most
resources have already been claimed. Without floorplan assignments,
this situation can lead to increased compilation time and reduced quality
of results.
You can use the Quartus II Timing Closure Floorplan or Chip Planner,
depending on your target device, to create a design floorplan using
LogicLock region assignments for each design partition. With a basic
design framework for the top-level design, these floorplan editors allow
you to view connections between regions, estimate physical timing
delays on the chip, and move regions around the device floorplan. When
you have compiled the full design, you can also view logic placement and
locate areas of routing congestion to improve the floorplan assignments.
1–18
Altera Corporation
October 2007
Design Planning with the Quartus II Software
Good partition and floorplan design helps lower-level designs meet toplevel design requirements when integrated with the rest of the design,
reducing the time spent integrating and verifying the timing of the toplevel design.
f
Early Timing
Estimation
For details about creating placement assignments in the design
floorplan, refer to the Analyzing and Optimizing the Design Floorplan
chapter in volume 2 of the Quartus II Handbook.
It is much less costly to find design issues early in the design cycle than
to find problems in the final timing closure stages. Once the first version
of the design source code is complete, you may want to perform a quick
compilation to create a kind of silicon virtual prototype, or SVP, that you
can use to perform timing analysis.
Regardless of your compilation flow, when the design source code is
complete you can use the Start Early Timing Estimate option to perform
a quick compilation and timing analysis of your design. The software
chooses a device automatically if required, places any LogicLock regions
used to create a floorplan, finds a quick initial placement for all the design
logic, and provides a useful estimate of the final design performance. If
you have entered timing constraints, timing analysis reports on these
constraints.
1
Early Timing Estimation is supported with both the TimeQuest
and Classic Timing Analyzers. Use the TimeQuest Timing
Analyzer with Synopsys Design Constraint (SDC) format
constraints to enable advanced timing analysis capabilities that
are not available in the Classic Timing Analyzer.
Designers of individual blocks in bottom-up design flows can use this
feature as they develop the design. Any issues the feature highlights in
the lower level design blocks can be communicated to the system
architect. Resolving these issues may require allocating additional device
resources to the individual block or changing its timing budget.
A top-level designer can also use early timing estimation to prototype the
entire design. Incomplete partitions can be marked as empty in an
incremental compilation flow, while the rest of the design is compiled to
get an early timing estimate and detect any problems with design
integration.
A system architect can use early timing estimation along with design
partition scripts (as described in “Bottom-Up and Team-Based
Incremental Compilation Flow” on page 1–16) to pass additional
constraints to lower-level designers, and provide more information about
Altera Corporation
October 2007
1–19
Quartus II Handbook, Volume 1
the other partitions in the design. This information can be especially
useful to optimize cross-partition paths. Running early timing
estimations helps designers find and resolve design problems during the
early design stages.
Conclusion
Modern FPGAs support large, complex designs with fast timing
performance. By planning several aspects of your design early in the
process, you can reduce unnecessary time spent handling issues in later
stages of the process. You can use various features of the Quartus II
software to quickly plan your design and achieve the best possible
results. Choosing the correct device and programming method, planning
I/O pin locations, estimating power consumption, selecting appropriate
third-party tools, planning for debugging options, performing good
design partitioning, and obtaining early timing estimates all improve
productivity, which reduces the design cost and improves the final
product’s time to market.
Referenced
Documents
This chapter references the following documents:
■
■
■
■
■
■
■
■
■
■
■
■
■
■
■
■
1–20
AN 386: Using the MAX II Parallel Flash Loader with the Quartus II
Software
Analyzing and Optimizing the Design Floorplan chapter in volume 2 of
the Quartus II Handbook
Cadence PCB Design Tools chapter in volume 2 of the Quartus II
Handbook
Configuration Handbook
Design Debugging Using the SignalTap II Embedded Logic Analyzer
chapter in volume 3 of the Quartus II Handbook
Design Debugging Using In-System Sources and Probes chapter in
volume 3 of the Quartus II Handbook
Formal Verification section in volume 3 of the Quartus II Handbook
I/O Management chapter in volume 2 of the Quartus II Handbook
In-System Debugging Using External Logic Analyzers chapter in
volume 3 of the Quartus II Handbook
In-System Updating of Memory and Constants chapter in volume 3 of
the Quartus II Handbook
Introduction to Quartus II Manual
Mentor Graphics PCB Design Tools Support chapter in volume 2 of the
Quartus II Handbook
PowerPlay Power Analysis chapter in volume 3 of the Quartus II
Handbook
Quartus II Incremental Compilation for Hierarchical and Team-Based
Design chapter in volume 1 of the Quartus II Handbook
Quick Design Debugging Using SignalProbe chapter in volume 3 of the
Quartus II Handbook
Simulation section in volume 3 of the Quartus II Handbook
Altera Corporation
October 2007
Design Planning with the Quartus II Software
■
■
Document
Revision History
sld_virtual_jtag Megafunction User Guide
Synthesis section in volume 1 of the Quartus II Handbook
Table 1–1 shows the revision history for this chapter.
Table 1–1. Document Revision History
Date and
Document
Version
October 2007
v7.2.0
Changes Made
Reorganized “Referenced Documents” on page 1–20.
Summary of Changes
Updated for the Quartus II
7.2 software release.
May 2007 v7.1.0 Updated for the Quartus II 7.1 software release, including:
Updated for the Quartus II
7.1 software release and
● Expanded Introduction, Device Migration Planning, and
expanded topic coverage.
Early Pin Planning and Analysis sections.
● Added new sections: Selecting Third-Party EDA Tool Flows
and Planning for Debug Options.
● Other minor changes and reorganization.
● Added Referenced Documents.
March 2007
v7.0.0
Updated Quartus II software 7.0 revision and date only. No
other changes made to chapter.
—
November 2006
v6.1.0
Initial release.
—
Altera Corporation
October 2007
1–21
Quartus II Handbook, Volume 1
1–22
Altera Corporation
October 2007
2. Quartus II Incremental
Compilation for Hierarchical
and Team-Based Design
QII51015-7.2.0
Introduction
For today’s high-density, high-performance FPGA designs, the ability to
iterate rapidly during the design and debugging stages is critical. The
Quartus® II software delivers advanced technology to create designs for
high-density FPGAs. Altera® introduced the FPGA industry’s first true
incremental design and compilation flow, which provides the following
benefits:
■
■
■
■
■
■
Preserves the results and performance for unchanged logic in your
design as you make changes elsewhere.
Reduces design iteration time by up to 70%, so you can perform more
design iterations per day and achieve timing closure efficiently.
Easy to use in the graphical user interface (GUI).
Includes Tcl scripting, command-line, and makefile support.
Facilitates modular hierarchical and team-based design flows using
top-down or bottom-up methodologies.
Supports the Arria™ GX devices, and Stratix® and Cyclone® series of
devices. Supports some incremental compilation flows for
HardCopy® II devices (for details, refer to “HardCopy Compilation
Flows” on page 2–82).
Quartus II incremental compilation is an optional compilation flow.
“Choosing a Quartus II Compilation Flow” on page 2–3 provides an
overview of the Quartus II design flow with and without incremental
compilation to help you decide if you should take advantage of this
feature for your project. The remainder of the chapter includes the
following sections:
■
■
■
■
■
■
■
■
■
Altera Corporation
October 2007
“Quick Start Guide – Summary of Steps for an Incremental
Compilation Flow” on page 2–11
“Design Partitions” on page 2–17
“Creating Design Partitions” on page 2–19
“Setting the Netlist Type for Design Partitions” on page 2–22
“Creating a Design Floorplan With LogicLock Location
Assignments” on page 2–29
“Exporting and Importing Partitions for Bottom-Up Design Flows”
on page 2–32
“Guidelines for Creating Good Design Partitions and LogicLock
Regions” on page 2–46
“Recommended Design Flows and Compilation Application
Examples” on page 2–62
“Incremental Compilation Restrictions” on page 2–76
2–1
Preliminary
Quartus II Handbook, Volume 1
■
■
“Scripting Support” on page 2–99
“Conclusion” on page 2–109
To take advantage of incremental compilation, you organize your design
into logical partitions and physical regions for synthesis and fitting (or
placement and routing). Incremental compilation preserves the
compilation results and performance of unchanged partitions in your
design, dramatically reducing design iteration time by focusing new
compilations only on changed design partitions. New compilation results
are then merged with the previous compilation results from unchanged
design partitions. Additionally, you can target optimization techniques,
such as physical synthesis, to specific design partitions while leaving
other partitions untouched.
Incremental compilation supports two design methodologies: top-down,
in which one designer manages a single project for the entire design, and
bottom-up, in which each design block can be developed independently.
Bottom-up methodologies include team-based design flows in which
design partitions are created by team members in another location or by
third-party intellectual property (IP) providers. For bottom-up flows, you
can generate scripts from the top-level design that pass constraints to
lower-level design blocks compiled in separate Quartus II projects.
This chapter contains information to satisfy the following goals:
■
■
■
■
2–2
Preliminary
Provide an overview of the Quartus II compilation flow and help
you decide whether to use incremental compilation
Describe how to use the Quartus II incremental compilation feature
with a quick start guide and then more detailed information
Provide you with the level of understanding required to make good
design decisions to achieve timing closure while speeding up design
iterations
Present several recommended design flows for incremental
compilation in the form of examples, along with the rationale behind
them and the steps required to carry out the tasks:
●
“Design Flow 1—Changing a Source File for One of Multiple
Partitions in a Top-Down Compilation Flow” on page 2–62
●
“Design Flow 2—Optimizing the Placement for One of Multiple
Partitions in a Top-Down Compilation Flow” on page 2–63
●
“Design Flow 3—Preserving One Critical Partition in a
Multiple-Partition Design in a Top-Down Compilation Flow” on
page 2–64
●
“Design Flow 4—Placing All but One Critical Partition in a
Multiple-Partition Design in a Top-Down Compilation Flow” on
page 2–65
●
“Design Flow 5—Implementing a Team-Based Bottom-Up
Design Flow” on page 2–67
Altera Corporation
October 2007
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
●
●
Choosing a
Quartus II
Compilation
Flow
“Design Flow 6—Performing Design Iteration in a Bottom-Up
Design Flow” on page 2–71
“Design Flow 7—Creating Hard-Wired Macros for IP Reuse” on
page 2–73
Quartus II incremental compilation enhances the standard Quartus II
design flow by allowing you to reuse satisfactory results from previous
compilations and save compilation time. This section outlines the flat
compilation flow with no design partitions and the incremental flow, and
explains the differences. The section explains when a flat compilation
flow is satisfactory, and highlights some of the reasons you might want
to create design partitions and use the incremental flow.
The full incremental compilation option is turned on by default in the
Quartus II software, so the project is ready for you to create design
partitions for incremental compilation. If you do not create any design
partitions, the software uses a flat compilation flow.
Flat Compilation Flow with No Design Partitions
The standard Quartus II compilation flow consists of the following
essential modules:
■
■
■
■
Altera Corporation
October 2007
Analysis and Synthesis—performs logic synthesis to minimize the
design logic and performs technology mapping to implement the
design logic using device resources such as logic elements. This stage
also generates the project database that integrates the design files
(including netlists from third-party synthesis tools). When you are
using EDIF or VQM netlists created by third-party synthesis tools,
the Analysis and Synthesis stage performs logic synthesis and
technology mapping only for black boxes and Altera megafunctions.
Fitter—places and routes the logic of a design into a device.
Assembler—converts the Fitter’s device, logic, and pin assignments
into programming files for the device.
Timing Analyzer—analyzes and validates the timing performance
of all the logic in a design.
2–3
Preliminary
Quartus II Handbook, Volume 1
Figure 2–1 shows a block diagram of the Quartus II design flow with no
design partitions.
Figure 2–1. Quartus II Design Flow with No Design Partitions
Verilog
HDL
(.v)
VHDL
(.vhd)
AHDL
(.tdf)
Block
Design
File
(.bdf)
EDIF
Netlist
(.edf)
Analysis & Synthesis (1)
VQM
Netlist
(.vqm)
Settings &
Assignments
Post-Synthesis
Netlist
Settings &
Assignments
Fitter
Place-and-Route
Post-Fit
Netlist
Assembler
Timing Analyzer
Requirements
Satisfied?
No
Make Design & Assignment
Modifications
Yes
Program/Configure Device
Note to Figure 2–1:
(1)
When you are using EDIF or VQM netlists created by third-party EDA synthesis
tools, the Analysis and Synthesis stage of the compilation is performed to create
the design database, but logic synthesis and technology mapping are performed
only for black boxes and Altera megafunctions.
In any Quartus II compilation flow, you can use smart compilation to
allow the compiler to determine which compiler modules are required
based on the changes made to the design since the last smart compilation,
and then skip any modules that are not required. For example, when
smart compilation is selected, the compiler skips the Analysis & Synthesis
module if the design source files were unchanged. Smart compilation
skips only entire compiler stages. It cannot make incremental changes
2–4
Preliminary
Altera Corporation
October 2007
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
within a given stage of the compilation flow. To turn on smart
compilation, on the Assignments menu, click Settings. In the Category
list, select Compilation Process Settings and click Use Smart
Compilation.
In the default flat compilation flow, all of the source code is processed
with the Analysis & Synthesis module, and all the logic is placed by the
Fitter module whenever the design is recompiled after a change in any
part of the design. One reason for this behavior is to obtain optimal
quality of results. By processing the entire design, the compiler can
perform global optimizations to improve area and performance.
You can use a flat compilation flow for small designs, such as designs in
CLPD devices or low-density FPGA devices, when the timing
requirements are met easily with a push-button compilation. A flat
design is satisfactory when compilation time and preserving results for
timing closure are not concerns.
Incremental Compilation Flow with Design Partitions
There are many situations in which an incremental compilation flow is
more desirable than the simple flat compilation flow. Using an
incremental flow allows you to preserve the results and performance for
unchanged logic in your design as you make changes elsewhere. It
reduces design iteration time by up to 70%, allowing you to perform more
design iterations per day and achieve timing closure more efficiently.
Incremental compilation is recommended for large designs and high
device densities, as well as designs that require high performance relative
to the speed of the device architecture. The feature also facilitates
team-based design environments, allowing designers to create and
optimize design blocks independently.
In conventional FPGA design, as described in the previous section, a
hierarchical design is flattened into a single netlist before logic synthesis
and fitting, and the entire design is recompiled every time the design
changes. To use the Quartus II incremental compilation flow, you start by
splitting your design along any of its hierarchical boundaries into blocks
called design partitions. Refer to “Design Partitions” on page 2–17 for
more details. The Quartus II software synthesizes each individual
hierarchical design partition separately, then merges the partitions into a
complete netlist for subsequent stages of the compilation flow. When
recompiling the design, you can choose to use source code, post-synthesis
results, or post-fitting results for each partition. If you want to preserve
the Fitter results, you can choose to keep just the Fitter netlist, keep the
placement results, or keep both the placement and routing results.
Altera Corporation
October 2007
2–5
Preliminary
Quartus II Handbook, Volume 1
You may want to use incremental compilation later in the design cycle
when you are not interested in improving the majority of the design any
further, and want to make changes to or optimize one specific block. In
this case, you may want to preserve the performance of modules that are
unmodified and to reduce compilation time on subsequent iterations.
There are also situations in which incremental compilation is useful both
for reducing compilation time and for achieving timing closure. For
example, you may want to specify which partitions should be preserved
in subsequent incremental compilations, and then recompile the other
partitions with advanced optimizations turned on.
You might also have part of your design that is not yet complete, for
which you can create an empty partition while compiling the completed
partitions, and then save the results for the complete partitions while you
work on the new part of the design. Alternatively, different designers or
IP providers may be working on different blocks of the design using a
team-based methodology, and you might want to combine them in a
bottom-up compilation flow. In these cases, the Fitter can perform
placement and routing on each partition independently.
If you want to use the incremental compilation feature at any point in
your design flow, it is beneficial to start planning for incremental
compilation from the start of your design development. It is easier to
accommodate the guidelines for partitioning and creating a floorplan if
you start planning at the beginning of your design cycle. Refer to
“Guidelines for Creating Good Design Partitions and LogicLock
Regions” on page 2–46 for more information. For more detailed examples
that describe recommended design flows to take advantage of the
incremental compilation features, refer to “Recommended Design Flows
and Compilation Application Examples” on page 2–62.
2–6
Preliminary
Altera Corporation
October 2007
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Figure 2–2 shows a block diagram of the Quartus II design flow using
incremental compilation with design partitions.
Figure 2–2. Quartus II Design Flow Using Incremental Compilation
Verilog
HDL
(.v)
VHDL
(.vhd)
AHDL
(.tdf)
Block
Design File
(.bdf)
EDIF
Netlist
(.edf)
VQM
Netlist
(.vqm)
Partition Top
Design Partition
Assignments
Partition 1
Partition 2
Analysis & Synthesis (1)
Synthesize Changed Partitions,
Preserve Others
Settings &
Assignments
One Post-Synthesis
Netlist per Partition
Partition Merge
Create Complete Netlist Using Appropriate Source Netlists for Each
Partition (Post-Fit, Post-Synthesis, or Imported Netlist)
One Post-Fit
Netlist per
Partition
Single Netlist for
Complete Design
Fitter
Place-and-Route Changed Partitions,
Preserve Others
Create Individual Netlists and
Complete Netlists
Floorplan
Location
Assignments
Settings &
Assignments
Single Post-Fit
Netlist for
Complete Design
Assembler
Timing Analyzer
Requirements
Satisfied?
No
Make Design &
Assignment Modifications
Yes
Program/Configure Device
Note to Figure 2–2:
(1)
Altera Corporation
October 2007
When you are using EDIF or VQM netlists created by third-party EDA synthesis
tools, the Analysis and Synthesis stage of the compilation is performed to create
the design database, but logic synthesis and technology mapping are performed
only for black boxes and Altera megafunctions.
2–7
Preliminary
Quartus II Handbook, Volume 1
In this flow, Analysis and Synthesis reads the project assignments to
determine the partition boundaries, and performs logic synthesis and
technology mapping for each partition individually.
The diagram in Figure 2–2 shows a top-level partition and two
lower-level partitions. If any part of the design changes, Analysis and
Synthesis processes the changed partitions and keeps the existing netlists
for the unchanged partitions. After completion of Analysis and Synthesis,
there is one post-synthesis netlist for each partition.
The partition merge step creates a single, complete netlist that consists of
post-synthesis netlists, post-fit netlists, and netlists imported from
lower-level projects, depending on the netlist type you specify for each
partition.
The Fitter then processes the merged netlist, preserving the placement or
placement and routing of unchanged partitions, refitting only those
partitions that have changed. The Fitter generates the complete netlist for
use in further stages of the compilation flow, including timing analysis
and programming file generation. It also generates individual netlists for
each partition so that the partition merge step can use the post-fit netlist
to preserve the placement and routing of a partition if you specify to do
so in future compilations.
If the design does not meet its requirements (functionality, timing, or
area), you can make changes to the design and recompile. The Quartus II
software does not resynthesize or refit unchanged partitions that have a
netlist type assignment that specifies the use of a post-synthesis or post-fit
netlist, respectively.
For more information about using the incremental compilation feature,
refer to the “Quick Start Guide – Summary of Steps for an Incremental
Compilation Flow” on page 2–11.
See Table 2–1 for a summary of the impact of incremental compilation on
your compilation results.
Table 2–1. Summary of the Impact of Full Incremental Compilation (Part 1 of 2)
Characteristic
Impact of Full Incremental Compilation
Compilation Time Typically saves 50-70% of compilation time when post-fit netlists are preserved; savings in
Savings
both Quartus II integrated synthesis and the Fitter.
Performance
Preservation
Excellent when critical paths are contained within a partition, because you can preserve
post-fitting information for unchanged partitions.
Node Name
Preservation
Preserves post-fitting node names for unchanged partitions.
2–8
Preliminary
Altera Corporation
October 2007
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Table 2–1. Summary of the Impact of Full Incremental Compilation (Part 2 of 2)
Characteristic
Impact of Full Incremental Compilation
Area Changes
Area might increase because cross-boundary optimizations are no longer possible, and
placement and register packing are restricted.
fM A X Changes
fM A X might be reduced because cross-boundary optimizations are no longer possible. If the
design is partitioned and the floorplan location assignments are created appropriately, no
negative impact on fM A X .
Floorplan
Creation
Required for critical partitions to ensure the best quality of results when making design
changes. Required in bottom-up flows to avoid placement conflicts.
When Design is
Resynthesized
When you set the Netlist Type to use the source file. It is also resynthesized automatically
any time you make changes to the source code, unless you specify a Post-Fit (Strict) netlist,
or it is an imported partition.
When Design is
Refit
When you set the Netlist Type to use the source file, a post-synthesis netlist, or a post-fit
netlist with a Fitter preservation level of Netlist Only. It is also refit automatically any time you
make changes to the source code, unless you specify a Post-Fit (Strict) netlist, or it is an
imported partition.
Top-Down versus Bottom-Up Compilation Flows
The Quartus II incremental compilation feature supports both top-down
and bottom-up compilation flows. With top-down compilation, one
designer or project lead compiles the entire design in the software.
Different designers or IP providers can design and verify different parts
of the design, and the project lead can add design entities to the project as
they are completed. You can use a top-down flow to optimize one block
or IP core in which timing is critical before adding the rest of the design.
However, one person (generally the project lead or system architect)
compiles the top-level project as a whole. Completed parts of the design
can have fitting results and performance fixed as other parts of the design
are changing.
Bottom-up design flows allow individual designers or IP providers to
complete the optimization of their design in separate projects and then
integrate each lower-level project into one top-level project. Incremental
compilation provides export and import features to enable this design
methodology. Designers of lower-level blocks can export the optimized
placed and routed netlist for their design, along with a set of assignments
such as LogicLock™ regions. The project lead then imports each design
block as a design partition in a top-level project.
Altera Corporation
October 2007
2–9
Preliminary
Quartus II Handbook, Volume 1
The following two benefits are associated with a bottom-up design flow:
■
■
It facilitates team-based development
It permits the reuse of compilation results from another project, with
the ultimate goals of performance preservation and compilation time
reduction.
A bottom-up design flow also has the following potential drawbacks that
require careful planning:
■
■
It may be difficult to achieve timing closure for the full design
because you compile the lower-level blocks independently without
any information about each other. This problem may be avoided by
careful timing budgeting and special design rules, such as always
registering the ports at the module boundaries.
For the same reason, resource budgeting and allocation may be
required to avoid resource conflicts and overuse. Floorplan creation
is typically very important in a bottom-up flow.
In a bottom-up design flow, the top-level project lead can do much of the
design planning, and then pass constraints on to the designers of
lower-level blocks. For more information about the export and import
operations, and how to use design partition scripts to help with design
planning, refer to “Exporting and Importing Partitions for Bottom-Up
Design Flows” on page 2–32.
It is important to understand that with the full incremental compilation
flow, users who traditionally relied on a bottom-up approach for the sole
reason of performance preservation can now employ a top-down
approach to achieve the same goal. This ability is important for two
reasons. First, a top-down flow is generally simpler to perform than its
bottom-up counterpart. For example, the need to export and import
lower-level designs is eliminated. Second, a top-down approach provides
the design software with information about the entire design so it can
perform global placement and routing optimizations.
You can also mix top-down and bottom-up flows within a single project.
If the top-level design includes one or more design blocks that are created
by different designers or IP providers, you can import those blocks (using
a bottom-up methodology) into a project that also includes partitions for
a top-down incremental methodology.
2–10
Preliminary
Altera Corporation
October 2007
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Quick Start
Guide –
Summary of
Steps for an
Incremental
Compilation
Flow
This section provides a summary of the steps required to perform an
incremental compilation flow. Detailed descriptions for some of these
steps are included in later sections of this chapter. For more examples of
design flows that take advantage of the incremental compilation features,
refer to “Recommended Design Flows and Compilation Application
Examples” on page 2–62.
Top-Down Incremental Compilation Flow
The flow chart in Figure 2–3 illustrates the complete incremental
compilation flow using a top-down methodology (all partitions are
contained in one top-level project). The following subsections describe
the steps in the flow. First, prepare the design for incremental
compilation and perform a full compilation. Then proceed to verify or
debug your design and make design changes as required. When you
perform additional design iterations and recompile your design, you can
choose which netlists to reuse and perform incremental compilations.
Figure 2–3. Summary of Top-Down Incremental Compilation Flow
Perform Analysis & Elaboration
Create Design Partitions
Create Floorplan Location
Assignments using LogicLock Regions
Perform Complete Compilation
(All Partitions are Compiled)
Make Changes to Design
Set Netlist Type for Each Partition
Repeat as Needed
During Design, Verification,
& Debugging Stages
Perform Incremental Compilation
(Partitions are Compiled if Required)
Altera Corporation
October 2007
2–11
Preliminary
Quartus II Handbook, Volume 1
Preparing a Design for Top-Down Incremental Compilation
To set up your design for incremental compilation, use the following
general steps:
1.
Elaborate the design. On the Processing menu, point to Start and
click Start Analysis & Elaboration, or run any compilation flow
that includes this step. Elaboration is part of the synthesis process
that identifies your design’s hierarchy.
2.
Create partitions in your design by applying the Set as Design
Partition assignment to the appropriate instances.
Refer to “Design Partitions” on page 2–17 for an explanation of
design partitions and what part of your design can be specified as a
design partition. Refer to “Creating Design Partitions” on page 2–19
for details about assigning design partitions. For guidelines, refer to
“Guidelines for Creating Good Design Partitions and LogicLock
Regions” on page 2–46. The most important guidelines include using
registers at the I/O boundaries of each partition, and minimizing the
number of signals that cross between partitions.
3.
Use LogicLock regions to make location assignments for each
partition to create a design floorplan. Depending on your design
flow and requirements, each partition may be required to be
assigned to a physical region on the device. Refer to the section
“Creating a Design Floorplan With LogicLock Location
Assignments” on page 2–29 for details about these assignments. For
guidelines, refer to “Guidelines for Creating Good Design Partitions
and LogicLock Regions” on page 2–46.
4.
On the Processing menu, click Start Compilation to compile the
design. The first compilation after making partition and LogicLock
assignments is a complete compilation that prepares the design for
subsequent incremental compilations.
Compiling a Design Using Incremental Compilation
After compiling the design once and then making changes, you can take
advantage of incremental compilation to recompile the changed parts of
the design while preserving the results for the unchanged partitions, thus
saving time on subsequent compilations. To do this, perform the
following general steps:
1.
2–12
Preliminary
Choose which compilation results you would like to reuse for each
partition. To preserve previous placement results for a partition, set
the Netlist Type assignment for that partition to Post-Fit. To
preserve routing information as well, set the Fitter Preservation
Altera Corporation
October 2007
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Level to Placement and Routing. To save only the synthesis results,
set the Netlist Type assignment for that partition to Post-Synthesis.
Partitions with source code changes are recompiled automatically.
You can also direct the software to recompile from the source code
by choosing the Source File netlist type. If you do not want to
compile a specific partition at all, set its Netlist Type to Empty.
For details about setting these partition properties, refer to “Setting
the Netlist Type for Design Partitions” on page 2–22.
2.
Compile the design. When you start a compilation for a partitioned
design with incremental compilation turned on, the Quartus II
software uses the incremental compilation flow, preserving the
results you specified in Step 1.
Bottom-Up Incremental Compilation
The flow chart in Figure 2–4 illustrates the incremental compilation flow
using a bottom-up methodology (lower-level partitions are compiled
separately before being imported into the top-level project). The
following subsections describe the steps involved in the flow.
First, prepare the top-level design for incremental compilation. Then
design, optimize, verify, and debug the lower-level projects. Export the
lower-level projects, and import them into the top-level design. Finally,
compile the entire top-level design.
Figure 2–4. Summary of Bottom-Up Incremental Compilation Flow
Prepare Top-Level Project for
Bottom-Up Incremental Compilation
Create Lower-Level Project(s)
Design, Compile, & Optimize
Lower-Level Project(s)
Export Lower-Level Project(s)
Import Lower-Level Project(s)
into Top-Level Project
Repeat as Needed
During Design, Verification,
& Debugging Stages
Perform Incremental Compilation
in Top-Level Project
Altera Corporation
October 2007
2–13
Preliminary
Quartus II Handbook, Volume 1
Preparing a Design for Bottom-Up Incremental Compilation
The design’s project lead or top-level designer should perform the
following steps to prepare the design for a successful bottom-up design
methodology:
1.
2–14
Preliminary
Create the top-level Quartus II project that will eventually
incorporate the entire design, and apply project-wide settings and
global assignments.
a.
Define source code for a “skeleton” of the entire design that
defines the hierarchy and the port interfaces for the lower-level
designs. The top-level design file must include the top-level
entity that instantiates the lower-level blocks you plan to
compile in separate Quartus II projects. Include wrapper HDL
files for each of these blocks that define at least the port
interface. Analysis and Elaboration requires this wrapper file
(also known as a “stub” or “black box” file) to connect all the
separate design partitions at the top level. For example, in
Verilog HDL you should include a module declaration, and in
VHDL you should include an entity and architecture
declaration. The wrapper file does not have to contain any logic
for the design partition.
b.
Create all global assignments, including the device assignment,
pin location assignments, and timing assignments, so that the
final design meets its requirements. Lower-level project
designers can add their own constraints for their partitions as
needed, and later provide them to the top-level designer, but
the basic constraints can be passed down from the top level to
avoid any conflicts and ensure that lower-level projects use the
correct assignments.
2.
Make design partition assignments for each lower-level design, and
set the Netlist Type to Empty for each partition that will be
imported. Refer to “Creating Design Partitions” on page 2–19 and
“Setting the Netlist Type for Design Partitions” on page 2–22 for
details. For guidelines, refer to “Guidelines for Creating Good
Design Partitions and LogicLock Regions” on page 2–46.
3.
Create LogicLock regions for each of the lower-level partitions to
create a design floorplan. Refer to “Creating a Design Floorplan
With LogicLock Location Assignments” on page 2–29. For
guidelines, refer to “Guidelines for Creating Good Design Partitions
and LogicLock Regions” on page 2–46.
Altera Corporation
October 2007
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
4.
Optional: Perform a full compilation of the skeleton design and
create scripts to pass assignments to lower-level designers. After
compilation, on the Project menu, click Generate Bottom-Up
Design Partition Scripts. Refer to “Generating Bottom-Up Design
Partition Scripts for Project Management” on page 2–40 for details.
Provide each lower-level designer with the generated Tcl file to
create their project with the appropriate constraints. If you use
makefiles in your design environment, provide the makefile for
each partition.
Creating and Compiling Lower-Level Projects
The designer of each lower-level design should create and compile their
design in a separate Quartus II project.
If you are creating the project manually, create a new Quartus II project
for the subdesign with all the required settings. Create with LogicLock
region assignments and global assignments (including clock settings) as
specified by the project lead, as well as Virtual Pin assignments for ports
which represent connections to core logic instead of external device pins
in the top-level module.
If you have a bottom-up design partition script from the top-level
designer, source the Tcl script to create the Quartus II project with all the
required settings and assignments from the top-level design.
If you are using makefiles, use the make command and the makefile
provided by the project lead to create a Quartus II project with all the
required settings and assignments, and compile the project. Specify the
dependencies in the makefile to indicate which source file should be
associated with which partition.
Compile and optimize each lower-level design as a separate Quartus II
project.
Exporting Lower-Level Projects
When you have achieved the design requirements for the lower-level
design, export each design as a partition for the top-level design.
If you are not using makefiles, on the Project menu, use the Export
Design Partition dialog box to export each lower-level design. Refer to
“Exporting a Lower-Level Partition to be Used in a Top-Level Project” on
page 2–33. If you want to export only a portion of the design in the
lower-level project, refer to “Exporting a Lower-Level Block within a
Project” on page 2–35 for instructions. Each lower-level designer must
provide the Quartus II Exported Partition file (.qxp) to the project lead.
Altera Corporation
October 2007
2–15
Preliminary
Quartus II Handbook, Volume 1
If your design team is using makefiles, the project lead can use the make
command with the master_makefile to export the lower-level partitions
and create Quartus II Exported Partition files, and then import them into
the top-level design.
Importing Lower-Level Projects into the Top-Level Project
The project lead then imports the files sent in by the designers of each
lower-level subdesign partition.
If you are not using makefiles, on the Project menu, click Import Design
Partition and specify the partition in the top-level project that is
represented by the subdesign Quartus II Exported Partition (QXP) file.
Refer to “Importing a Lower-Level Partition Into the Top-Level Project”
on page 2–36 for details. Repeat the import process for each partition in
the design.
If you are using makefiles, the master_makefile command imports each
partition into the top-level design. Be sure to specify which source files
should be associated with which partition so that the software can rebuild
the project if source files change.
For details about which assignments are imported, and how to avoid
conflicts, refer to “Importing Assignments and Advanced Import
Settings” on page 2–37.
Performing an Incremental Compilation in the Top-Level Project
After you have imported the design partitions that make up the top-level
project, you can perform a full compilation. The software compiles
imported partitions in the same way as partitions defined in the top-level
project. The software recompiles an imported partition only if it has been
imported since the last compilation.
2–16
Preliminary
Altera Corporation
October 2007
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Design
Partitions
It is a common design practice to create modular or hierarchical designs
in which you develop each design entity separately and then instantiate
them in a higher-level entity, forming a complete design. The software
does not consider each design entity automatically to be a design
partition for incremental compilation; rather, you must designate one or
more design hierarchies below the top-level project to be a design
partition. Creating partitions prevents the compiler from performing
optimizations across partition boundaries, as discussed in “Guidelines
for Creating Good Design Partitions and LogicLock Regions” on
page 2–46 and illustrated in Figure 2–10. However, this allows for
separate synthesis and placement for each partition, making incremental
compilation possible.
Partitions must have the same boundaries as hierarchical blocks in the
design because a partition cannot be a portion of the logic within a
hierarchical entity. When you declare a partition, every hierarchical entity
within that partition becomes part of the same partition. You can create
new partitions for hierarchical entities within an existing partition, in
which case the entities within the new partition are no longer included in
the higher-level partition, as described in the following example.
In Figure 2–5, hierarchical entities B and F form partitions in the complete
design, which is made up of entities A, B, C, D, E, and F. The shaded
boxes in Representation A indicate design partitions in a “tree”
representation of the hierarchy. In Representation B, the lower-level
entities are represented inside the higher-level entities, and the partitions
are illustrated with different colored shading. The top-level partition,
called Top, automatically contains the top-level entity in the design, and
contains any logic not defined as part of another partition. The design file
for the top level may be just a wrapper for the hierarchical entities below
it, or it may contain its own logic. In this example, the partition for
top-level entity A also includes the logic in one of its lower-level entities,
C. Because entity F is contained in its own partition, it is not treated as
part of the top-level partition. Another separate partition, B, contains the
logic in entities B, D, and E.
Altera Corporation
October 2007
2–17
Preliminary
Quartus II Handbook, Volume 1
Figure 2–5. Partitions in a Hierarchical Design
Representation A
Partition Top
A
B
C
D
E
F
Partition B
Partition F
Representation B
A
B
C
D
E
FE
Design Partition Assignments Compared to Physical Placement
Assignments
Design partitions for incremental compilation are logical partitions,
different from physical placement assignments in the device floorplan. A
logical design partition does not refer to a physical area of the device and
does not directly control the placement of instances. A logical design
partition sets up a virtual boundary between design hierarchies so each is
compiled separately, preventing logical optimizations from occurring
between them. The software creates a separate post-synthesis and
post-fitting netlist for each partition, which allows the software to reuse
the synthesis results or reuse the fitting results (including placement and
routing information) in subsequent compilations.
If you preserve the compilation results using a Post-Fit netlist, it is not
necessary for you to back-annotate or make any location assignments for
specific logic nodes. You should not use the incremental compilation and
assignment back-annotation features in the same Quartus II project. The
2–18
Preliminary
Altera Corporation
October 2007
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
incremental compilation feature does not use placement “assignments”
to preserve placement results; it simply reuses the netlist database that
includes the placement information.
You can assign design partitions to physical regions in the device
floorplan using LogicLock assignments. Altera recommends using
LogicLock regions to improve the quality of results and avoid placement
conflicts when performing incremental compilation. LogicLock regions
have a size and location on the device floorplan, and you can assign a
partition to a physical region to place it in a specific area of the device.
Creating floorplan location assignments for design partitions using
LogicLock regions is discussed in “Creating a Design Floorplan With
LogicLock Location Assignments” on page 2–29.
Creating Design
Partitions
To use incremental compilation, you must first split your design into
partitions, as described in “Design Partitions” on page 2–17 and “Quick
Start Guide – Summary of Steps for an Incremental Compilation Flow” on
page 2–11. You can make partition assignments to HDL or schematic
design instances, or to VQM or EDIF netlist instances (from third-party
synthesis tools). To take advantage of incremental compilation when
source files change, the top-level design entity of each partition should
have a unique design file. If you define two different entities of separate
partitions but they are in the same design file, you cannot maintain
incremental compilation because the software would have to recompile
both partitions if you changed either entity in the design file.
When you are using a third-party synthesis tool, create a separate netlist
file for each partition to allow each partition to be treated incrementally.
To create separate netlists for each partition, you may have to create a
top-level HDL wrapper file that instantiates the lower-level netlist files
and then create separate projects in your synthesis tool for each of the
lower-level partitions. In this case, the lower-level blocks should be
treated as a black box in the top-level design. Some synthesis tools allow
you to create separate netlist files for different design blocks within a
single project.
f
For information about using incremental compilation with third-party
synthesis tools, refer to the appropriate chapter in the Synthesis section in
volume 1 of the Quartus II Handbook.
For suggestions on determining which parts of your design should be set
as design partitions, refer to “Guidelines for Creating Good Design
Partitions and LogicLock Regions” on page 2–46.
Altera Corporation
October 2007
2–19
Preliminary
Quartus II Handbook, Volume 1
The full incremental compilation option is turned on by default (for new
projects created in the Quartus II software version 6.1 and later), so the
project is ready for you to create design partitions.
If full incremental compilation is not turned on when you specify your
first partition, a dialog box appears that asks whether you want to enable
incremental compilation. Selecting Full incremental compilation in this
dialog box turns on incremental compilation on the Incremental
Compilation page under Compilation Process Settings in the Settings
dialog box.
Selecting Off on the Incremental Compilation page of the Settings
dialog box does not remove any partition assignments. Partition
assignments have no effect on the design if incremental compilation is
turned off.
You can create design partitions in the Quartus II GUI with the Design
Partitions Window or the Project Navigator.
On the Assignments menu, click Design Partitions Window (Figure 2–6)
to create your partitions in one of the following ways:
■
■
Create new partitions for one or more instances by dragging and
dropping them from the Hierarchy tab of the Project Navigator, into
the Design Partitions window. Using this method, you can create
multiple partitions at once.
Create new partitions by double-clicking the <<new>> cell in the
Partition Name column. In the Create New Partitions dialog box,
select the design instance and click OK.
To delete partitions in the Design Partitions window, right-click a
partition and click Delete, or select the partition and press the Delete key.
Figure 2–6. Design Partitions Window
2–20
Preliminary
Altera Corporation
October 2007
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Alternatively, you can use the list of instances under the Hierarchy tab in
the Project Navigator to create and delete design partitions. Right-click
on an instance in the Project Navigator and click Set as Design Partition.
1
A design partition icon appears next to each instance that is set
as a partition (Figure 2–7).
To remove an existing partition assignment, right-click the instance in the
Project Navigator and click Set as Design Partition again. (This process
turns off the option.)
Figure 2–7. Project Navigator Showing Design Partitions
Partition Name
When you create a partition, the Quartus II software automatically
generates a name based on the instance name and hierarchy path. You
can change the name by double-clicking on the partition name in the
Design Partitions window, or right-click the partition and click Rename.
Alternatively, you can right-click the partition in the Design Partitions
window and click Properties to open the Design Partition Properties
dialog box. On the General tab, enter the new name in the Name field.
By renaming your partitions you can avoid referring to them by their
hierarchy path, which can sometimes be long. This is especially important
when using command-line commands or assignments. Partition names
can be from 1 to 1024 characters in length and must be unique. The name
can only contain alphanumeric characters and the pipe ( | ), colon ( : ),
and underscore ( _ ) characters.
Altera Corporation
October 2007
2–21
Preliminary
Quartus II Handbook, Volume 1
Setting the
Netlist Type for
Design
Partitions
The Netlist Type property controls the incremental compilation process,
as described in “Compiling a Design Using Incremental Compilation” on
page 2–12. The Netlist Type is a property of each design partition that
allows you to specify the type of netlist or source file that the compiler
should use as the input for each partition. This property determines
which netlist is used by the Partition Merge stage in the next compilation.
To view and modify the Netlist Type, on the Assignments menu, click
Design Partitions Window. Double-click the Netlist Type for an entry.
Alternatively, right-click on an entry, click Design Partition Properties,
then modify the Netlist Type on the Compilation tab.
Table 2–2 describes the different settings for the Netlist Type property,
explains the behavior of the Quartus II software for each setting, and
gives guidance on when to use a certain setting.
Table 2–2. Netlist Type Settings (Part 1 of 3)
Partition
Netlist Type
Source File
Quartus II Behavior for Partition During Compilation
Always compiles the partition using the associated design source file(s).
You can use this netlist type to recompile a partition from the source code using new synthesis
or Fitter settings.
If a partition has an associated imported netlist, compiling it with netlist type set to Source File
removes the imported netlist.
Post-Synthesis Preserves post-synthesis results for the partition and uses the post-synthesis netlist as long as
the following conditions are true:
● A post-synthesis netlist is available from a previous synthesis
● No change has been made to the associated source files since the previous synthesis
Compiles the partition from the source files if there are source changes or if a post-synthesis
netlist is not available. Changes to the assignments do not cause recompilation.
You can use this netlist type to preserve the synthesis results unless source files change, but
refit the partition using any new Fitter settings.
If a partition has an associated imported netlist, this setting is not available.
2–22
Preliminary
Altera Corporation
October 2007
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Table 2–2. Netlist Type Settings (Part 2 of 3)
Partition
Netlist Type
Post-Fit
Quartus II Behavior for Partition During Compilation
Preserves post-fit results for the partition and uses the post-fit netlist as long as the following
conditions are true:
● A post-fit netlist is available from a previous fitting
● No change has been made to the associated source files since the previous fitting
Compiles the partition from the source files if there are source changes or if a post-fit netlist is
not available. Changes to assignments do not cause recompilation.
The Fitter Preservation Level specifies what level of information is preserved from the post-fit
netlist. For details, refer to “Fitter Preservation Level” on page 2–24.
You can use this netlist type to preserve the Fitter results unless source files change. You can
also use this netlist type to apply global optimizations, such as Physical Synthesis
optimizations, to certain partitions while preserving the fitting results for other partitions.
If a partition has an associated imported netlist, this setting is not available.
Post-Fit (Strict) Always preserves post-fit results for the partition. Uses the post-fit netlist even if changes have
been made to the associated source files since the previous fitting. For more information, refer
to “Forcing Use of the Post-Fitting Netlist When a Source File has Changed” on page 2–28.
The Fitter Preservation Level specifies what level of information is preserved from the postfit netlist. For details, refer to “Fitter Preservation Level” on page 2–24.
If a partition has an associated imported netlist, this setting is not available.
Imported
Compiles the design partition using a netlist imported from a Quartus II Exported Partition File
(.qxp).
The software does not modify or overwrite the original imported netlist during compilation. To
preserve changes made to the imported netlist (such as movement of an imported LogicLock
region), use the Post-Fit (Import-based) setting following a successful compilation with the
imported netlist. For additional details, refer to “Exporting and Importing Partitions for BottomUp Design Flows” on page 2–32.
The Fitter Preservation Level specifies what level of information is preserved from the
imported netlist. For details, refer to “Fitter Preservation Level” on page 2–24.
If you have not imported a netlist for this partition using the Import Design Partition command,
this setting is not available.
Altera Corporation
October 2007
2–23
Preliminary
Quartus II Handbook, Volume 1
Table 2–2. Netlist Type Settings (Part 3 of 3)
Partition
Netlist Type
Quartus II Behavior for Partition During Compilation
Post-Fit
Preserves post-fit results for the partition and uses the post-fit netlist as long as the following
(Import-based) conditions are true:
● A post-fit netlist is available from a previous fitting
● No change has been made to the associated imported netlist since the previous fitting
Compiles the partition from the imported netlist if the imported netlist changes (which means it
has been reimported) or if a post-fit netlist is not available. Changes to assignments do not
cause recompilation.
The Fitter Preservation Level specifies what level of information is preserved from the postfit netlist. For details, refer to “Fitter Preservation Level”.
You can use this netlist type to preserve changes to the placement and routing of an imported
netlist.
If a partition does not have an associated imported netlist, this setting is not available.
Empty
Uses an empty placeholder netlist for the partition and uses virtual pins at the partition
boundaries.
You can use this netlist type to skip the compilation of a lower-level partition. For more details
on the Empty setting, refer to “Empty Partitions” on page 2–26.
Fitter Preservation Level
The Fitter Preservation Level property specifies which information the
compiler will use from a post-fit or imported netlist. The property is only
available if the Netlist Type is set to Post-Fit, Post-Fit (Strict), Imported,
or Post-Fit (Import-based).
On the Assignments menu, click Design Partitions Window. You can
view and modify the Fitter Preservation Level by double-clicking an
entry. You can also right-click and click Properties, then edit the Fitter
Preservation Level on the Compilation tab.
2–24
Preliminary
Altera Corporation
October 2007
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Table 2–3 describes the Fitter Preservation Level settings.
Table 2–3. Fitter Preservation Level Settings
Fitter Preservation
Level
Netlist Only
Quartus II Behavior for Partition During Compilation
Preserves the netlist atoms of the design partition, but replaces and reroutes the design
partition. Unlike a Post-Synthesis netlist, a Post-Fit netlist with the atoms preserved
contains any Fitter optimizations, for example, registers duplicated by Physical Synthesis
during a previous Fitting.
You can use this setting to:
● Preserve Fitter optimizations but allow the software to perform placement and routing
again
● Reapply certain Fitter optimizations (that is, physical synthesis) that would otherwise
be impossible when the placement is locked down
● Resolve resource conflicts between two imported partitions in a bottom-up design flow
Placement
Preserves the netlist atoms and their placement in the design partition. Re-routes the
design partition.
This setting saves significant compilation time because the Fitter does not need to re-fit
the nodes in the partition. Note that the Fitter may need to modify the placement for timing
or legality reasons.
This setting might not be available if the netlist type is set to Imported and the imported
netlist does not contain placement data.
Placement and
Routing
Preserves the netlist atoms and their placement and routing in the design partition. The
minimum preservation level required to preserve Engineering Change Order (ECO)
changes made to the post-fitting netlist and SignalProbe pins added to the design.
This setting reduces compilation times compared to Placement only. Note that the Fitter
may need to modify the placement and routing for timing or legality reasons.
This setting may not be available if the netlist type is set to Imported and the imported
netlist does not contain routing data.
Placement, Routing,
and Tile
Preserves the netlist atoms and their placement and routing in the design partition, as well
as the power tile settings of high-speed or low-power.
Note that the Fitter may need to modify the placement and routing for timing or legality
reasons.
This setting is available only for devices with configurable power tiles (currently only
Stratix III devices).
Altera Corporation
October 2007
2–25
Preliminary
Quartus II Handbook, Volume 1
Empty Partitions
To set the Netlist Type to Empty, on the Assignments menu, click Design
Partitions Window, or double-click an entry, or right-click an entry and
click Design Partition Properties and select Empty. This setting specifies
that the Quartus II Compiler should use an empty placeholder netlist for
the partition.
You can use the Empty setting to skip the compilation of a lower-level
partition that is incomplete or missing from the top-level design. You can
also use it if you want to compile only some partitions in the design, such
as during optimization or if the compilation time is large for one partition
and you want to exclude it. This is useful if you want to optimize the
placement of a timing-critical block such as an IP core and then lock its
placement before adding the rest of your custom logic.
When a partition Netlist Type is defined as Empty, virtual pins are
created at the boundary of the partition. This means that the software
temporarily maps I/O pins in the lower-level design entity to internal
cells and not to pins during compilation.
Any subpartitions below an empty partition in the design hierarchy are
also treated as empty, regardless of their settings.
You can use a design flow in which some partitions are set to Empty in a
variation of a bottom-up design flow, where you develop pieces of the
design separately and then combine them at the top level at a later time.
When you implement part of the design without information about the
rest of the project, it is impossible for the Compiler to perform global
placement optimizations. One way to reduce this effect is to ensure the
input and output ports of the partitions are registered whenever possible,
as recommended in “Creating Good Design Partitions” on page 2–47.
When you set a design partition to Empty, a design file is required in
Analysis and Synthesis to specify, at minimum, the port interface
information so that it can connect the partition correctly to other logic and
partitions in the design. If the design file is missing, you must create a
wrapper file (called a black box or hollow-body file) that defines the
design block and specifies the input, output, and bidirectional ports. For
example, in Verilog HDL you should include a module declaration, and
in VHDL you should include an entity and architecture declaration.
2–26
Preliminary
Altera Corporation
October 2007
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
What Represents a Source Change for Incremental Compilation?
Any change in any design source file that affects a partition triggers an
automatic recompilation of the partition. The only exception is if the
partition's Netlist Type is set to Post-Fit (Strict) – refer to “Forcing Use of
the Post-Fitting Netlist When a Source File has Changed” on page 2–28.
The Quartus II software uses an internal checksum to determine whether
the contents of a source file have changed. Source files are the design files
used to create the design, and consist of VHDL files, Verilog HDL files,
AHDL files, Block Design Files (.bdf), EDIF netlists, VQM netlists, and
memory initialization files. Changes in other files such as vector
waveform files for simulation do not trigger recompilation.
Changes to certain project-wide assignments, such as changing the device
family, also trigger automatic recompilation.
Synthesis and Fitter assignments, including optimization settings, timing
assignments, or Fitter location assignments such as pin assignments or
LogicLock assignments, do not trigger automatic recompilation in the
incremental compilation flow. To recompile a partition with new
assignments, change the Netlist Type assignment for that partition to one
of the following:
■
■
■
Source File to recompile with all new settings
Post-Synthesis to recompile using existing synthesis results but new
Fitter settings
Post-Fit with the Fitter preservation Level set to Placement to rerun
routing using existing placement results except for any new routing
settings including delay chain settings
The project database folder (\db) includes all the netlist information for
previous compilations. To avoid unnecessary recompilations, the
database files must not be altered or deleted.
If you want to archive or reproduce the project in another location, you
can use a Quartus II Archive (.qar) file. On the Project menu, click
Archive Project and turn on Include database from compilation and
simulation so that compilation results are preserved. To manually create
a project archive that preserves compilation results without keeping the
entire compilation database, you should keep all source and settings files
and create and save a Quartus II Exported Partition (.qxp) file for each
partition in the design. Refer to “Exporting a Lower-Level Block within a
Project” on page 2–35 for more details.
Altera Corporation
October 2007
2–27
Preliminary
Quartus II Handbook, Volume 1
Determining Which Partitions Will Be Recompiled
When design files in a partition have dependencies on other files,
changing one file may trigger an automatic recompilation of another file.
The Partition Dependent Files table in the Analysis and Synthesis report
lists the design files that contribute to each design partition. You can use
this table to determine which partitions will be recompiled when a
specific file is changed.
For example, if a design has files a.v that contains entity a, b.v that
contains entity b, and c.v that contains entity c, then the Partition
Dependent Files table for the partition containing entity a lists file a.v,
the table for the partition containing entity b lists file b.v, and the table for
the partition containing entity c lists file c.v. Any dependencies are
transitive, so if file a.v depends on b.v, and b.v depends on c.v, then the
entities in file a.v depend on files b.v and c.v. In this case, files b.v and c.v
are listed in the report table as dependent files for the partition containing
entity a.
If you define module parameters in a higher-level module, you will create
file dependencies. The Quartus II software checks the parameter values
when determining which partitions require resynthesis. If you change a
parameter in a higher-level module that affects a lower-level module, the
lower-level module will be resynthesized.
If a design contains common files, such as a file includes.v that is
referenced in each entity by the command ‘include includes.v, then
all partitions are dependent on this file. A change to includes.v causes the
entire design to be recompiled. The VHDL statement use work.all
also typically results in unnecessary recompilations, because it makes all
entities in the work library visible in the current entity, which results in
the current entity being dependent on all other entities in the design.
To avoid this type of problem, ensure that files common to all entities,
such as a common include file, contain only the set of information that is
truly common to all entities. Remove use work.all statements in your
VHDL file or replace them by including only the specific design units
needed for each entity.
Forcing Use of the Post-Fitting Netlist When a Source File has Changed
Forcing the use of the post-fitting netlist when the contents of a source file
has changed is recommended only for advanced users who thoroughly
understand when a partition must be recompiled. You might want to use
this assignment, for example, if you are making source code changes but
do not want to recompile the partition until you finish debugging a
2–28
Preliminary
Altera Corporation
October 2007
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
different partition. To force the Fitter to use a previously generated postfit netlist even when there are changes to the source files, you can use the
Post-Fit (Strict) Netlist Type assignment.
Misuse of the Post-Fit (Strict) Netlist Type can result in the generation of
a functionally incorrect netlist when source design files change. Use
caution in applying this assignment.
Creating a
Design
Floorplan With
LogicLock
Location
Assignments
After you have partitioned the design, create floorplan location
assignments for the design as discussed in this section to improve the
quality of results when using the full incremental compilation flow.
Creating a design floorplan is not a requirement to use an incremental
compilation flow, but it is highly recommended in many cases. Floorplan
assignments are required if you want to import partition placement
results in a bottom-up flow to avoid placement conflicts at the top level.
You should also ensure that you have a LogicLock floorplan assignment
for any timing-critical blocks that will be recompiled as you make
changes to the design. Logic that is not timing-critical can float
throughout the device in a top-down compilation flow, so a floorplan
assignment might not be required in this case.
The simplest way to create a floorplan for a partitioned design is to create
one LogicLock region per partition (including the top-level partition).
Initially, you can leave each region with the default settings of Auto size
and Floating location to allow the Quartus II software to determine the
optimal size and location for the regions. Then, after compilation, use the
Fitter-determined size and origin location as a starting point for your
design floorplan. Check the quality of results obtained for your floorplan
location assignments and make changes to the regions as needed.
Alternately, you can perform synthesis, and then set the regions to the
required size based on resource estimates. In this case, use your
knowledge of the connections between partitions to place the regions in
the floorplan.
For more information about why creating a design floorplan is important
in many cases, refer to “The Importance of Floorplan Location
Assignments in Incremental Compilation” on page 2–55. For guidelines
on creating the floorplan, refer to “Creating Good Floorplan Location
Assignments” on page 2–57.
To create a LogicLock region for each design partition, use the following
general methodology:
1.
Altera Corporation
October 2007
On the Assignments menu, click Design Partitions Window and
ensure that all partitions have their Netlist Type set to Source File
or Post-Synthesis. If the Netlist Type is set to Post-Fit, floorplan
location assignments are not used when recompiling the design.
2–29
Preliminary
Quartus II Handbook, Volume 1
2.
Create a LogicLock region for each partition (including the top-level
entity, which is automatically considered a partition) using one of
the following methods:
●
●
In the Design Partitions window, right-click on a partition and
click Create New LogicLock Region. You can highlight
multiple (or all) partitions by holding down the Ctrl key and
clicking on each partition. Then you can choose the option to
create a separate LogicLock region for each highlighted
partition.
Under Compilation Hierarchy in the Project Navigator,
right-click each instance that is denoted as a partition and click
Create New LogicLock Region.
1
A LogicLock icon appears in the Project Navigator next to
each instance that is set as a LogicLock region (Figure 2–8).
Figure 2–8. Project Navigator Showing LogicLock Regions
3.
On the Processing menu, point to Start and click Start Early Timing
Estimate to place auto-sized, floating-location LogicLock regions.
1
You must perform Analysis and Synthesis and Partition
Merge before performing an Early Timing Estimate.
To run a full compilation instead of the Early Timing
Estimate, on the Processing menu, click Start Compilation.
2–30
Preliminary
4.
On the Assignments menu, click LogicLock Regions Window, and
click on each LogicLock region while holding the Ctrl key to select
all regions (including the top-level region).
5.
Right-click on the last selected LogicLock region, and click Set Size
and Origin to Previous Fitter Results.
Altera Corporation
October 2007
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
1
It is important that you use the Fitter-chosen locations only
as a starting point to make the regions of a fixed size and
location. On average, regions with fixed size and location
yield better fMAX than auto-sized regions.
Do not back-annotate the contents of the region, just save
the size and origin. Placement is preserved through the use
of the post-fit netlist and not any back-annotated content
assignments.
6.
If required, modify the size and location via the LogicLock Regions
Window or the Chip Planner. For example, make the regions bigger
to fill up the device and allow for future logic changes.
7.
On the Processing menu, point to Start and click Start Early Timing
Estimate to estimate the timing performance of your design with
these LogicLock regions.
8.
Repeat steps 6 and 7 until you are satisfied with the quality of
results for your design floorplan. On the Processing menu, click
Start Compilation to run a full compilation.
If you do not want to use auto-sized and floating-location regions, in
steps 3–5, you can estimate the size of the regions after synthesis. On the
Processing menu, point to Start, and choose Start Analysis & Synthesis.
Right-click on a region in the LogicLock Regions dialog box, and choose
Set to Estimated Size. Then continue with step 6 to modify the size and
origin of each region as appropriate.
Taking Advantage of the Early Timing Estimator
The methodology for creating a good floorplan takes advantage of the
Early Timing Estimator to enable quick compilations of the design while
creating assignments. The Early Timing Estimator feature provides a
timing estimate for a design as much as 45 times faster than running a full
compilation, yet estimates are, on average, within 11% of final design
timing. You can use the Chip Planner to view the “placement estimate”
created by this feature, identify critical paths by locating from the timing
analyzer reports, and, if necessary, add or modify floorplan constraints.
You can then rerun the Early Timing Estimator to quickly assess the
impact of any floorplan location assignments or logic changes, enabling
rapid iterations on design variants to help you find the best solution.
Altera Corporation
October 2007
2–31
Preliminary
Quartus II Handbook, Volume 1
Exporting and
Importing
Partitions for
Bottom-Up
Design Flows
The bottom-up flow refers to the design methodology in which a project
is first divided into smaller subdesigns that are implemented as separate
projects, potentially by different designers. The compilation results of
these lower-level projects are then exported and given to the designer (or
the project lead) who is responsible for importing them into the top-level
project to obtain a fully functional design.
In a bottom-up design flow, the top-level project lead can do much of the
design planning, and then pass constraints on to the designers of
lower-level blocks. The bottom-up design partition scripts generated by
the Quartus II software can make it easier to plan a bottom-up design,
and limit the difficulties that can arise when integrating separate designs.
Refer to “Generating Bottom-Up Design Partition Scripts for Project
Management” on page 2–40 for details.
Refer to “Bottom-Up Incremental Compilation” on page 2–13 in the
Quick Start Guide section for an overview of the entire flow. For examples
of team-based scenarios, refer to “Bottom-Up Incremental Design Flows”
on page 2–67.
This section describes the export and import features provided to support
bottom-up compilation flows. The section covers the following topics:
■
■
■
■
■
■
“Quartus II Exported Partition File (.qxp)”
“Exporting a Lower-Level Partition to be Used in a Top-Level
Project” on page 2–33
“Exporting a Lower-Level Block within a Project” on page 2–35
“Importing a Lower-Level Partition Into the Top-Level Project” on
page 2–36
“Importing Assignments and Advanced Import Settings” on
page 2–37
“Generating Bottom-Up Design Partition Scripts for Project
Management” on page 2–40
Quartus II Exported Partition File (.qxp)
The bottom-up incremental compilation flow uses a file called the
Quartus II Exported Partition file (or QXP) to represent lower-level
design partitions. The QXP is a binary file that contains compilation
results describing the exported design partition and includes a post-fit or
post-synthesis netlist, LogicLock regions, and a set of assignments. Note
that the QXP file does not contain the original source design files from the
lower-level design.
The following sections describe how to generate a QXP file for a
lower-level design partition, and how to import the QXP into the
top-level project.
2–32
Preliminary
Altera Corporation
October 2007
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Exporting a Lower-Level Partition to be Used in a Top-Level
Project
Each lower-level subdesign is compiled as a separate Quartus II project.
In each project, use the following guidelines to improve the exporting and
importing process:
■
■
■
■
Altera Corporation
October 2007
If you have a bottom-up design partition script from the top level,
source the Tcl script to create the project and all the assignments
from the top-level design. Doing so may create many of the
assignments described below. Ensure that the LogicLock region uses
only the resources allocated by the top-level project lead.
Ensure that you know which clocks should be allocated to global
routing resources so that there are no resource conflicts in the
top-level design.
●
Set the Global Signal assignment to On for the high fan-out
signals that should be routed on global routing lines.
●
To avoid other signals being placed on global routing lines, on
the Assignments menu, click Settings and turn off Auto Global
Clock and Auto Global Register Controls under More Settings
on the Fitter page of the Settings dialog box.
●
Alternatively, you can set the Global Signal assignment to Off
for signals that should not be placed on global routing lines.
Placement for LABs depends on whether the inputs to the logic
cells within the LAB use a global clock. You may encounter
problems if signals do not use global lines in the lower-level
design but use global routing in the top level.
Use the Virtual Pin assignment to indicate pins of a subdesign that
do not drive pins in the top-level design. This is critical when a
subdesign has more output ports than the number of pins available
in the target device. Using virtual pins also helps optimize
cross-partition paths for a complete design by enabling you to
provide more information about the subdesign ports, such as
location and timing assignments.
Because subdesigns are compiled independently without any
information about each other, you should provide more information
about the timing paths that may be affected by other partitions in the
top-level design. You can apply location assignments for each pin to
indicate where the port connection will be located after it is
incorporated in the top-level design. You can also apply timing
assignments to the I/O ports of the subdesign to perform timing
budgeting as described in “Timing Budgeting” on page 2–53.
2–33
Preliminary
Quartus II Handbook, Volume 1
When your subdesign partition has been compiled using these
guidelines, and is ready to be incorporated into the top-level design,
export a subdesign as a partition using the following steps:
1.
In the subdesign project, on the Project menu, click Export Design
Partition. The Export Design Partition dialog box appears
(Figure 2–9).
Figure 2–9. Export Design Partition Dialog Box
2.
In the Export file box, type the name of the Quartus II Exported
Partition file (.qxp). By default, the directory path and file name are
the same as the current project.
3.
You can also select the Partition hierarchy to export. By default, the
Top partition (the entire project) is exported, but you can choose to
export the compilation result of any partition hierarchy in the
project, as described in “Exporting a Lower-Level Block within a
Project” on page 2–35. Choose the partition hierarchy from the
drop-down box.
4.
Under Netlist to export, select either Post-fit netlist or
Post-synthesis netlist. The default is Post-fit netlist. For post-fit
netlists, turn on or off the Export routing option as required.
5.
Click OK. The Quartus II software creates the Quartus II Exported
Partition file in the specified directory.
Alternatively, you can set up your project so that the export process is
performed every time you compile the design:
2–34
Preliminary
Altera Corporation
October 2007
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
1.
On the Assignments menu, click Settings.
2.
In the Settings dialog box, under Compilation Process Settings,
select the Incremental Compilation page.
3.
Turn on Automatically export design partition after compilation.
4.
If you want to view or change the default export settings, click the
Export Design Partition Settings button to open the Export Design
Partition Settings dialog box (Figure 2–9).
5.
In the Export Design Partition Settings dialog box, change the
settings, if required, as in steps 2-4 in the preceding export
procedure. Click OK.
6.
Click OK to close the Settings dialog box. During the next full
compilation, the software will create the Quartus II Exported
Partition file in the specified directory.
Exporting a Lower-Level Block within a Project
Step 3 in “Exporting a Lower-Level Partition to be Used in a Top-Level
Project” enables you to create a Quartus II Exported Partition file for a
lower-level block within a Quartus II project. When you do this, the
command exports the entire hierarchy under the specified partition into
the QXP file.
You can use this feature to add test logic around a lower-level block that
will be exported as a design partition for a top-level design. You can also
instantiate additional design components in a lower-level project so it
matches the top-level design environment. For example, you can include
a top-level PLL in your lower-level project so that you can optimize the
design with information about the frequency multipliers, phase shifts,
compensation delays, and any other PLL parameters. The software then
captures timing and resource requirements more accurately while
ensuring that the timing analysis in the lower-level project is complete
and accurate. You can export the lower-level partition, without exporting
any auxiliary components to the top-level design.
In addition, you can use this feature in a top-down design flow to create
QXP files for specific design partitions that are complete. You can then
import the QXP file back into the project and use the Imported netlist
type. In this usage, the QXP file acts as an archive for the partition,
including the netlist and placement and routing information in one file. If
you need to change the source code for the partition, you must change the
netlist type back to Source File to use the source instead of the imported
information.
Altera Corporation
October 2007
2–35
Preliminary
Quartus II Handbook, Volume 1
Importing a Lower-Level Partition Into the Top-Level Project
The import process involves importing the design netlist from the
Quartus II Exported Partition file and adding the netlist to the database
for the top-level project. Importing also filters the assignments from the
subdesign and creates the appropriate assignments in the top-level
project.
To import a subdesign partition into a top-level design:
1.
In the top-level project, on the Project menu, click Import Design
Partition. Alternatively, right-click on the partition that you want to
import in the Design Partitions window and click Import Design
Partition. The Import Design Partition dialog box appears.
2.
In the Partition(s) box, browse to the desired partition. To choose a
partition, highlight the partition name in the Select Partition(s)
dialog box and use the appropriate buttons to select or deselect the
desired partitions.
1
3.
Under Import file, type the name of the Quartus II Exported
Partition file or browse for the file that you want to import into the
selected partition. Note that this file is required only during
importation, and is not used during subsequent compilations unless
you reimport the partition.
1
2–36
Preliminary
Note that you can select multiple partitions if your top-level
design has multiple instances of the subdesign partition
and you want to use the same imported netlist.
If you have already imported the Quartus II Exported
Partition file for this partition at least once, you can use the
same location as the previous import instead of specifying
the file name again. To do so, turn on Reimport using the
latest import files at previous locations. This option is
especially useful when you want to import the new
Quartus II Exported Partition files for several partitions
that you have already imported at least once. You can select
all the partitions to be imported in the Partition(s) box and
then use the Reimport using latest import files at previous
locations option to import all partitions using their
previous locations, without specifying individual file
names.
Altera Corporation
October 2007
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
4.
To view the contents of the selected Quartus II Exported Partition
file, click Load Properties. The properties displayed include the
Netlist Type, Entity name, Device, and statistics about the partition
size and ports.
5.
Click Advanced Import Settings and make selections, as
appropriate, to control how assignments and regions are integrated
from a subdesign into a top-level design partition. During
importation, some regions may be resized or slightly moved. Click
OK to apply the settings.
For more information about the advanced settings, refer to
“Importing Assignments and Advanced Import Settings” on
page 2–37.
6.
In the Import Design Partition dialog box, click OK to start
importation. The specified Quartus II Exported Partition file is
imported into the database for the current top-level project.
Importing Assignments and Advanced Import Settings
When you import a subdesign partition into a top-level design, the
software sets certain assignments by default and also imports relevant
assignments from the subdesign into the top-level design.
Design Partition Properties after Importing
When you import a subdesign partition, the import process sets the
partition’s Netlist Type to Imported.
If you compile the design and make changes to the place-and-route
results, use the Post-Fit (Import-based) Netlist Type on the subsequent
compilation. To discard an imported netlist and recompile from source
code, simply compile the partition with netlist type set to Source File and
be sure to include the relevant source code with the top-level project.
The import process sets the partition’s Fitter Preservation Level to the
setting with the highest degree of preservation supported by the
imported netlist. For example, if a post-fit netlist is imported with
placement information, the level is set to Placement, but you can change
it to the Netlist Only value.
Refer to “Setting the Netlist Type for Design Partitions” on page 2–22 for
details about the Netlist Type and Fitter Preservation Level setting.
Altera Corporation
October 2007
2–37
Preliminary
Quartus II Handbook, Volume 1
Importing Design Partition Assignments Within the Subdesign
Design partition assignments defined within the subdesign project are
not imported into the top-level project. All logic in the subdesign is
imported as one partition in the QXP file.
Synopsys Design Constraint (SDC) Files for the Quartus II TimeQuest
Timing Analyzer
Timing assignments made for the Quartus II TimeQuest Timing
Analyzer in an SDC file are currently not imported into the top-level
project. You should manually ensure that the top-level project includes
all of the timing requirements for the entire project.
If you want to copy lower-level SDC files to the top-level project, consider
prefixing lower-level constraints with a variable for the design hierarchy.
Then, when you copy the file to the top-level design, you can set the
variable to provide the hierarchy path to the lower-level partition in the
top-level design.
Importing LogicLock Assignments
LogicLock regions are set to a fixed size when imported. If you instantiate
multiple instances of a subdesign in the top-level design, the imported
LogicLock regions are set to a Floating location. Otherwise, they are set to
a Fixed location. You can change the location of LogicLock regions after
they are imported, or change them to a Floating location to allow the
software to place each region but keep the relative locations of nodes
within the region wherever possible. If you want to preserve changes
made to a partition after compilation, use the Netlist Type Post-Fit
(Import-Based).
The LogicLock Member State assignment is set to Locked to signify that
it is a preserved region.
LogicLock back-annotation and node location data is not imported
because the Quartus II Exported Partition file contains all the relevant
placement information. Altera strongly recommends that you do not add
to or delete members from an imported LogicLock region.
Importing Other Instance Assignments
All instance assignments are imported, with the exception of design
partition assignments, SDC constraints, and LogicLock assignments, as
described previously.
2–38
Preliminary
Altera Corporation
October 2007
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Importing Global Assignments
Global assignments are not imported. The project lead should make
global assignments in the top-level design. Global assignments include
clock settings for the Quartus II Classic Timing Analyzer.
Advanced Import Settings
The Advanced Import Settings dialog box allows you to specify the
options that control how assignments and regions are integrated and how
to resolve assignment conflicts when importing a subdesign partition into
a top-level design. The following subsections describe each of these
options.
Allow Creation of New Assignments
Allows the import command to add new assignments from the imported
project to the top-level project.
When this option is turned off, it imports updates to existing
assignments, but no new assignments are allowed.
Promote Assignments to all Instances of the Imported Entity
Converts and promotes entity-level assignments from the subdesign into
instance-level assignments in the top-level design.
Assignment Conflict Resolution: LogicLock Regions
Choose one of the following options to determine how to handle
conflicting LogicLock assignments (that is, subdesign assignments that
do not match the top-level assignments):
■
■
■
Always replace regions in the current project (default)—Deletes
existing regions and replaces them with the new subdesign region.
Any changes made to the LogicLock region after the assignments
were imported are also deleted.
Always update regions in the current projects—Overwrites existing
region assignments to reflect any new subdesign assignments with
the exception of the LogicLock Origin, in case the project lead has
made floorplan location assignments in the top-level design.
Skip conflicting regions—Ignores and does not import subdesign
assignments that conflict with any assignments that exist in the
top-level design.
Assignment Conflict Resolution: Other Assignments
Choose one of the following options to determine how to handle conflicts
with other types of assignments (that is, the subdesign assignments do
not match the top-level assignments):
Altera Corporation
October 2007
2–39
Preliminary
Quartus II Handbook, Volume 1
■
■
Always replace assignments in the current project (default)—
Overwrites or updates existing instance assignments with the new
subdesign assignments.
Skip conflicting assignments—Ignores and does not import
subdesign assignments that conflict with any assignments that exist
in the top-level design.
Generating Bottom-Up Design Partition Scripts for Project
Management
The bottom-up design partition scripts automate the process of
transferring top-level project information to lower-level modules. The
software provides a project manager interface for managing resource and
timing budgets in the top-level design. This makes it easier for designers
of lower-level modules to implement the instructions from the project
lead, and avoid conflicts between projects when importing and
incorporating the projects into the top-level design. This helps reduce the
need to further optimize the designs after integration, and improves
overall designer productivity and team collaboration.
1
Generating bottom-up design partition scripts is optional in any
bottom-up design methodology.
For example design scenarios using these scripts, refer to “Bottom-Up
Incremental Design Flows” on page 2–67. In a typical bottom-up design
flow, the project lead must perform some or all of the following tasks to
ensure successful integration of the subprojects:
■
■
■
■
2–40
Preliminary
Manually determine which assignments should be propagated from
the top level to the bottom levels. This requires detailed knowledge
of which Quartus II assignments are needed to set up low-level
projects.
Manually communicate the top-level assignments to the low-level
projects. This requires detailed knowledge of Tcl or other scripting
languages to efficiently communicate project constraints.
Manually determine appropriate timing and location assignments
that will help overcome the limitations of bottom-up design. This
requires examination of the logic in the lower levels to determine
appropriate timing constraints.
Perform final timing closure and resource conflict avoidance at the
top level. Because the low-level projects have no information about
each other, meeting constraints at the lower levels does not
guarantee they will be met when integrated at the top-level. It then
becomes the project lead’s responsibility to resolve the issues, even
though information about the low-level implementation may not be
available.
Altera Corporation
October 2007
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Using the Quartus II software to generate bottom-up design partition
scripts from the top level of the design makes these tasks much easier and
eliminates the chance of error when communicating between the project
lead and lower-level designers. Partition scripts pass on assignments
made in the top-level design, and create some new assignments that
guide the placement and help the lower-level designers see how their
design connects to other partitions. If necessary, you can exclude specific
design partitions.
Generate design partition scripts after a successful compilation of the
top-level design. On the Project menu, click Generate Bottom-Up Design
Partition Scripts. The design can have empty partitions as placeholders
for lower-level blocks, and you can perform an Early Timing Estimation
instead of a full compilation to reduce compilation times.
The following subsections describe the information that can be included
in the bottom-up design partition Tcl scripts. Use the options in the
Generate Bottom-Up Design Partition Scripts dialog box to choose
which types of assignments you want to pass down and create in the
lower-level partition projects. Each time you rerun the script generation
process, the Quartus II software recreates the files and replaces older
versions.
For information about current limitations in the bottom-up partition
scripts, refer to “Bottom-Up Design Partition Script Limitations” on
page 2–84.
Project Creation
You can use the Create lower-level project if one does not exist option
for the partition scripts to create lower-level projects if they are required.
The Quartus II Project File for each lower-level project has the same name
as the entity name of its corresponding design partition.
With this project creation feature, the scripts work by themselves to create
a new project, or can be sourced to make assignments in an existing
project.
Excluded Partitions
Use the Excluded partition(s) option at the bottom of the dialog box to
exclude specific partitions from the Tcl script generation process. Use the
browse button, then highlight the partition name in the Select
Partition(s) dialog box and use the appropriate buttons to select or
deselect the desired partitions.
Altera Corporation
October 2007
2–41
Preliminary
Quartus II Handbook, Volume 1
Assignments from the Top-Level Design
By default, any assignments made at the top level (not including default
assignments or project information assignments) are passed down to the
appropriate lower-level projects in the scripts. The software uses the
assignment variables and determines the logical partition(s) to which the
assignment pertains (this includes global assignments, instance
assignments, and entity-level assignments). The software then changes
the assignments so that they are syntactically valid in a project with its
target partition’s logic as the top-level entity.
The names of the design files that apply to the specific partition are added
to each lower-level project. Note that the script uses the file name(s)
specified in the top-level project. If the top-level project used a
placeholder wrapper file with a different name than the design file in the
lower-level project, you should be sure to add the appropriate file to the
lower-level project.
The scripts process wildcard assignments correctly, provided there is
only one wildcard. Assignments with more than one wildcard are
ignored and warning messages are issued.
Use the following options to specify which types of assignments to pass
down to the lower-level projects:
■
■
■
2–42
Preliminary
Timing assignments—When this option is turned on, all Classic
Timing Analyzer global timing assignments for the lower-level
projects are included in the script, including tCO, tSU, and fMAX
constraints. This option may also include timing constraints on
internal partition connections.
Design partition assignments—When this option is turned on,
script assignments related to design partitions in the lower-level
projects are included, as well as assignments associated with
LogicLock regions.
Pin location assignments—When this option is turned on, all pin
location assignments for lower-level project ports that connect to
pins in the top-level design are included in the script, controlling the
overuse of I/Os at the top-level during the integration phase and
preserving placement.
Altera Corporation
October 2007
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Virtual Pin Assignments
When Create virtual pins at low-level ports connected to other design
units is turned on, the Quartus II software searches partition netlists and
identifies all ports that have cross-partition dependencies. For each
lower-level project pin associated with an internal port in another
partition or in the top-level project, the script generates a virtual pin
assignment, ensuring more accurate placement, because virtual pins are
not directly connected to I/O ports in the top-level project. These pins are
removed from a lower-level netlist when it is imported into the top-level
design.
Virtual Pin Timing and Location Assignments
One of the main issues in bottom-up design methodologies is that each
individual design block includes no information about how it is
connected to other design blocks. If you turn on the option to write virtual
pin assignments, you can also turn on options to constrain these virtual
pins to achieve better timing performance after the lower-level partitions
are integrated at the top level.
When Place created virtual pins at location of top-level source/sink is
turned on, the script includes location constraints for each virtual pin
created. Virtual output pins are assigned to the location of the
connection’s destination in the top-level project, and virtual input pins
are assigned to the location of the connection’s source in the top-level
project. Note that if the top-level design uses Empty partitions, the final
location of the connection is not known but the pin is still assigned to the
LogicLock region that contains its source or destination.
As a result, these virtual pins are no longer placed inside the LogicLock
region of the lower-level project, but at their location in the top-level
design, eliminating resource consumption in the lower-level project and
providing more information about lower-level projects and their port
dependencies. These location constraints are not imported into the
top-level project.
When Add maximum delay to created virtual input pins, Add
maximum delay from created virtual output pins, or both, are turned on,
the script includes timing constraints for each virtual pin created. The
value you enter in the dialog box is the maximum delay allowed to or
from all paths between virtual pins to help meet the timing requirements
for the complete design. The software uses the INPUT_MAX_DELAY
assignment or OUTPUT_MAX_DELAY assignment to apply the constraint.
Altera Corporation
October 2007
2–43
Preliminary
Quartus II Handbook, Volume 1
This option allows the project lead to specify a general timing budget for
all lower-level internal pin connections. The lower-level designer can
override these constraints by applying individual node-level
assignments on any specific pin as needed.
LogicLock Region Assignments
When Copy LogicLock region assignments from top-level is turned on,
the script includes assignments identifying the LogicLock assignment for
the partition.
The script can also pass assignments to create the LogicLock regions for
all other partitions. When Include all LogicLock regions in lower-level
projects is turned on, the script for each partition includes all LogicLock
region assignments for the top-level project and each lower-level
partition, revealing the floorplan for the complete design in each
partition. Regions that do not belong to other partitions contain virtual
pins representing the source and destination ports for cross-partition
connections. This allows each designer to more easily view the
connectivity between their partition and other partitions in the top-level
design, and helps ensure that resource conflicts at the top level are
minimized.
When Remove existing LogicLock regions from lower-level projects is
turned on, the script includes commands to remove LogicLock regions
defined in the lower-level project prior to running the script. This ensures
that LogicLock regions not part of the top-level project do not become
part of the complete design, and avoids any location conflicts by ensuring
lower-level designs use the LogicLock regions specified at the top level.
Global Signal Promotion Assignments
To help prevent conflicts in global signal usage when importing projects
into the top-level design, you can choose to write assignments that
control how signals are promoted to global routing resources in the
lower-level partitions. These options can help resource balancing of
global routing resources.
When Promote top-level global signals in lower-level projects is turned
on, the Quartus II software searches partition netlists and identifies
global resources, including clock signals. For the relevant partitions, the
script then includes a global signal promotion assignment, providing
information to the lower-level projects about global resource allocation.
When Disable automatic global promotion in lower-level projects is
turned on, the script includes assignments that turn off all automatic
global promotion settings in the lower-level projects. These settings
2–44
Preliminary
Altera Corporation
October 2007
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
include the Auto Global Memory Control Signals logic option, output
enable logic options, and clock and register control promotions. If you
select the Disable automatic global promotion in lower-level projects
option in conjunction with the Promote top-level global signals in
lower-level projects option, you can ensure that only signals promoted
to global resources in the top-level are promoted in the lower-level
projects.
Makefile Generation
Makefiles allow you to use make commands to ensure that a bottom-up
project is up-to-date if you have a make utility installed on your
computer. The Generate makefiles to maintain lower-level and
top-level projects option creates a makefile for each design partition in
the top-level design, as well as a master makefile that can run the
lower-level project makefiles. The Quartus II software places the master
makefiles in the top-level directory, and the partition makefiles in their
corresponding lower-level project directories.
You must specify the dependencies in the makefiles to indicate which
source file should be associated with which partition. The makefiles use
the directory locations generated using the Create lower-level project if
one does not exist option. If you created your lower-level projects
without using this option, you must modify the variables at the top of the
makefile to specify the directory location for each lower-level project.
To run the makefiles, use a command such as
make -f master_makefile.mak from the script output directory. The
master makefile first runs each lower-level makefile, which sources its Tcl
script and then generates a Quartus II Exported Partition file to export the
project as a design partition. Next, run the top-level makefile that
specifies these newly generated Quartus II Exported Partition files as the
import files for their respective partitions in the top-level project. The
top-level makefile then imports the lower-level results and performs a
full compilation, producing a final design.
To exclude a certain partition from being compiled, edit the
EXCLUDE_FLAGS section of master_makefile.mak according to the
instructions in the file, and specify the appropriate options. You can also
exclude some partitions from being built, exported, or imported using
make commands. To exclude a partition, run the makefile using a
command such as the one for the GNU make utility shown in the
following example:
gnumake –f master_makefile.mak exclude_<partition directory>=1 r
Altera Corporation
October 2007
2–45
Preliminary
Quartus II Handbook, Volume 1
This command instructs that the partition whose output files are in
<partition directory> are not built. Multiple directories can be excluded by
adding multiple exclude_<partition directory> commands.
Command-line options override any options in the makefile.
Another feature of makefiles is the ability to have the master makefile
invoke the low-level makefiles in parallel on systems with multiple
processors. This option can help designers working with multiple CPUs
greatly improve their compilation time. For the GNU make utility, add
the -j<N> flag to the make command. The value <N> is the number of
processors that can be used to run the build.
1
Guidelines for
Creating Good
Design
Partitions and
LogicLock
Regions
The makefile does not include a make clean option, so the design
may recompile when make is run again and a QXP file already
exists.
This section provides guidelines for creating design partitions and
floorplan location assignments that will help you achieve good quality
results, as well as criteria and methodologies to check the quality of your
assignments.
When planning your design, keep in mind the size and scope of each
partition, and the likelihood that different parts of your design might
change as your design develops. Consider placing logic that changes
frequently into its own partition, so that you have to recompile only that
partition if the rest of the design stays the same. Similarly, consider
placing fixed logic, such as IP cores or logic reused from another project,
into its own partition so that you can compile once and lock down the
placement immediately with a post-fit netlist.
Creating partitions prevents the compiler from performing logic
optimizations across partition boundaries (Figure 2–10), allowing the
software to synthesize and place each partition separately.
Figure 2–10. Effects of Partition Boundaries During Optimization
Hierarchy A
Hierarchy B
Compile without
Partition Boundaries
Cannot Obtain Results of an
Individual Hierarchy for
Incremental Compilation
Hierarchy A
Hierarchy B
Compile with
Partition Boundaries
Presence of Cross-Boundary
Optimizations
Hierarchy A
Hierarchy B
Hierarchies Remain Independent
from One Another During Logic
Optimizations
Possible to Incrementally
Recompile Each Hierarchy
2–46
Preliminary
Altera Corporation
October 2007
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
For example, consider a design with a 36-bit function defined in partition
A, but with only 18 bits connected in partition B. In a flat design, you
would expect the logic for the other 18 bits to be removed during
synthesis. With incremental compilation, the Quartus II compiler does
not remove the (unused) logic from partition A because partition B is
allowed to change independently from partition A. That is, you could
later connect all 36 bits in partition B. In this case, you should remove the
unconnected ports and replace them with ground signals inside partition
A. You can create a new wrapper file to do this.
Another example is the case in which a clock is inverted at partition
boundary, but the inversion should be done in the destination LAB for
best results. With incremental compilation, the Quartus II compiler uses
logic to invert the signal, then routes the signal on global clock resource
to its destinations within the partition. The signal acts as a gated clock
with high skew. You must set up partitions to ensure that optimization
does not rely on information from other partitions, so you should
perform clock inversions in the destination partitions.
Because cross-boundary optimizations cannot occur when using
partitions, the quality of results and performance of the design may
decrease as the number of partitions increases. Although more partitions
allows for greater reduction in compilation time, you should limit the
number of partitions to prevent degradation of the quality of results. This
effect is more pronounced in a bottom-up methodology than a top-down
methodology.
In a top-down compilation where partitions are not locked down with
post-fitting results, the Fitter can perform placement optimizations on the
design as a whole to optimize the placement of cross-partition paths.
(However, the Fitter cannot perform logic optimizations such as physical
synthesis across the partition boundary.) In a bottom-up flow, partitions
are compiled separately. Typically, the fitting results are exported, so
there is no placement optimization across the partitions boundaries.
Creating Good Design Partitions
Altera recommends that you observe the following important
hierarchical design considerations when creating partitions:
■
Altera Corporation
October 2007
Register all inputs and outputs of each partition. This helps avoid
any delay penalty on signals that cross partition boundaries. At the
very least, either the inputs or the outputs should be registered. The
Statistics reports described in the “Partition Statistics Reports”
section list the ports registered for each partition.
2–47
Preliminary
Quartus II Handbook, Volume 1
1
■
■
■
2–48
Preliminary
While this can be difficult in practice, adherence to this
principle results in less timing degradation and area
increase when using incremental flows. Registering lessens
the need for the cross-partition optimizations that are
prevented by partitioning. By registering the ports, you can
keep critical paths within a single partition, thus keeping
the lengths of inter-partition register-to-register paths to a
minimum.
Minimize the number of paths that cross partition boundaries. If
there are critical paths crossing between partitions, rework the
partitions to avoid these inter-partition paths. Capturing as many of
the timing-critical connections as possible inside a partition allows
you to effectively apply optimizations to that partition to improve
timing, while leaving the rest of the design unchanged. The Statistics
reports described in “Partition Statistics Reports” on page 2–50 list
the number of input and output ports for each partition.
Ensure that the size of each partition is not too small (as a rough
guideline, partitions should be greater than 2,000 logic elements
(LEs) or adaptive logic modules (ALMs)). The Statistics reports
described in the “Partition Statistics Reports” section list the logic
utilization of each partition.
Minimize the number of unconnected ports at partition boundaries.
When a port is left unconnected, optimizations that remove logic
driving that port could improve results. However, these
optimizations are not allowed in an incremental design, because they
would lead to cross-partition dependence. Altera recommends that
you either connect such ports to an appropriate node or remove them
from the design. If you know the port should not be used, consider
defining a wrapper module with a port interface that reflects this
fact. The Statistics reports described in the “Partition Statistics
Reports” section list the number of unconnected input and output
ports for each partition.
Altera Corporation
October 2007
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
■
■
■
■
■
■
Altera Corporation
October 2007
Do not use tri-state signals or bidirectional ports on hierarchical
boundaries, unless the port is connected directly to a top-level I/O
pin on the device. If you use boundary tri-states in a lower-level
block, synthesis pushes the tri-states through the hierarchy to the top
level to take advantage of the tri-state drivers on the output pins of
the device.
In an incremental compilation flow, internal tri-states are supported
only when all the destination logic is contained in the same partition,
in which case Analysis and Synthesis implements the internal
tri-state signals using multiplexing logic. For a bidirectional port that
feeds a bidirectional pin at the top level, all the logic that forms the
bidirectional I/O cell must reside in the same partition.
Note that logic is not synthesized or optimized across partition
boundaries, which means any constant value (for example, a signal
set to GND) is not propagated across partitions. If a port is supposed
to be connected to VCC or GND, replace the port with VCC or GND in
the module's design. This allows optimizations to take place that
could not be performed if VCC or GND is connected through a port.
Do not use the same signal to drive multiple ports on a single
partition. If the same driving signal feeds multiple ports of a
partition, those ports are logically equivalent. However, because
inter-partition optimizations cannot be performed, the compilation
of that partition cannot take advantage of this fact, which usually
results in sub-optimal performance. For example, if a single clock is
used to drive the read and write clocks of a RAM block and the RAM
block is compiled separately in a bottom-up design flow, the RAM
block is implemented as though there are two unique clocks. If you
know the port connectivity will not change (that is, the ports will
always be driven by the same signal), redefine the port interface so
there is only a single port that can then internally drive other logic in
the partition. If required, you can create a wrapper module around
the partition that has fewer ports.
Do not directly connect two ports of a partition. If two ports on a
module are directly connected, consider redefining the module to
remove those ports. If an output port drives an input port on the
same module, the connection can be made internally without going
through any I/O ports. If an input port drives an output port
directly, the connection can likely be implemented without the ports
by connecting the signals in a higher-level design partition.
You may have to perform some manual resource balancing across
partitions if device resources are overused in the individual
partitions. Refer to “Resource Balancing” on page 2–51 for details.
You may have to perform some timing budgeting if paths that cross
partition boundaries require further optimization. Refer to “Timing
Budgeting” on page 2–53 for details.
2–49
Preliminary
Quartus II Handbook, Volume 1
You can use the Incremental Compilation Advisor to check that your
design follows many of these guidelines. Refer to “Incremental
Compilation Advisor” on page 2–60 for more details.
Partition Statistics Reports
You can view statistics about design partitions in the Partition Merge
Partition Statistics compilation report and the Statistics tab in the Design
Partitions Properties dialog box.
The Partition Statistics page under the Partition Merge folder of the
Compilation Report lists statistics about each partition. The statistics for
each partition (each row in the table) include the number of logic cells it
contains, as well as the number of input and output pins it contains and
how many are registered or unconnected. This report is useful when
optimizing your design partitions in a top-down compilation flow, or
when you are compiling the top-level design in a bottom-up compilation
flow, ensuring that the partitions meet the guidelines presented in
“Creating Good Design Partitions” on page 2–47. Figure 2–11 shows the
report window.
Figure 2–11. Partition Merge Partition Statistics Report
You can also view statistics about the resource and port connections for a
particular partition on the Statistics tab of the Design Partition
Properties dialog box. On the Assignments menu, click Design
Partitions Window. Right-click on a partition and click Properties to
open the dialog box. Click Show All Partitions to view all the partitions
in the same report (Figure 2–12).
2–50
Preliminary
Altera Corporation
October 2007
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Figure 2–12. Statistics Tab in the Design Partitions Properties Dialog Box
Resource Balancing
When using incremental compilation, the software synthesizes each
partition separately, with no data about the resources used in other
partitions. This means that device resources could be overused in the
individual partitions during synthesis, and thus the design may not fit in
the target device when the partitions are merged.
In a bottom-up design flow in which designers optimize their lower-level
designs and export them to a top-level design, the software also places
and routes each partition separately. In some cases, partitions can use
conflicting resources when combined at the top level.
To avoid these effects, you may have to perform manual resource
balancing across partitions.
Altera Corporation
October 2007
2–51
Preliminary
Quartus II Handbook, Volume 1
RAM and DSP Blocks
In the standard synthesis flow, when DSP blocks or RAM blocks are
overused, the Quartus II Compiler can perform resource balancing and
convert some of the logic into regular logic cells (for example, LEs or
ALMs). Without data about resources used in other partitions, it is
possible for the logic in each separate partition to maximize the use of a
particular device resource, such that the design does not fit after all the
partitions are merged. In this case, you may be able to manually balance
the resources by using the Quartus II synthesis options to control
inference of megafunctions that use the DSP or RAM blocks. You can also
use the MegaWizard® Plug-In Manager to customize your RAM or DSP
megafunctions to use regular logic instead of the dedicated hardware
blocks.
f
For more information about resource balancing when using Quartus II
synthesis, refer to the Megafunction Inference Control section in the
Quartus II Integrated Synthesis chapter in volume 1 of the Quartus II
Handbook. For more tips about resource balancing and reducing resource
utilization, refer to the appropriate Resource Utilization Optimization
Techniques section in the Area and Timing Optimization chapter in
volume 2 of the Quartus II Handbook.
Altera recommends using a LogicLock region for each partition to
minimize the chance that the logic in more than one partition uses the
same logic resource. However, there are situations in which partition
placement may still cause conflicts at the top level. For example, you can
design a partition one way in a lower-level design (such as using an
M-RAM memory block) and then instantiate it in two different ways in
the top level (such as one using an M-RAM block and another using an
M4K block). In this case, you can use a post-fit netlist only with no
placement information to allow the software to refit the logic.
Global Routing Signals
Global routing signals can cause conflicts when multiple projects are
imported into a top-level design. The Quartus II software automatically
promotes high fan-out signals to use global routing resources available in
the device. Lower-level partitions can use the same global routing
resources, thus causing conflicts at the top level.
In addition, LAB placement depends on whether the inputs to the
LCELLs within the LAB are using a global clock signal. Therefore,
problems can occur if a design does not use a global signal in the
lower-level design, but does use a global signal in the top-level design.
2–52
Preliminary
Altera Corporation
October 2007
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
To avoid these problems, the project lead can first determine which
partitions will use global routing signals. Each designer of a lower-level
partition can then assign the appropriate type of global signals manually,
and prevent other signals from using global routing resources. If you
have all partitions available, you can compile the entire design at the top
level with floorplan assignments to allow the use of regional clocks that
span only a part of the chip. The Fitter automatically promotes some
signals to global routing, and you can use this information when
optimizing the lower-level partitions in separate Quartus II projects.
Use the Global Signal assignment set to a value of On or Off in the
Assignment Editor to place a signal on a global routing line, or to prevent
the signal from using a global routing line. You can also assign certain
types of global clock resources in some device families, such as regional
clocks that cover only part of the device. You can view the resource
coverage of such clocks in the Chip Planner, and then align LogicLock
regions that constrain partition placement with available global clock
routing resources. For example, if the LogicLock region for a particular
partition is limited to one device quadrant, that partition’s clock can use
a regional clock routing type that covers only one device quadrant.
If you want to disable the automatic global promotion performed in the
Fitter, turn off the Auto Global Clock and Auto Global Register Control
Signals options. On the Assignments menu, click Settings. On the Fitter
Settings page, click More Settings and change the settings to Off.
Alternatively, to avoid problems when importing, direct the Fitter to
discard the placement and routing of the imported netlist by setting the
Fitter preservation level property of the partition to Netlist Only. With
this option, the Fitter re-assigns all the global signals for this particular
partition when compiling the top-level design.
If you are performing a bottom-up flow using the design partition scripts,
the software can automatically write the commands to pass global
constraints and turn off the automatic options. Refer to “Generating
Bottom-Up Design Partition Scripts for Project Management” on
page 2–40 for details.
Timing Budgeting
If you optimize lower-level partitions independently and import them to
the top level, any unregistered paths that cross between partitions are not
optimized as an entire path. One way to reduce this effect is to ensure
input and output ports of the partitions are registered whenever possible.
Altera Corporation
October 2007
2–53
Preliminary
Quartus II Handbook, Volume 1
To ensure that the Compiler correctly optimizes the input and output
logic in each partition, you may be required to perform some manual
timing budgeting. For each unregistered timing path that crosses
between partitions, make timing assignments on the corresponding I/O
path in each partition to constrain both ends of the path to the budgeted
timing delay. Timing budgets may be required for these I/O ports
because when the Compiler optimizes each partition, it has no
information about the placement of the logic that connects to that port. If
the logic in one partition is placed far away from logic in another
partition, the routing delay between the logic could lead to problems
meeting the timing requirements. Assigning a timing budget for each
part of the connection ensures that the Compiler optimizes the paths
appropriately.
When performing manual timing budgeting, you can also use Virtual Pin
assignments to represent I/O ports of a partition that feed another
partition in the full design. By assigning location and timing constraints
to the Virtual Pins that represent the connections in the full design, you
can further improve the quality of the timing budget.
If you are performing a bottom-up flow using the design partition scripts,
the software can write virtual pin assignments and I/O timing budget
constraints automatically. Refer to “Generating Bottom-Up Design
Partition Scripts for Project Management” on page 2–40 for details.
Methodology to Check Partition Quality during Partition Planning
There is an inherent tradeoff between compilation time and quality of
results when you vary the number of partitions in a project. You can
ensure that you limit this effect by following an iterative methodology
during the partitioning process. In any incremental compilation flow in
which you can compile the source code for each partition during the
partition planning phase, Altera recommends the following iterative
flow:
2–54
Preliminary
1.
Start with a complete design that is not partitioned and has no
location or LogicLock assignments.
2.
To perform a placement and timing analysis estimate, on the
Processing menu, point to Start and click Start Early Timing
Estimate.
Altera Corporation
October 2007
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
1
You must perform Analysis and Synthesis before
performing an Early Timing Estimate. If incremental
compilation is already turned on, you must also perform
Partition Merge.
To run a full compilation instead of the Early Timing Estimate, on the
Processing menu, click Start Compilation.
3.
Record the quality of results from the Compilation Report (fM A X ,
area, and so forth).
4.
Create design partitions as described in “Creating Design
Partitions” on page 2–19 using the guidelines in “Creating Good
Design Partitions” on page 2–47.
5.
Perform another Early Timing Estimate or full compilation.
6.
Record the quality of results from the Compilation Report. If the
quality of results is significantly worse than that obtained in the
previous compilation in Step 3, repeat Step 4 through this step
(Step 6) to change your partition assignments and use a different
partitioning scheme.
7.
Even if the quality of results is acceptable, you can repeat Step 4
through Step 6 by further dividing a large partition into several
smaller partitions. Doing so improves compilation time in future
incremental compilations. You can repeat this step until you achieve
a good tradeoff point (that is, all critical paths are localized within
partitions, the quality of results is not negatively affected, and the
size of each partition is reasonable).
The Importance of Floorplan Location Assignments in
Incremental Compilation
Floorplan location planning can be very important for a design that uses
full incremental compilation, for the following two reasons:
■
■
To avoid resource conflicts between partitions
To ensure a good quality of results when recompiling partitions and
other partition placement is unchanged
Location assignments for each partition ensures that there are no conflicts
for locations between different partitions. If there are no LogicLock
region assignments, or if LogicLock regions are set to auto-size or
floating, it is unclear which resources on the device are allocated for the
logic associated with the region. Without clearly defining this resource
budget, bottom-up design can produce many resource conflicts when
Altera Corporation
October 2007
2–55
Preliminary
Quartus II Handbook, Volume 1
importing results, because each bottom-up partition has no information
about its resource budget and may therefore claim resources required by
another partition.
In addition, a design floorplan helps to avoid the situation that arises
when the Fitter is directed to place or replace a portion of the design in an
area of the device where most resources have already been claimed. In
this case, the placement of the post-fit netlists of other modules forces the
Fitter to place the new portion of the design in the empty parts of the
device. There are two immediate disadvantages to this situation. First, the
Fitter must work harder because of the higher number of physical
constraints, and therefore compilation time probably increases. Second,
the quality of results often decreases, sometimes dramatically, because
the placement of the target module is now scattered throughout the
device.
Figures 2–13 and 2–14 illustrate the problems associated with refitting
designs that do not have floorplan location assignments. Figure 2–13
shows the initial placement of a four-partition design (P1–P4) without
floorplan location assignments. The second part of the figure shows the
situation if a change occurs to P3. After removing the logic for the
changed partition, the Fitter must replace and reroute the new logic for
P3 using the white space shown in the figure.
Figure 2–13. Representation of Device Floorplan without Location
Assignments
P1
P2
P3
P1
P2
P3
P1
P4
P2
P1
Device Floorplan
With 4 Partitions
P1
P4
P2
P3
P1
Device Floorplan
After Removing Changed Partition P3
Performing this placement is very difficult. The Fitter may not be able to
find any legal placement for the logic in partition P3, even if it was able to
do so in the initial compilation. If the Fitter does find a legal placement,
the results are probably sub-optimal.
2–56
Preliminary
Altera Corporation
October 2007
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Figure 2–14 shows the initial placement of a four-partition design with
floorplan location assignments made by the user, and the situation after
partition P3 is removed in this case.
Figure 2–14. Representation of Device Floorplan with Location Assignments
P2
P3
P1
Device Floorplan
With 4 Partitions
P2
P4
P1
P4
Device Floorplan
After Removing Changed Partition P3
This placement presents a much more reasonable task to the Fitter and
yields better results than the previous case that does not have floorplan
location assignments. Due to this effect, you should ensure that you have
a LogicLock floorplan assignment for any timing-critical blocks that will
be recompiled as you make changes to the design. You can use the
Reserved property to ensure that there are no placement conflicts in
bottom-up flows. Logic that is not timing-critical can float throughout the
device in a top-down compilation flow, so a floorplan assignment might
not be required in this case.
Creating Good Floorplan Location Assignments
This section presents recommendations for creating a design floorplan
using LogicLock regions.
In most cases, each LogicLock region should contain logic from only one
partition. This organization helps prevent resource conflicts in a bottomup design and can lead to better performance preservation when locking
down parts of a project in a top-down design. One exception to this rule
is the case where you want to have two lower-level partitions compiled
together in the same LogicLock region because of tight interaction, but
you want to separate the placement of the parent logic for each partition.
In this case, you can place more than one partition in one LogicLock
region, but for best results you must ensure that you recompile all
partitions every time the logic in one partition changes. In addition, if
your partition consists of a wrapper around more than one lower-level
Altera Corporation
October 2007
2–57
Preliminary
Quartus II Handbook, Volume 1
module, you can place those modules in different areas of the device by
using different LogicLock regions even if they are defined in the same
partition.
If your design contains hierarchical partitions (that is, parent-child
relationships between partitions), you can create hierarchical LogicLock
regions to ensure that the logic in the child partition is physically placed
inside the LogicLock region for the parent partition. This can be useful
when the parent partition does not contain registers at the boundary with
the lower-level child partition and has a lot of signal connectivity. To
create a hierarchical relationship between regions in the LogicLock
Regions window, drag and drop the child region to the parent region.
Ensure that all LogicLock regions in the design have a fixed size and have
their origin locked to a specific location on the chip. If you use auto-sized,
floating-location regions to create an initial floorplan, be sure to set the
size and origin to use the fitter results before you recompile. Do not use
the Soft LogicLock region property. Refer to “The Importance of
Floorplan Location Assignments in Incremental Compilation” on
page 2–55 for more information.
If resource utilization is low, you can enlarge the regions chosen by the
Fitter with the auto-size setting. Doing so usually improves the final
results because it gives the Fitter more freedom to place additional logic
added to the partition during future incremental compilations.
Ideally, almost the entire device should be covered by LogicLock regions
if all partitions are assigned to a region. Give more area to regions that are
densely populated, because overly congested regions can lead to poor
results. You may move the region origins from auto-floating region
placement to satisfy this requirement, but Altera recommends preserving
the Fitter-determined relative placement of the regions. Also, regions that
are too large for their logic can result in wasted resources and also lead to
poor results. You should define LogicLock regions that are neither too
small nor too large.
Regions should not overlap in the device floorplan, especially in
bottom-up flows. If two partitions are allocated an overlapping portion of
the chip, each may independently claim some common resources in this
region. This will lead to resource conflicts when importing bottom-up
results into a final top-level design.
If two LogicLock regions have several connections between them, place
them near each other to improve timing performance. By placing
connected regions near each other, the Fitter has more opportunity to
2–58
Preliminary
Altera Corporation
October 2007
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
optimize inter-region paths when both partitions are recompiled.
Reducing the criticality of inter-region paths also allows the Fitter more
flexibility when placing the other logic in each region.
You can use the Incremental Compilation Advisor to check that your
design follows many of these guidelines. Refer to “Incremental
Compilation Advisor” on page 2–60 for more details.
f
For more information about making and editing LogicLock regions, refer
to the Analyzing and Optimizing the Design Floorplan chapter in volume 2
of the Quartus II Handbook.
Excluding Certain Device Elements (such as RAM or DSP Blocks) with
Resource Exceptions
If your design contains memory or digital signal processing (DSP)
elements, you may want to exclude these elements from the LogicLock
region. You can use LogicLock resource exceptions to prevent elements
of certain types from being assigned to a region. Note that the filter does
not prevent them from being placed inside the region boundaries unless
the region’s Reserved property is turned on. Defining a resource
exception instructs the Fitter that certain blocks are not required to be
inside a region.
Resource exceptions are useful in cases where it is difficult to place
rectangular regions for design blocks that contain memory and DSP
elements, because of their placement in columns throughout the device
floorplan. Excluding these elements can help to resolve no-fit errors that
are caused by regions spanning too many resources, especially for
designs that are memory-intensive, DSP-intensive, or both. If desired,
you can also create separate regions for the memory or DSP blocks,
excluding logic cell resources, which can be shaped to accommodate the
columns in the device to control the placement of those design elements.
To view any resource exceptions, right-click in the LogicLock Regions
window and click Properties. In the LogicLock Region Properties dialog
box, highlight the design element (module/entity) in the Members box
and click Edit. To set up a resource exception, click the browse button
under Excluded element types, then turn on the design element types to
be excluded from the region. You can choose to exclude combinational
logic or registers from logic cells, or any of the sizes of TriMatrix™
memory blocks, or DSP blocks.
Altera Corporation
October 2007
2–59
Preliminary
Quartus II Handbook, Volume 1
Incremental Compilation Advisor
You can use the Incremental Compilation Advisor to check that your
design follows many of the recommendations presented in this chapter
for creating design partitions and floorplan location assignments. On the
Tools menu, point to Advisors, and click Incremental Compilation
Advisor.
As shown in Figure 2–15, recommendations are split into General
Recommendations that apply to all compilation flows and Bottom-Up
Design Recommendations that apply to bottom-up design
methodologies. Each recommendation provides an explanation,
describes the effect of the recommendation, and provides the action
required to make the suggested change. In some cases, there is a link to
the appropriate Quartus II settings page where you can make a suggested
change to assignments or settings.
Figure 2–15. Incremental Compilation Advisor
To check whether the design follows the recommendations, go to the
Timing Independent Recommendations page or the Timing
Dependent Recommendations page, and click Check
Recommendations. For large designs, these operations can take a few
minutes. After you perform a check operation, symbols appear next to
each recommendation to indicate whether the design or project setting
follows the recommendations, or if some or all of the design or project
settings do not follow the recommendations. Refer to the Legend on the
How to use the Incremental Compilation Advisor page in the advisor
for more information.
For some items in the Advisor, if your design does not follow the
recommendation, the Check Recommendations operation lists any parts
of the design that could be improved. For example, if not all of the
partition I/O ports follow the Register All Ports recommendation, the
advisor displays a list of unregistered ports with the partition name and
the source and destination nodes for the port.
2–60
Preliminary
Altera Corporation
October 2007
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
When the advisor provides a list of nodes, you can right-click on a node
and click Locate to cross-probe to other Quartus II features such as the
RTL Viewer, Chip Planner, or the design source code in the text editor.
1
The first time you open the RTL or Technology Map Viewer, a
preprocessor stage runs. This preprocessor resets the
Incremental Compilation Advisor, so you must rerun the Check
Recommendations process. Alternatively, you can open the
appropriate netlist viewer before you use the Incremental
Compilation Advisor if you want to locate nodes in the viewer.
Criteria for Successful Partition and Floorplan Schemes
The end results of design partitioning and floorplan creation differ from
design to design. However, it is important to evaluate your results to
ensure that your scheme is successful. Compare the results before
creating your floorplan location assignments to the results after doing so,
and consider using another scheme if any of the following guidelines are
not met:
■
■
■
No degradation in fMAX should be observed after the design is
partitioned and floorplan location assignments are created. In many
cases, a slight increase in fMAX is possible.
The area increase should be no more than 5% after the design is
partitioned and floorplan location assignments are created.
The time spent in the routing stage should not significantly increase.
The amount of compilation time spent in the routing stage is reported in
the Messages window with an Info message indicating the elapsed time
for Fitter routing operations. If you notice a dramatic increase in routing
time, the floorplan location assignments may be creating substantial
routing congestion. In this case, decrease the number of LogicLock
regions. Doing so typically reduces the compilation time in subsequent
incremental compilations, and may also improve design performance. To
help you modify your LogicLock regions, you can identify areas of
congested routing in your design using the Chip Planner. On the Tools
menu, click Chip Planner. To view the routing congestion, click the
Layers icon located next to the Task menu. Under Background Color
Map, select the Routing Utilization map.
Altera Corporation
October 2007
2–61
Preliminary
Quartus II Handbook, Volume 1
Recommended
Design Flows
and Compilation
Application
Examples
This section provides design flows for solving common timing closure
and team-based design issues using incremental compilation. Each flow
describes the situation in which it should be used, and gives a
step-by-step description of the commands required to implement the
flow. These examples are divided into the following two sections:
■
■
“Top-Down Incremental Design Flows”
“Bottom-Up Incremental Design Flows”
Top-Down Incremental Design Flows
There are four top-down incremental design flow examples that reduce
compilation time while making incremental changes to the design. The
following design flow examples also allow you to achieve timing closure
more quickly by optimizing or preserving the results for one partition in
a larger design:
■
■
■
■
“Design Flow 1—Changing a Source File for One of Multiple
Partitions in a Top-Down Compilation Flow”
“Design Flow 2—Optimizing the Placement for One of Multiple
Partitions in a Top-Down Compilation Flow” on page 2–63
“Design Flow 3—Preserving One Critical Partition in a MultiplePartition Design in a Top-Down Compilation Flow” on page 2–64
“Design Flow 4—Placing All but One Critical Partition in a
Multiple-Partition Design in a Top-Down Compilation Flow” on
page 2–65
All examples assume you have set up the project to use the full
incremental compilation flow, using the steps described in “Quick Start
Guide – Summary of Steps for an Incremental Compilation Flow” on
page 2–11.
Design Flow 1—Changing a Source File for One of Multiple Partitions in a
Top-Down Compilation Flow
Use this flow to update the source file in one partition without having to
recompile the other parts of the design. You can reduce the compilation
time by keeping the post-fit netlists for the unchanged partitions, while
also preserving the performance for these blocks to reduce additional
timing closure efforts.
Example background: You have just performed a lengthy, complete
compilation of a design that consists of multiple partitions. An error is
found in the HDL source file for one partition and it is being fixed.
Because the design is currently meeting timing requirements and the fix
is not expected to affect timing performance, it makes sense to compile
only the affected partition and preserve the rest of the design.
2–62
Preliminary
Altera Corporation
October 2007
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Perform the following steps to update the single source file:
1.
Apply and save the fix to the HDL source file.
2.
On the Assignments menu, click Design Partitions Window.
3.
For the partitions that should be preserved, change the Netlist Type
to Post-Fit. You can set the Fitter Preservation Level to either
Placement or Placement and Routing. For the partition that
contains the fix, you can change the netlist type to Source File.
Making the Source File setting is optional because the Quartus II
software recompiles partitions if changes are detected in a
source file.
4.
Click Start Compilation to incrementally compile the fixed HDL
code. This compilation should take much less time than the initial
full compilation.
5.
Run simulation again to ensure that the bug is fixed, and use the
Timing Analyzer report to ensure that timing results have not
degraded.
Design Flow 2—Optimizing the Placement for One of Multiple Partitions
in a Top-Down Compilation Flow
Use this flow when you want to optimize the results of one partition
when the other partitions in the design already meet their requirements.
Example background: You have just performed a lengthy full
compilation of a design that consists of multiple partitions. The Timing
Analyzer reports that the clock timing requirement is not met. After some
analysis, you believe that timing closure can be achieved if placement can
be improved for one particular partition. You have at least three
optimization techniques in mind: raising the Placement Effort Multiplier,
enabling Physical Synthesis, and running the Design Space Explorer.
Because these techniques all involve significant compilation time, it
makes sense to apply them (or just one of them) to only the partition in
question.
Perform the following steps to raise the Placement Effort Multiplier or
enable Physical Synthesis:
Altera Corporation
October 2007
1.
On the Assignments menu, click Design Partitions Window.
2.
For the partition in question, set the Netlist Type to Post-Synthesis.
This causes the partition to be placed and routed with the new Fitter
settings (but not resynthesized) during the next compilation.
2–63
Preliminary
Quartus II Handbook, Volume 1
3.
For the remaining partitions (including the top-level entity), set the
Netlist Type to Post-Fit. Set the Fitter Preservation Level to
Placement to allow for the most flexibility during routing. To
reduce compilation time further, use the Placement and Routing
setting. These partitions are preserved during the next compilation.
4.
Apply the desired optimization settings.
5.
Click Start Compilation to incrementally compile the design with
the new settings. During this compilation, the Partition Merge stage
automatically merges the post-synthesis netlist of the critical
partition with the post-fit netlists of the remaining partitions. This
“merged” netlist is fed to the Fitter. The Fitter then refits only one
partition. Since the effort is reduced as compared to the initial full
compilation, the compilation time is also reduced.
To use Design Space Explorer, perform the following steps:
1.
Repeat steps 1–3 of the previous set of steps.
2.
Save the project and run Design Space Explorer.
Design Flow 3—Preserving One Critical Partition in a Multiple-Partition
Design in a Top-Down Compilation Flow
Use this flow to optimize one partition by itself, and then lock the
placement to preserve its results while you complete the rest of your
design. For example, you can incorporate some IP that comes with
instructions to perform optimization before you incorporate the rest of
your custom logic.
Example background: Prior to any compilation, you have some insight
into which partition will be the most critical (in terms of timing) after
placement and routing. To help achieve timing closure, you decide to use
the following compilation flow.
The critical partition is placed and routed by itself, with all optimizations
turned on (manually or through Design Space Explorer). After timing
closure is achieved for this partition, its content and placement are
preserved and the remaining partitions are fit with normal or reduced
optimization levels so that the compilation time can be reduced.
1
This flow generally works only if the critical path is contained
inside the partition in question. This is one reason why both the
inputs and outputs of each partition should be registered.
To implement this design flow, perform the following steps:
2–64
Preliminary
Altera Corporation
October 2007
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
1.
Partition the design and create floorplan location assignments.
2.
For the partition expected to be critical, on the Assignments menu,
click Design Partitions Window and set Netlist Type to Source
File.
3.
For the remaining partitions (other than any direct or indirect
parents of the critical one), set the Netlist Type to Empty.
4.
Click Start Compilation to compile with the desired optimizations
turned on, or use Design Space Explorer.
5.
Check Timing Analyzer reports to ensure that timing requirements
are met. If so, proceed to step 6. Otherwise, repeat steps 4 and 5 until
the requirements are met.
6.
In the Design Partitions Window, set the Netlist Type to Post-Fit
for the critical partition. Set the Fitter Preservation Level to
Placement and Routing to preserve the results.
7.
Change the Netlist Type from Empty to Source File for the
remaining partitions.
8.
Turn off the optimizations set in step 4, and compile the design.
Turning off the optimizations at this point does not affect the fitted
partition, because its Netlist Type is set to Post-Fit.
9.
Check Timing Analyzer reports to ensure that timing requirements
are met. If not, make design or option changes and repeat step 8 and
step 9 until the requirements are met.
1
This flow is similar to a bottom-up design flow in which a
module is implemented separately and is merged into the
rest of the design afterwards. Refer to “Empty Partitions”
on page 2–26 for more information about potential issues.
Ensure that if there are any partitions representing a design
file that is missing from the project, you create a placeholder
wrapper file that defines the port interface.
Design Flow 4—Placing All but One Critical Partition in a
Multiple-Partition Design in a Top-Down Compilation Flow
Use this flow if you want to compile your design without one
timing-critical partition or a partition that requires a long compilation
time, and then preserve the rest of your design when you add the last
design block.
Altera Corporation
October 2007
2–65
Preliminary
Quartus II Handbook, Volume 1
Example background: Prior to any compilation, you have some insight
into which partition will be the most critical (in terms of timing) after
placement and routing. To help achieve timing closure, you decide to use
the following compilation flow.
Only the non-critical partitions are placed and routed initially, using
floorplan location assignments. These non-critical partitions are then
preserved when the critical partition is introduced into the Fitter, with
various optimizations turned on (manually or through Design Space
Explorer).
To implement this design flow, perform the following steps:
2–66
Preliminary
1.
Perform partitioning and floorplan creation.
2.
For the partition expected to be critical, on the Assignments menu,
click Design Partitions Window and set the Netlist Type to Empty.
3.
For the remaining partitions, set the Netlist Type to Source File.
4.
Click Start Compilation to compile the non-critical partitions.
5.
Check the Timing Analyzer report to ensure that the timing
requirements are met. If so, proceed to step 6. Otherwise, make
design or option changes and repeat steps 4 and 5 until the
requirements are met.
6.
In the Design Partitions Window, set the Netlist Type to Post-Fit
for the processed partitions. Set the Fitter Preservation Level to
Placement to allow for the most flexibility during routing.
7.
Change the Netlist Type from Empty to Source File for the
partition expected to be critical.
8.
Click Start Compilation to compile the design with optimizations
turned on, or use Design Space Explorer.
9.
Check the Timing Analyzer report to ensure that the timing
requirements are met. If not, make design or option changes and
repeat steps 8 and 9 until the requirements are met.
Altera Corporation
October 2007
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
1
This flow is similar to a bottom-up design flow, in which a
module is implemented separately and merged into the rest of
the design afterwards. Refer to “Empty Partitions” on page 2–26
for more information about potential issues. If there are any
partitions representing a design file that is missing from the
project, ensure that you create a placeholder wrapper file that
defines the port interface.
Bottom-Up Incremental Design Flows
This section contains the following three bottom-up design flow
examples to illustrate team-based design methodologies and IP reuse:
■
■
■
“Design Flow 5—Implementing a Team-Based Bottom-Up Design
Flow” on page 2–67
“Design Flow 6—Performing Design Iteration in a Bottom-Up
Design Flow” on page 2–71
“Design Flow 7—Creating Hard-Wired Macros for IP Reuse” on
page 2–73
Design Flow 5—Implementing a Team-Based Bottom-Up Design Flow
This example describes how to use incremental compilation in a
bottom-up design flow.
Example background: A project consists of several lower-level
subdesigns that are implemented separately by different designers. The
top-level project instantiates each of these subdesigns exactly once. The
subdesign designers want to optimize their designs independently and
pass on the results to the project lead.
As the project lead in this scenario, perform the following steps to prepare
the design for a successful bottom-up design methodology:
Altera Corporation
October 2007
1.
Create a new Quartus II project that will ultimately contain the full
implementation of the entire design.
2.
To prepare for the bottom-up methodology, create a “skeleton” of
the design that defines the hierarchy for the subdesigns that will be
implemented by separate designers. The top-level design
implements the top-level entity in the design and instantiates
wrapper files that represent each subdesign by defining only the
port interfaces but not the implementation.
2–67
Preliminary
Quartus II Handbook, Volume 1
3.
Make project-wide settings. Select the device, make global
assignments for clocks and device I/O ports, and make any global
signal constraints to specify which signals can use global routing
resources.
4.
Ensure that Full incremental compilation is turned on.
5.
Make design partition assignments for each subdesign and set the
Netlist Type for each design partition that will be imported to
Empty in the Design Partitions window.
6.
Create LogicLock regions for each of the lower-level partitions to
create a design floorplan. This floorplan should consider the
connectivity between partitions and estimates of the size of each
partition based on any initial implementation numbers and
knowledge of the design specifications.
7.
On the Project menu, click Generate Bottom-Up Design Partition
Scripts, or launch the script generator from Tcl or the command
prompt.
8.
Make any changes to the default script options as desired. Altera
recommends that you pass all the default constraints, including
LogicLock region, for all partitions and virtual pin location
assignments. Altera further recommends that you add a maximum
delay timing constraint for the virtual I/O connections in each
partition to help timing closure during integration at the top level. If
lower-level projects have not already been created by the other
designers, use the partition script to set up the projects so that you
can easily take advantage of makefiles.
9.
Provide each lower-level designer with the Tcl file to create their
project with the appropriate constraints. If you are using makefiles,
provide the makefile for each partition.
As the designer of a lower-level subdesign in this example, perform the
appropriate set of steps to successfully export your design, whether your
design team is using makefiles, or exporting and importing the design
manually.
2–68
Preliminary
Altera Corporation
October 2007
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
If you are using makefiles, perform the following steps:
1.
Use the make command and the makefile provided by the project
lead to create a Quartus II project with all design constraints, and
compile the project.
2.
The information about which source file should be associated with
which partition is not available to the software automatically, so
you must specify this information in the makefile. You must specify
the dependencies before the software will rebuild the project after
the initial call to the makefile.
3.
When you have achieved the desired compilation results and the
design is ready to be imported into the top-level design, the project
lead can use the master_makefile command to export this
lower-level partition and create a Quartus II Exported Partition file,
and then import it into the top-level design.
If you are not using makefiles, perform the following steps:
Altera Corporation
October 2007
1.
Create a new Quartus II project for the subdesign.
2.
Make LogicLock region assignments and global assignments
(including clock settings) as specified by the project lead.
3.
Make Virtual Pin assignments for ports which represent
connections to core logic instead of external device pins in the toplevel module.
4.
Make floorplan location assignments to the Virtual Pins so that they
are placed in their corresponding regions as determined by the
top-level module. This provides the Fitter with more information
about the timing constraints between modules. Alternatively, you
can apply timing I/O constraints to the paths that connect to virtual
pins.
5.
Ensure that Full incremental compilation is turned on and proceed
to compile and optimize the design as needed.
6.
When you have achieved the desired compilation results, on the
Project menu, click Export Design Partition. The Export Design
Partition dialog box appears.
2–69
Preliminary
Quartus II Handbook, Volume 1
7.
Under Netlist to export, select the netlist type Post-fit netlist to
preserve the placement and performance of the subdesign, and turn
on Export routing to include the routing information if required.
You can export Post-synthesis netlist instead if placement or
performance preservation is not required.
8.
Provide the Quartus II Exported Partition file to the project lead.
Finally, as the project lead in this example, perform the appropriate set of
steps to import the files sent in by the designers of each lower-level
subdesign partition.
If you are using makefiles, perform the following steps:
1.
Use the master_makefile command to export each lower-level
partition and create Quartus II Exported Partition files, and then
import them into the top-level design.
2.
The software does not have all the information about which source
files should be associated with which partition, so you must specify
this information in the makefile. The software cannot rebuild the
project if source files change unless you specify the dependencies.
If you are not using makefiles, perform the following steps:
1.
After you obtain the Quartus II Exported Partition file for each
subdesign from the other designers on the team, on the Project
menu, click Import Design Partition and specify the partition in the
top-level project that is represented by the subdesign Quartus II
Exported Partition file.
2.
Repeat the import process described in step 1 for each partition in
the design. After you have imported each partition once, select all
the design partitions and use the Reimport using latest import files
at previous locations option to import all of the files from their
previous locations at one time.
Resolving Assignment Conflicts During Import
When importing the subdesigns, the project lead may become aware of
some assignment conflicts. This can occur, for example, if the subdesign
designers changed their LogicLock regions to account for additional logic
or placement constraints, or if the designers applied I/O port timing
constraints that differ from constraints added to the top-level project by
the project lead. To address these conflicts, the project lead may want to
take one or both of the following actions:
■
2–70
Preliminary
Allow new assignments to be imported
Altera Corporation
October 2007
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
■
Allow existing assignments to be replaced or updated
When LogicLock region assignment conflicts occur, the project lead may
take one of the following actions:
■
■
■
Allow the imported region to replace the existing region
Allow the imported region to update the existing region
Skip assignment import for regions with conflicts
The project lead can address all of these situations using the Advanced
Import Settings as described in “Importing Assignments and Advanced
Import Settings” on page 2–37.
If the placement of different subdesigns conflict, the project lead can also
set the partition’s Fitter Preservation Level to Netlist Only, which allows
the software to re-perform placement and routing with the imported
netlist.
Importing a Partition to be Instantiated Multiple Times
In this variation of the scenario, one of the subdesigns is instantiated more
than once in the top-level design. The designer of the subdesign may
want to compile and optimize the entity once under a lower-level project,
and then import the results as multiple partitions in the top-level project.
In this case, placement conflict resolution as described in “Resolving
Assignment Conflicts During Import” is mandatory because the top-level
partitions share the same imported post-fit netlist. If you import multiple
instances of a subdesign in the top-level design, the imported LogicLock
regions are automatically set to Floating status.
If you choose to resolve conflicts manually, you can use the import
options and manual LogicLock assignments to specify the placement of
each instance in the top-level design.
Design Flow 6—Performing Design Iteration in a Bottom-Up Design Flow
Use this flow if you want to re-optimize lower-level partitions in a
bottom-up compilation by incorporating additional constraints from the
integrated top-level design.
Example background: A project consists of several lower-level
subdesigns that have been exported from separate Quartus II projects
and imported into the top-level design in a bottom-up compilation flow.
In this example, integration at the top level has failed because the timing
requirements are not met. The timing requirements are met in each
individual lower-level project, but critical inter-partition paths in the top
level are causing timing requirements to fail.
Altera Corporation
October 2007
2–71
Preliminary
Quartus II Handbook, Volume 1
After trying various optimizations at the top level, the project lead
determines that they cannot meet the timing requirements given the
current lower-level partition placements that were imported. The project
lead decides to pass additional constraints to the lower-level projects to
improve the placement.
To implement this design flow, perform the following steps:
1.
In the top-level design, on the Project menu, click Generate
Bottom-Up Design Partition Scripts, or launch the script generator
from Tcl or the command line.
2.
Because lower-level projects have already been created for each
partition, turn off Create lower-level project if one does not exist.
3.
Make any additional changes to the default script options as
desired. Altera recommends that you pass all the default
constraints, including LogicLock regions, for all partitions and
virtual pin location assignments. Altera also recommends that you
add a maximum delay timing constraint for the virtual I/O
connections in each partition.
4.
The Quartus II software generates Tcl scripts for all partitions, but in
this scenario, you would focus on the partitions that make up the
cross-partition critical paths. The following assignments are
important in the script:
●
●
●
5.
Virtual pin assignments for module pins not connected to device
I/O ports in the top-level design.
Location constraints for the virtual pins that reflect the initial
top-level placement of the pin’s source or destination. These
help make the lower-level placement “aware” of its
surroundings in the top-level, leading to a greater chance of
timing closure during integration at the top-level.
INPUT_MAX_DELAY and OUTPUT_MAX_DELAY timing
constraints on the paths to and from the I/O pins of the
partition. These constrain the pins to optimize the timing paths
to and from the pins.
The low-level designers source the file provided by the project lead.
●
To source the Tcl script from the Quartus II GUI, on the Tools
menu, click Utility Windows and open the Tcl console.
Navigate to the script’s directory, and type the following
command:
source <filename> r
2–72
Preliminary
Altera Corporation
October 2007
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
●
To source the Tcl script at the system command prompt, type the
following command:
quartus_cdb -t <filename>.tcl r
6.
The lower-level designers recompile their designs with the new
assignments.
7.
The lower-level designers re-export their results.
8.
The top-level designer re-imports the results.
9.
You can now analyze the design to determine if the timing
requirements have been achieved. Since the lower-level partitions
were compiled with more information about connectivity at the top
level, it is more likely that the inter-partition paths have improved
placement which helps to meet the timing requirements.
Design Flow 7—Creating Hard-Wired Macros for IP Reuse
Use this design flow to create a hard-wired macro or IP block that can be
instantiated in a top-level design. This flow provides the ability to export
a design block with placement (and optionally routing) information and
to import any number of copies of this pre-placed macro into another
design.
Example background: An IP provider wants to produce and sell an IP
core for a component to be used in higher-level systems. The IP provider
wants to optimize the placement of their block for maximum
performance in a specific Altera device and then pass on the placement
information to their end customer. To preserve their IP, they also prefer
to send a compiled netlist instead of providing the HDL source code to
their customer.
The customer first specifies what Altera device they are using for this
project and provides the design specifications.
As the IP provider in this example, perform the following steps to export
a preplaced IP core (or hard macro):
Altera Corporation
October 2007
1.
Create an HDL black box wrapper file that defines the port interface
for the IP core and provide the file to the customer to instantiate as
an empty partition in their top-level design.
2.
Create a Quartus II project for the IP core.
3.
Create a LogicLock region for the design hierarchy to be exported.
2–73
Preliminary
Quartus II Handbook, Volume 1
1
4.
Creating a floorplan using LogicLock regions is recommended
although not required for the generation and use of QXP files.
Using a LogicLock region for the IP core allows the customer to
create an empty placeholder region to reserve space for the IP in
their design floorplan. This ensures there are no conflicts with
the top-level design logic, and that the IP core will not affect the
timing performance of other logic in the top-level design.
LogicLock regions can be effective to reduce resource utilization
conflicts and to enable performance preservation. In addition,
without LogicLock regions, placement can be preserved only in
an absolute manner. With LogicLock regions, you can preserve
placement absolutely or relative to the origin of the associated
regions. This is important when a QXP file is imported for
multiple partition hierarchies in the same project, because in this
case the location of at least one instance in the top-level project
does not match the location used by the IP provider.
If required, add any logic (such as PLLs or other logic that will be
defined in the customer’s top-level design) around the design
hierarchy to be exported. If you do so, create a design partition for
the design hierarchy that is to be exported as an IP core.
For more information, refer to “Exporting a Lower-Level Block
within a Project” on page 2–35.
5.
Optimize the design and close timing to meet the design
specifications.
6.
Export the appropriate level of hierarchy into a single QXP file.
Following a successful compilation of the project, you can generate
a QXP file from the GUI, the command-line, or with Tcl commands:
●
●
●
7.
If you are using the Quartus II GUI, use the Export Design
Partition command.
If you are using command-line executables, run quartus_cdb
with the --incremental_compilation_export option.
If you are using Tcl commands, run the following command:
execute_flow -incremental_compilation_export.
Provide the QXP file to the customer. Note that you do not have to
send any of your design source code to the customer; the design
netlist as well as placement and routing information is contained
within this single file.
As the customer in this example, incorporate the IP core in your design
by performing the following steps:
2–74
Preliminary
Altera Corporation
October 2007
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
1.
Create a Quartus II project for the top-level design and instantiate a
copy or multiple copies of the IP core. Add the black box wrapper
file from the IP provider to your project to specify the entity name
and the port interface.
2.
On the Processing menu, point to Start and click Perform Analysis
& Elaboration to identify the design hierarchy.
3.
Create a design partition for each instance of the IP core (refer to
“Creating Design Partitions” on page 2–100) with the Netlist Type
set to Empty (refer to “Setting the Netlist Type for Design
Partitions” on page 2–22).
4.
You can now continue work on your part of the design and accept
the IP core from the IP provider whenever it is ready.
5.
Import the QXP file from the IP provider for the appropriate
partition hierarchy. You can import a QXP file from the GUI, the
command-line, or with Tcl commands.
●
●
●
6.
1
7.
If you are using the Quartus II GUI, use the Import Design
Partition command.
From the command-line, run quartus_cdb with the
--incremental_compilation_import option.
With Tcl commands, run the following command:
execute_flow -incremental_compilation_import.
You can set the imported LogicLock regions to floating or move
them to a new location, with the relative locations of the region
contents preserved. Routing information is preserved whenever
possible.
The Fitter ignores relative placement assignments if the
LogicLock region’s location in the top-level design is not
compatible with the locations exported in the QXP file.
You can control whether to preserve the imported netlist only,
placement, or placement and routing (if the placement or placement
and routing information was exported in the QXP file) with the
Fitter Preservation Level.
By default, the software preserves the absolute placement and
routing of all nodes in the imported netlist if you choose to preserve
placement and routing. However, if you use the same QXP files for
multiple partitions in the same project, the software preserves the
relative placement for each of the imported modules (relative to the
origin of the LogicLock region).
Altera Corporation
October 2007
2–75
Preliminary
Quartus II Handbook, Volume 1
1
Incremental
Compilation
Restrictions
If the IP provider did not define a LogicLock region in the
exported partition, the software preserves absolute placement
locations and this leads to placement conflicts if the partition is
imported for more than one instance.
This section documents the restrictions and limitations that you may
encounter when using incremental compilation, including interactions
with other Quartus II features. Some restrictions apply to both top-down
and bottom-up design flows, while some additional restrictions apply
only to bottom-up design flows.
The following restrictions and limitations are covered:
■
■
■
■
■
■
■
■
■
■
“Using Incremental Compilation with Quartus II Archive Files” on
page 2–77
“OpenCore Plus MegaCore Functions in Bottom-Up Flows” on
page 2–78
“SignalProbe Pins and Engineering Change Management with the
Chip Planner” on page 2–78
“SignalTap II Embedded Logic Analyzer in Bottom-Up Compilation
Flows” on page 2–80
“HardCopy Compilation Flows” on page 2–82
“Restrictions on Megafunction Partitions” on page 2–84
“Routing Preservation in Bottom-Up Compilation Flows” on
page 2–84
“Bottom-Up Design Partition Script Limitations” on page 2–84
“Register Packing and Partition Boundaries” on page 2–87
“I/O Register Packing” on page 2–87
Using Incremental Synthesis Only Instead of Full Incremental
Compilation
You can turn on incremental compilation for only the synthesis stage of
compilation to perform incremental synthesis, with no incremental
place-and-route. This mode is not recommended for new projects
because it is not compatible with certain Quartus II design flows, such as
formal verification and incremental SignalTap II verification.
To use incremental synthesis only, you can follow the steps for full
incremental compilation, but turn on the Incremental synthesis only
(Can reduce compilation time for a design with partition assignments)
option on the Incremental Compilation page under Compilation
Process Settings in the Settings dialog box.
2–76
Preliminary
Altera Corporation
October 2007
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
In this mode, the Fitter uses a flattened netlist without partition
boundaries, so the design is always replaced and rerouted. The difference
between this flow and the one shown in Figure 2–2 on page 2–7 is that the
partition merge stage does not accept post-fit netlists produced by the
Fitter, and the Fitter does not compile partitions separately. The following
differences exist in the impact of incremental synthesis only as compared
to full incremental compilation:
■
■
■
Compilation time reduction is limited to Quartus II integrated
synthesis.
You cannot preserve placement and routing, therefore the feature
does not preserve partition timing performance.
A partition is automatically resynthesized whenever you make a
change to the source code or any synthesis assignments (changes to
synthesis or fitting assignments do not trigger an automatic
recompilation with Full Incremental Compilation).
Preserving Exact Timing Performance
Timing performance might change slightly in the top-level design when
all partitions are incorporated due to differences between the separate
partitions and the full design. For example, there may be parasitic effects
or crosstalk that was not present in the initial compilation with only part
of the design. Additional fan-out on routing lines can also degrade timing
performance. To ensure that the design will meet performance when all
partitions are present, only approximately 2% margin is required. This
applies to both bottom-up and top-down methodologies. The Fitter
automatically works to achieve more than 2% margin when compiling
any design.
Using Incremental Compilation with Quartus II Archive Files
The post-synthesis and post-fitting netlist information for each design
partition is stored in the project database. When you archive a project, the
database information is not included in the archive unless you include the
database files in the Quartus II Archive file (.qar). In addition, when you
import a design partition into a top-level design, the lower-level design
netlist is stored in the project database for the top-level design (the
top-level project does not use the original source files or the Quartus II
Exported Partition file). If you archive the top-level project, the imported
design information is not included unless the database files are included
in the Quartus II Archive file.
Altera recommends that you turn on Include database from compilation
and simulation in the Archive Project dialog box if any form of
incremental compilation is used so that compilation results are
preserved.
Altera Corporation
October 2007
2–77
Preliminary
Quartus II Handbook, Volume 1
Formal Verification Support
You cannot use design partitions if you are creating a netlist for a formal
verification tool.
OpenCore Plus MegaCore Functions in Bottom-Up Flows
You can use OpenCore Plus MegaCore® functions in top-down
incremental compilation flows beginning with the Quartus II software
version 7.1. You cannot export partitions containing OpenCore Plus
MegaCore functions, so you cannot use OpenCore Plus functions in a
bottom-up design flow. Include any OpenCore IP functions in your
top-level Quartus II project.
Importing Encrypted IP Cores in Bottom-Up Flows
Proper license information is required to compile encrypted IP cores. The
license assignment is imported in to the top-level project when a design
is imported as a QXP file. However, the license assignment contains an
absolute path to the licensed IP source files. Therefore, the QXP file
usually works correctly only if imported into a top-level project on the
same computer as the lower-level project.
To avoid this problem, you can include this partition in the top-level
project instead of importing it, because IP cores generally do not require
additional changes by a designer in the project team. You can set the
partition that contains the core to Post-Fit after the first compilation to
reduce future compilation times, because the partition will not be
changing in any subsequent compilation. You can also set the partition to
Empty to exclude the IP core from the database until you are ready to
compile the entire design.
If you do want to import an encrypted IP core, copy the encrypted IP
source files to the top-level project's computer in exactly the same path
structure. For example, if the IP encrypted source file was
d:/work/my_encrypted_file.vhd, the top-level designer that imports the
QXP file must create the same folder and place the file in this location.
SignalProbe Pins and Engineering Change Management with the
Chip Planner
When you create SignalProbe pins or use the Resource Property Editor to
make changes due to engineering change orders (ECOs) after performing
a full compilation, recompiling the entire design is not necessary. These
changes are made directly to the netlist without performing a new
placement and routing. You can preserve these changes using a post-fit
2–78
Preliminary
Altera Corporation
October 2007
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
netlist with placement and routing. When a partition is recompiled,
SignalProbe pins and ECO changes in unaffected partitions are
preserved.
f
For more information about using the SignalProbe feature to debug your
design, refer to the Design Debugging Using the SignalTap II Embedded
Logic Analyzer chapter in volume 3 of the Quartus II Handbook. For more
information about using the Chip Planner and the Resource Property
Editor to make ECOs, refer to the Engineering Change Management with
the Chip Planner chapter in volume 2 of the Quartus II Handbook.
To preserve SignalProbe pins or ECO changes, the partitions must be set
to a Netlist Type of Post-fit with the Fitter Preservation Level set to
Placement and routing. If any partitions with SignalProbe pins or ECO
changes are set to post-fit without routing or to netlist only, the software
issues a warning and internally uses the post-fit netlist with placement
and routing. If the partitions are set to use the source code or a
post-synthesis netlist, the software issues a warning and the post-fit
SignalProbe pins or ECO changes are not included in the new
compilation. However, partitions can become linked due to the
SignalProbe pins or ECO changes, as described below, in which case all
linked partitions inherit the netlist type from the linked partition with the
highest level of preservation.
Linked Partitions Due to SignalProbe Pins or ECO Changes
If ECO changes affect more than one partition or the connection between
any partitions, the partitions become linked. All of the higher-level
“parent” partitions up to their nearest common parent are also linked. In
this case, the connection between the partitions is actually defined
outside of the two partitions immediately affected, so all the partitions
must be compiled together. All linked partitions use the same netlist type,
and they inherit the netlist type from the linked partition with the highest
level of preservation.
When a SignalProbe pin is created, it affects the partition that contains the
node being probed. In addition, any pipeline registers are created in the
same partition as the node being probed. The SignalProbe output pin is
assigned to the top-level partition. Therefore, there is a new connection
formed between the top-level partition and the lower-level partition that
is being probed. Because of this connection, the lower-level partition
being probed and all of the higher-level “parent” partitions up to the top
level become linked. All linked partitions use the same netlist type, and
they inherit the netlist type from the linked partition with the highest
level of preservation.
Altera Corporation
October 2007
2–79
Preliminary
Quartus II Handbook, Volume 1
When partitions are linked, they can change which netlists are preserved
when you recompile the design, as follows:
■
■
■
■
If all the linked partitions are set to use the source code or a
post-synthesis netlist, the partitions are refit as normal. In this case,
the SignalProbe pins or ECO changes are not included in the new
netlists, so you must reapply the changes in the Change Manager.
If any of the linked partitions is set to the Post-Fit netlist type, and
there are no source code changes, the software issues a warning and
internally uses the post-fit netlist with placement and routing for all
linked partitions. By preserving the appropriate post-fit netlists, the
software can preserve the SignalProbe pins or ECO changes.
If any of the linked partitions is set to the Post-Fit (Strict) netlist type,
the software issues a warning and internally uses the post-fit netlist
with placement and routing for all linked partitions, regardless of
any source code changes. By preserving the appropriate post-fit
netlists, the software can preserve the SignalProbe pins or ECO
changes. Note that in this case, source code changes in any of the
linked partitions are not included in the new netlist.
If any of the linked partitions is recompiled due to a change in source
code, the software issues a warning and recompiles the other linked
partition(s) as well. When this occurs, the SignalProbe pins or ECO
changes are not included in the new netlist, so you must reapply the
changes in the Change Manager.
Exported Partitions
In a bottom-up incremental compilation, the exported netlist includes all
currently saved SignalProbe pins and ECO changes. This might require
flattening and combining lower-level partitions in the child project to
avoid partition boundary violations at the top level. After importing this
netlist, changes made in the lower-level partition do not appear in the
Change Manager at the top level.
If you make any ECO changes that affect the interface to the lower-level
partition, the software issues a warning message during the export
process that this netlist will not work in the top-level design without
modifying the top-level HDL code to reflect the lower-level change.
SignalTap II Embedded Logic Analyzer in Bottom-Up
Compilation Flows
You can use the SignalTap® II Embedded Logic Analyzer in any project
that you can compile and program into an Altera device. You cannot
export a lower-level project that uses a SignalTap II File (.stp) for the
SignalTap II Logic Analyzer in a bottom-up incremental compilation
flow. You must disable the SignalTap II feature and recompile the design
2–80
Preliminary
Altera Corporation
October 2007
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
before you export the design as a partition. You can instantiate the
SignalTap II Megafunction directly in your lower-level design (instead of
using an .stp file) and export the design to the top level in a bottom-up
flow.
You can tap any nodes in a Quartus II project, including nodes imported
from other projects. Use the appropriate filter in the Node Finder to find
your node names. Use SignalTap II: post-fitting if the Netlist Type is
Post-Fit to incrementally tap node names in the post-fit netlist database.
Use SignalTap II: pre-synthesis if the Netlist Type is Source File to make
connections to the source file (pre-synthesis) node names when you
synthesize the partition from the source code.
f
For details about using the SignalTap II logic analyzer in an incremental
design flow, refer to the Design Debugging Using the SignalTap II Embedded
Logic Analyzer chapter in volume 3 of the Quartus II Handbook.
Logic Analyzer Interface in Bottom-Up Compilation Flows
You can use the Logic Analyzer Interface in any project that you can
compile and program into an Altera device. You cannot export a
lower-level project that uses the Logic Analyzer Interface in a bottom-up
incremental compilation flow. You must disable the Logic Analyzer
Interface feature and recompile the design before you export the design
as a partition.
f
For more information about the Logic Analyzer Interface, refer to the
In-System Debugging Using External Logic Analyzers chapter in volume 3
of the Quartus II Handbook.
Migrating Projects with Design Partitions to Different Devices
Partition assignments are still valid if you migrate to a different device
density or family. LogicLock region size is valid if you migrate to a device
in the same family, but the origin location is not valid. Specific floorplan
assignments are not valid for different devices or families because the
location coordinates change between devices.
Post-synthesis netlists are valid if you migrate to a different-sized device
in the same family. Post-fit netlists are not valid if you migrate to a
different device density or family.
Altera Corporation
October 2007
2–81
Preliminary
Quartus II Handbook, Volume 1
HardCopy Compilation Flows
HardCopy APEX and HardCopy Stratix Devices
Incremental compilation with the Quartus II software is not supported
for HardCopy APEX or HardCopy Stratix design flows.
HardCopy II Migration Flows
Top-down incremental compilation is supported for the base family in
HardCopy II migration flows for both the Stratix II first and HardCopy II
first flows. Design partitions are migrated to the companion device.
LogicLock regions are suggested for design partitions but are not
migrated to the companion device, due to the different device
architecture. However, you can not make changes to the design after
migration because the design would not match the compilation results for
the base family.
The Netlist only preservation level is not supported for Post-fit netlists for
Stratix II or HardCopy II device compilations when there is a migration
device set (that is, for HardCopy II device compilations with a Stratix II
migration device, or Stratix II device compilations with a HardCopy II
migration device).
Bottom-up incremental compilation is not supported in HardCopy II or
Stratix II device compilations when there is a migration device setting.
The Revision Compare feature requires that the HardCopy II and FPGA
netlists are the same. Therefore, all operations performed on one revision
must also occur on the other revision. This is accomplished by logging all
operations and replaying them on the other revision. Unfortunately,
using the bottom-up flow and importing partitions does not support this
requirement. You can often use a top-down flow with Empty partitions
to implement behavior similar to bottom-up flows.
HardCopy II Stand-Alone Compilations
You can use both top-down and bottom-up incremental compilation for
stand-alone HardCopy II compilations.
Routing preservation is not supported for HardCopy II devices.
Therefore, the Placement and Routing preservation level is not available,
and routing cannot be exported in the bottom-up flow.
2–82
Preliminary
Altera Corporation
October 2007
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Assignments Made in HDL Source Code in Bottom-Up Flows
Assignments made with I/O primitives or the altera_attribute
HDL synthesis attribute in lower-level partitions are not currently
honored at the top level in a bottom-up flow. The assignments are
processed at the top level, but cannot always be applied to the netlist
database after import. Fitter-related assignments (such as I/O
termination setting) can be applied correctly if you use a post-synthesis
QXP file.
Compilation Time with Physical Synthesis Optimizations
If Physical Synthesis is turned on, the optimizations run whenever there
is any partition placement that is not fixed with a post-fit netlist. For
example, when using the SignalTap II logic analyzer, there is an
automatic partition created for the SignalTap II instance which does not
have its placement preserved. Physical synthesis cannot make any
changes to partitions that are set to post-fit; however, it does still analyze
the netlist as whole. Therefore, the compilation time is not reduced as
much if physical synthesis optimizations are turned on.
You can set partitions to Empty to reduce compilation time if you want to
use physical synthesis for other partitions. You can go back to the Post-fit
netlist type directly from Empty, so the previous fitting results can be
reused when you want to include all partitions in the netlist. This method
works best if you assign each Empty partition to a LogicLock region with
the Reserved property, so that no other logic is placed in that region of the
device floorplan when the design is recompiled.
You can also turn off physical synthesis if you are recompiling a partition
which does not require physical synthesis optimizations. For example,
when using the SignalTap II Logic Analyzer on a design that has all
partitions using post-fit netlists, you can turn off physical synthesis to
reduce compilation time. You can also compile critical partitions that
require Physical Synthesis first, and close timing for those partitions. If
those partitions do not require any logic changes, you can set the critical
partitions to post-fit and then subsequent compilations can have physical
synthesis turned off. Be sure to turn the option on again if you make
design changes to timing-critical partitions and want to recompile the
new logic with physical synthesis optimizations.
Altera Corporation
October 2007
2–83
Preliminary
Quartus II Handbook, Volume 1
Restrictions on Megafunction Partitions
The Quartus II software does not support partitions for megafunction
instantiations. If you use the MegaWizard Plug-In Manager to customize
a megafunction variation, the MegaWizard-generated wrapper file
instantiates the megafunction. You can create a partition for the
MegaWizard-generated megafunction custom variation wrapper file.
The Quartus II software does not support the creation of a partition for
inferred megafunctions (that is, where the software infers a megafunction
to implement logic in your design). If you have a module or entity for the
logic that is inferred, you can create a partition for that hierarchy level in
the design.
The Quartus II software does not support creation of a partition for any
Quartus II internal hierarchy that is dynamically generated during
compilation to implement the contents of a megafunction.
Routing Preservation in Bottom-Up Compilation Flows
There are some cases in which routing information cannot be preserved
exactly, especially in bottom-up compilation, because of legality in the
device architecture. For example, when multiple partitions are imported,
there may be routing conflicts because you cannot pre-assign routing for
each lower-level block. In addition, if an imported LogicLock region is
moved in the top-level design, the relative placement of the nodes is
preserved but the routing may not be preserved.
Bottom-Up Design Partition Script Limitations
The Quartus II software has some limitations related to bottom-up design
partition scripts.
Synopsys Design Constraint (SDC) Files for the TimeQuest Timing
Analyzer
As described in “Importing Assignments and Advanced Import Settings”
on page 2–37, timing assignments made for the TimeQuest Timing
Analyzer in an SDC file are currently not imported into the top-level
project. You should manually ensure that the top-level project includes
all of the timing requirements for the entire project.
If you want to copy lower-level SDC files to the top-level project, consider
prefixing lower-level constraints with a variable that describes the
constraint’s location in the design hierarchy. Then, when you copy the file
to the top-level design, you can set the variable to provide the hierarchy
path to the lower-level partition in the top-level design.
2–84
Preliminary
Altera Corporation
October 2007
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Wildcard Support in Bottom-Up Design Partition Scripts
When applying constraints with wildcards, wildcards are not analyzed
across hierarchical boundaries. For example, an assignment could be
made to these nodes: Top|A:inst|B:inst|*, where A and B are
lower-level partitions, and hierarchy B is a child of A, that is B is
instantiated in hierarchy A. This assignment is applied to modules A, B
and all children instances of B. However, the assignment
Top|A:inst|B:inst* is applied to hierarchy A, but is not applied to the B
instances because the single level of hierarchy represented by B:inst* is
not expanded into multiple levels of hierarchy. To avoid this issue, ensure
that you apply the wildcard to the hierarchical boundary if it should
represent multiple levels of hierarchy.
When using the wildcard to represent a level of hierarchy, only single
wildcards are supported. This means assignments such as
Top|A:inst|*|B:inst|* are not supported. The Quartus II software
issues a warning in these cases.
Derived Clocks and PLLs in Bottom-Up Design Partition Scripts
If a clock in the top level is not directly connected to a pin of a lower-level
partition, then the lower-level partition does not receive assignments and
constraints from the top-level pin in the design partition scripts.
This issue is of particular importance for clock pins that require timing
constraints and clock group settings. Problems can occur if your design
uses logic or inversion to derive a new clock from a clock input pin. Make
appropriate timing assignments in your lower-level Quartus II project to
ensure that clocks are not unconstrained.
In addition, if you use a PLL in your top-level design and connect it to
lower-level partitions, the lower-level partitions do not have information
about the multiplication or phase shift factors in the PLL. Make
appropriate timing assignments in your lower-level Quartus II project to
ensure that clocks are not unconstrained or constrained with the incorrect
frequency. Alternately, you can manually duplicate the top-level derived
clock logic or PLL in the lower-level design file to ensure that you have
the correct multiplication or phase shift factors, compensation delays and
other PLL parameters for complete accurate timing analysis. Create a
design partition for the rest of the lower-level design logic that will be
exported to the top level. When the lower-level design is complete, export
just the partition that contains the relevant logic with the “Exporting a
Lower-Level Block within a Project” on page 2–35 feature.
Altera Corporation
October 2007
2–85
Preliminary
Quartus II Handbook, Volume 1
Virtual Pin Timing Assignments in Bottom-Up Design Partition Scripts
The design partition scripts use INPUT_MAX_DELAY and
OUTPUT_MAX_DELAY assignments to specify the inter-partition delays
associated with input and output pins which would not otherwise be
visible to the project. These assignments require that the software specify
the clock domain for the assignment, and the software sets this clock
domain to ‘*’.
This clock domain assignment means that there may be some paths
constrained and reported by the timing analysis engine that are not
required.
To restrict which clock domains are included in these assignments, edit
the generated scripts or change the assignments in your lower-level
Quartus II project. In addition, because there is no known clock
associated with the delay assignments, the software assumes the
worst-case skew, which makes the paths seem more timing critical than
they are in the top-level design. To make the paths appear less
timing-critical, lower the delay values from the scripts. If required, you
can also enter negative numbers for input and output delay values.
Top-Level Ports that Feed Multiple Lower-Level Pins in Bottom-Up
Design Partition Scripts
When a single top-level I/O port drives multiple pins on a lower-level
module, it unnecessarily restricts the quality of the synthesis and
placement at the lower-level. This occurs because in the lower-level
design, the software must maintain the hierarchical boundary and cannot
use any information about pins being logically equivalent at the top level.
In addition, because I/O constraints are passed from the top-level pin to
each of the children, it is possible to have more pins in the lower level
than at the top level, and these pins use the top-level I/O constraints and
placement options that might make them impossible to place at the
lower-level. The software avoids this situation whenever possible, but it
is best to avoid this design practice to avoid these potential problems.
Restructure your design so that the single I/O port feeds the design
partition boundary, and then the connection is split into multiple signals
within the lower-level partition.
2–86
Preliminary
Altera Corporation
October 2007
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Register Packing and Partition Boundaries
The Quartus II software automatically performs register packing during
compilation. However, when incremental compilation is enabled, logic in
different partitions cannot be packed together because partition
boundaries prevent cross-boundary optimization. (Refer to “Guidelines
for Creating Good Design Partitions and LogicLock Regions” on
page 2–46 for more information.) This restriction applies to all types of
register packing, including I/O cells, DSP blocks, sequential logic, and
unrelated logic.
I/O Register Packing
Cross-partition register packing of I/O registers is allowed in certain
cases where your input and output pins exist in the top hierarchy level
(and the Top partition), but the corresponding I/O registers exist in other
partitions.
The following specific circumstances are required for cross-partition
register packing of input pins:
■
■
The input pin feeds exactly one register
The path between the input pin and the register includes only input
ports of partitions that have one fan-out each
The following specific circumstances are required for cross-partition
register packing of output registers:
■
■
■
The register feeds exactly one output pin
The output pin is fed by only one signal
The path between the register and the output pin includes only
output ports of partitions that have one fan-out each
Output pins with an output enable signal cannot be packed into the
device I/O cell if the output enable logic is part of a different partition
from the output register. To allow register packing for output pins with
an output enable signal, structure your HDL code or design partition
assignments so that the register and the tri-state logic are defined in the
same partition.
Bidirectional pins are handled in the same way as output pins with an
output enable. If the registers that need to be packed are in the same
partition as the tri-state logic, then register packing can be performed.
Altera Corporation
October 2007
2–87
Preliminary
Quartus II Handbook, Volume 1
The restrictions on tri-state logic are due to the fact that the I/O atom
(device primitive) is created as part of the partition that contains the
tri-state logic. If an I/O register and its tri-state logic are contained in the
same partition, the register can always be packed with the tri-state logic
into the I/O atom. The same cross-partition register packing restrictions
also apply to I/O atoms for input and output pins. The I/O atom must
feed the I/O pin directly with exactly one signal and the path between the
I/O atom and the I/O pin must include only ports of partitions that have
one fan-out each.
Examples of I/O Register Packing Across Partition Boundaries
The following examples provide detailed explanations for various I/O
and partition configurations. The examples use BDF schematics to
illustrate the design logic.
Example 1—Output Register in Partition Feeding Output Pin
In this example, a subdesign contains a single register, as shown in
Figure 2–16. As shown in Figure 2–17, the top-level design instantiates
the subdesign with a single fan-out directly feeding an output pin, and
designates the subdesign as a separate design partition.
Figure 2–16. Subdesign with One Register, Designated as a Separate Partition
Figure 2–17. Top-level Design Instantiating the Subdesign in Figure 2–16 as an Output Register
The Quartus II software performs cross-partition register packing if there
is a Fast Output Register assignment on pin out. This type of
cross-partition output register packing is permitted because the port
interface of the subdesign partition does not need to be changed and the
partition port feeds an output pin directly.
2–88
Preliminary
Altera Corporation
October 2007
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Example 2—Output Register in Partition Feeding Multiple Output
Pins
In this example, a subdesign designated as a separate partition contains a
register as in Figure 2–16. The top-level design instantiates the subdesign
as an output register with more than one fan-out signal, as shown in
Figure 2–18.
Figure 2–18. Top-level Design Instantiating the Subdesign in Figure 2–16 with Two Output Pins
In this case, the software does not perform output register packing. If
there is a Fast Output Register assignment on pin out, the software issues
a warning that the Fitter can't pack the node to an I/O pin because the
node and the I/O cell are connected across a design partition boundary.
This kind of cross-partition register packing is not permitted because it
would require modification to the interface of the subdesign partition. In
order to perform incremental compilation, the interface of design
partitions must be preserved.
To allow the software to pack the register in the subdesign from
Figure 2–16 with the output pin out in Figure 2–18, make one of the
following changes:
■
■
■
Altera Corporation
October 2007
Remove the design partition assignment to the subdesign. This
allows the Fitter to perform all cross-hierarchy optimizations.
However, it prevents you from using incremental compilation for
this block of hierarchy. A good design partition should have a
well-defined interface so that the Fitter does not have to perform
cross-boundary optimizations.
Restructure your HDL code to place the register in the same partition
as the output pin. The simplest option is to move the register from
the subdesign partition into the partition containing the output pin.
This guarantees that the Fitter can optimize the two nodes without
violating any partition boundaries.
Restructure your HDL code so the register feeds only one output pin.
Turn off the Analysis and Synthesis setting Remove Duplicate
Registers. Duplicate the register in your subdesign HDL as in
2–89
Preliminary
Quartus II Handbook, Volume 1
Figure 2–19 so that each register feeds only one pin, then connect the
extra output pin to the new port in the top-level design as shown in
Figure 2–20. This converts the cross-partition register packing into
the simplest case where the register has a single fan-out.
Figure 2–19. Modified Subdesign from Figure 2–16 with Two Output Registers and Two Output Ports
Figure 2–20. Modified Top-Level Design from Figure 2–18 Connecting Two Output Ports to Output Pins
Example 3—Output Register, Output Enable Register and Tri-State
Logic in Partition Feeding Output Pin
In this example, a subdesign designated as a separate partition contains
an output register, an output enable register, and the tri-state logic to
drive the output pin, as shown in Figure 2–21. The top-level design
instantiates the subdesign with a single fan-out directly feeding an output
pin, as shown in Figure 2–22.
2–90
Preliminary
Altera Corporation
October 2007
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Figure 2–21. Subdesign with Output Register, Output Enable Register and Tri-State Logic, Designated as a
Separate Partition
Figure 2–22. Top-level Design Instantiating the Subdesign in Figure 2–21
The Quartus II software performs cross-partition register packing if there
is a Fast Output Register assignment, Fast Output Enable Register
assignment, or both, on pin out. This kind of cross-partition output
register packing is permitted because the port interface of the subdesign
partition does not need to be changed, no logic needs to be optimized
across the partition boundary, and the partition port feeds an output pin
directly.
Example 4—Output Register, Output Enable Register, or Both, in
Partition Feeding Tri-State Output Pin
In this example, a subdesign designated as a separate partition contains
two registers, as shown in Figure 2–23. The top-level design instantiates
the subdesign with the registers driving the output and the output enable
signal for an output pin, as shown in Figure 2–24.
Altera Corporation
October 2007
2–91
Preliminary
Quartus II Handbook, Volume 1
Figure 2–23. Subdesign with Two Registers, Designated as a Separate Partition
Figure 2–24. Top-level Design Instantiating the Subdesign in Figure 2–25 to Drive Output Enable Logic
In this case, the software cannot perform register packing. If there is a Fast
Output Register or Fast Output Enable Register assignment on pin out,
the software issues a warning that the Fitter cannot pack the node to an
I/O pin because the node and the I/O cell are connected across a design
partition boundary.
The same restrictions apply in the case that the top-level design includes
either the output register or the output enable register as well as the
tri-state logic. The software cannot pack the register that is part of the
subdesign partition into the I/O register.
This type of register packing is not permitted because it would require
moving logic across a design partition boundary to place into a single I/O
device atom. To perform register packing, either the registers must be
moved out of the subdesign partition or the tri-state logic must be moved
into the subdesign partition. In order to guarantee correctness of the
design with subsequent incremental compilations, the contents of design
partitions must be preserved.
2–92
Preliminary
Altera Corporation
October 2007
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
To allow the software to pack the output register, output enable register,
or both, in the subdesign from Figure 2–23 with the output pin out in
Figure 2–24, make one of the following changes:
■
■
■
Remove the design partition assignment to the subdesign. This
allows the Fitter to perform all cross-hierarchy optimizations.
However, it prevents you from using incremental compilation for
this block of hierarchy. A good design partition should have a
well-defined interface so that the Fitter does not need to perform
cross-boundary optimizations.
Restructure your HDL code to place the register in the same partition
as the output pin. The simplest option is to move the register from
the subdesign partition into the top-level partition containing the
output pin. This guarantees that the Fitter can optimize the two
nodes without violating any partition boundaries.
Restructure your HDL code so the register and the tri-state logic are
contained in the same partition. Move the tri-state logic from the
top-level block into the subdesign with both registers as shown in
Figure 2–21. Then connect the subdesign to an output pin in the
top-level design, as shown in Figure 2–22.
Example 5—Bidirectional Logic in Partition Feeding Bidirectional Pin
The behavior for bidirectional pins is similar to that of an output pin with
an output enable. To allow register packing, the registers must be
included in the same partition as the tri-state logic that drives the
bidirectional pin.
In this example, a subdesign designated as a separate partition contains
three registers and the tri-state logic for a bidirectional pin, as shown in
Figure 2–25. The top-level design instantiates the subdesign with ports
feeding bidirectional and output pins, as shown in Figure 2–26.
Altera Corporation
October 2007
2–93
Preliminary
Quartus II Handbook, Volume 1
Figure 2–25. Subdesign with Three Registers and Tri-State Logic, Designated as a Separate Partition
Figure 2–26. Top-level Design Instantiating the Subdesign in Figure 2–28
The Quartus II software performs cross-partition register packing if there
is a Fast Output Register, Fast Output Enable Register, or Fast Input
Register assignment on pin bidir. This type of cross-partition output
register packing is permitted because the port interface of the subdesign
partition does not need to be changed and the partition port feeds a
bidirectional pin directly.
Registers cannot be packed in designs that have the registers and tri-state
logic in different partitions. The situations described in “Example 4—
Output Register, Output Enable Register, or Both, in Partition Feeding
Tri-State Output Pin” on page 2–91 apply similarly to bidirectional pins if
you replace the output pin out with a bidirectional pin in the top-level
design.
2–94
Preliminary
Altera Corporation
October 2007
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Example 6—Input Register in Partition Fed by Input Pin
In this example, a subdesign contains a single register, as shown in
Figure 2–27. The top-level design instantiates the subdesign with a single
fanin directly fed by an input pin, as shown in Figure 2–28, and
designates the subdesign to be a separate design partition.
Figure 2–27. Subdesign with One Register, Designated as a Separate Partition
Figure 2–28. Top-level Design Instantiating the Subdesign in Figure 2–27 as an Input Register
The Quartus II software performs cross-partition register packing if there
is a Fast Input Register assignment on pin in. This type of cross-partition
output register packing is permitted because the port interface of the
subdesign partition does not have to be changed and the partition port is
fed by an input pin directly.
Example 7—Input Register in Partition Fed by Input with Multiple
Fan-Out
In this example, a subdesign designated as a separate partition contains a
register as in Figure 2–27. The top-level design instantiates the subdesign
as an input register but the input pin also feeds another destination, as
shown in Figure 2–29.
Altera Corporation
October 2007
2–95
Preliminary
Quartus II Handbook, Volume 1
Figure 2–29. Top-level Design Instantiating the Subdesign in Figure 2–27 as an Input Register for a Pin with
Two Destinations
In this case, the software does not perform input register packing. If there
is a Fast Input Register assignment on pin in, the software issues a
warning that the Fitter cannot pack the node to an I/O pin because the
node and the I/O cell are connected across a design partition boundary.
This type of cross-partition register packing is not permitted because it
would require modification to the interface of the subdesign partition. In
order to perform incremental compilation, the interface of design
partitions must be preserved.
To allow the software to pack the register in the subdesign from
Figure 2–27 with the input pin in in Figure 2–29, make one of the
following changes:
■
■
Remove the design partition assignment to the subdesign. This
allows the Fitter to perform all cross-hierarchy optimizations.
However, it also prevents you from using incremental compilation
for this block of hierarchy. A good design partition should have a
well-defined interface so that the Fitter does not have to perform
cross-boundary optimizations.
Restructure your HDL code to place the register in the same partition
as the input pin. The simplest option is to move the register from the
subdesign partition into the partition containing the input pin. This
guarantees that the Fitter can optimize the two nodes without
violating any partition boundaries.
Example 8—Inverted Input Register in Partition Fed by Input Pin
In this example, a subdesign designated as a separate partition contains
an inverted register as in Figure 2–30. The top-level design instantiates
the subdesign as an input register, as shown in Figure 2–31.
2–96
Preliminary
Altera Corporation
October 2007
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Figure 2–30. Subdesign with an Inverted Register, Designated as a Separate Partition
Figure 2–31. Top-level Design Instantiating the Subdesign in Figure 2–30 as an Input Register
The Quartus II software performs cross-partition register packing if there
is a Fast Input Register assignment on pin in. This kind of cross-partition
input register packing is permitted because the software can implement
the logic for the inversion with the input register inside the partition, and
then the partition port is fed by an input pin directly.
Example 9—Input Register in Partition Fed by Inverted Input Pin, or
Output Register in Partition Feeding Inverted Output Pin
In this example, a subdesign designated as a separate partition contains a
register as in Figure 2–32. The top-level design in Figure 2–33 instantiates
the subdesign as an input register with the input pin inverted. The
top-level design in Figure 2–34 instantiates the subdesign as an output
register with the signal inverted before feeding an output pin.
Figure 2–32. Subdesign with One Register, Designated as a Separate Partition
Altera Corporation
October 2007
2–97
Preliminary
Quartus II Handbook, Volume 1
Figure 2–33. Top-level Design Instantiating the Subdesign in Figure 2–32 as an Input Register with an
Inverted Input Pin
Figure 2–34. Top-level Design Instantiating the Subdesign in Figure 2–33 as an Output Register Feeding an
Inverted Output Pin
In these cases, the software does not perform register packing. If there is
a Fast Input Register assignment on pin in in Figure 2–33 or a Fast
Output Register assignment on pin out in Figure 2–34, the software
issues a warning that the Fitter cannot pack the node to an I/O pin
because the node and the I/O cell are connected across a design partition
boundary.
This type of register packing is not permitted because it would require
moving logic across a design partition boundary to place into a single I/O
device atom. To perform register packing, either the register must be
moved out of the subdesign partition or the inverter must be moved into
the subdesign partition to be implemented in the register. In order to
guarantee correctness of the design with subsequent incremental
compilations, the contents of design partitions must be preserved.
2–98
Preliminary
Altera Corporation
October 2007
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
To allow the software to pack the register in the subdesign from
Figure 2–32 with the input pin in in Figure 2–33 or the output pin out in
Figure 2–34, make one of the following changes:
■
■
■
Scripting
Support
Remove the design partition assignment from the subdesign. This
allows the Fitter to perform all cross-hierarchy optimizations.
However, it prevents you from using incremental compilation for
this block of hierarchy. A good design partition should have a
well-defined interface so that the Fitter does not have to perform
cross-boundary optimizations.
Restructure your HDL code to place the register in the same partition
as the pin. The simplest option is to move the register from the
subdesign partition into the top-level partition containing the pin.
This ensures that the Fitter can optimize the two nodes without
violating any partition boundaries.
Restructure your HDL code so the register and the inverter are
contained in the same partition. Move the inverter from the top-level
block into the subdesign as shown in Figure 2–30 for an input pin.
Then connect the subdesign to a pin in the top-level design, as shown
in Figure 2–31 for an input pin.
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 r
The Quartus II Scripting Reference Manual includes the same information
in PDF form.
f
For more information about Tcl scripting, refer to the Tcl Scripting
chapter in volume 2 of the Quartus II Handbook. Refer to the Quartus II
Settings File Reference Manual for information about all settings and
constraints in the Quartus II software. For more information about
command-line scripting, refer to the Command-Line Scripting chapter in
volume 2 of the Quartus II Handbook.
Generate Incremental Compilation Tcl Script Command
To create a template Tcl script for full incremental compilation, use the
Generate Incremental Compilation Tcl Script feature. Right-click in the
Design Partitions Window and click Generate Incremental
Compilation Tcl Script.
Altera Corporation
October 2007
2–99
Preliminary
Quartus II Handbook, Volume 1
If you have made any partition assignments in the user interface, this
script contains the Tcl equivalents of the assignments. The Tcl
assignments are described in the following sections.
Preparing a Design for Incremental Compilation
To set or modify the current mode of incremental compilation, use the
following command:
set_global_assignment -name INCREMENTAL_COMPILATION \
<value>
The incremental compilation <value> setting must be one of the following
values:
■
■
■
FULL_INCREMENTAL_COMPILATION—Full incremental
compilation (this is the default)
INCREMENTAL_SYNTHESIS—Incremental synthesis only
OFF—No incremental compilation is performed
Creating Design Partitions
To create a partition, use the following command:
set_instance_assignment -name PARTITION_HIERARCHY \
<file name> -to <destination> -section_id <partition name>
The <destination> should be the entity’s short hierarchy path. A short
hierarchy path is the full hierarchy path without the top-level name
(including quotation marks), for example:
"ram:ram_unit|altsyncram:altsyncram_component"
For the top-level partition, you can use the pipe (|) symbol to represent
the top-level entity.
f
For more information about hierarchical naming conventions, refer to
Node-Naming Conventions in Quartus II Integrated Synthesis in the
Quartus II Integrated Synthesis chapter in volume 1 of the Quartus II
Handbook.
The <partition name> is the user-designated partition name, which must
be unique and less than 1024 characters. The name can consist only of
alphanumeric characters, and the pipe ( | ), colon ( : ), and underscore
( _ ) characters. Altera recommends enclosing the name in double
quotation marks (" ").
2–100
Preliminary
Altera Corporation
October 2007
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
The <file name> is the name used for internally generated netlists files
during incremental compilation. Netlists are named automatically by the
Quartus II software based on the instance name if you create the partition
in the user interface. If you are using Tcl to create your partitions, you
must assign a custom file name that is unique across all partitions. For the
top-level partition, the specified file name is ignored, and you can use any
dummy value. To ensure the names are safe and platform independent,
file names must be unique regardless of case. For example, if a partition
uses the file name my_file, no other partition can use the file name
MY_FILE. For simplicity, Altera recommends that you base each file
name on the corresponding instance name for the partition.
The software stores all netlists in the \db compilation database directory.
Setting Properties of Design Partitions
After a partition is created, set its Netlist Type with the following
command:
set_global_assignment -name PARTITION_NETLIST_TYPE <value> -section_id \
<partition name>
The netlist type <value> setting is one of the following values:
■
■
■
■
■
■
■
SOURCE—Source File
POST_SYNTH—Post-Synthesis
POST_FIT—Post-Fit
STRICT_POST_FIT—Post-Fit (Strict)
IMPORTED—Imported
IMPORT_BASED_POST_FIT—Post-Fit (Import-based)
EMPTY—Empty
Set the Fitter Preservation Level for a post-fit or imported netlist using the
following command:
set_global_assignment -name PARTITION_FITTER_PRESERVATION_LEVEL <value> \
-section_id <partition name>
The Fitter Preservation Level <value> setting is one of the following
values:
■
■
■
■
Altera Corporation
October 2007
NETLIST_ONLY—Netlist only
PLACEMENT—Placement
PLACEMENT_AND_ROUTING—Placement and routing
PLACEMENT_AND_ROUTING_AND_TILE— Placement and routing,
as well as the power tile setting of high-speed or low-power
2–101
Preliminary
Quartus II Handbook, Volume 1
For details about these partition properties, refer to “Setting Properties of
Design Partitions”.
Creating Good Floorplan Location Assignments—Excluding or
Filtering Certain Device Elements (Such as RAM or DSP Blocks)
Resource filtering uses the optional Tcl argument
-exclude_resources in the set_logiclock_contents function of
the LogicLock Tcl package. If left unspecified, no resource filter is created.
The argument takes a list of resources-to-be-excluded as input. The list is
a colon-delimited string of the following keywords:
Table 2–4. Resources-to-be-Excluded Keywords
Keyword
Resource
REGISTER
Any registers in the logic cells
COMBINATIONAL
Any combinational elements in the logic cells
SMALL_MEM
The small TriMatrix memory blocks (M512 or MLAB)
MEDIUM_MEM
The medium TriMatrix memory blocks (M4K or M9K)
LARGE_MEM
The large TriMatrix memory blocks (M-RAM or M144K)
DSP
Any DSP blocks
VIRTUAL_PIN
Any virtual pins
For example, the following command assigns everything under
alu:alu_unit to the ALU region, excluding all the DSP and M512 blocks:
set_logiclock_contents -region ALU -to alu:alu_unit -exceptions \
"DSP:SMALL_MEM"
In the QSF, resource filtering uses an extra LogicLock membership
assignment called LL_MEMBER_RESOURCE_EXCLUDE. For example, the
following line in the QSF is used to specify a resource filter for the
alu:alu_unit entity assigned to the ALU region. The value of the
assignment takes the same format as the resource listing string taken by
the previous Tcl command.
set_instance_assignment -name LL_MEMBER_RESOURCE_EXCLUDE "DSP:SMALL_MEM" \
-to "alu:alu_unit" -section_id ALU
2–102
Preliminary
Altera Corporation
October 2007
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Generating Bottom-Up Design Partition Scripts
To generate scripts, type the following Tcl command at a Tcl prompt:
generate_bottom_up_scripts <options> r
The command is part of the database_manager package, which must
be loaded using the following command before the command can be
used:
load_package database_manager
You must open a project before you can generate scripts.
The Tcl options are the same as those available in the GUI. The exact
format of each option is specified in Table 2–5.
Table 2–5. Options for Generating Bottom-Up Partition Scripts with Tcl Commands
Option
Default
-include_makefiles <on|off>
On
-include_project_creation <on|off>
On
-include_virtual_pins <on|off>
On
-include_virtual_pin_timing <on|off>
On
-include_virtual_pin_locations <on|off>
On
-include_logiclock_regions <on|off>
On
-include_all_logiclock_regions <on|off>
On
-include_global_signal_promotion <on|off>
Off
-include_pin_locations <on|off>
On
-include_timing_assignments <on|off>
On
-include_design_partitions <on|off>
On
-remove_existing_regions <on|off>
On
-disable_auto_global_promotion <on|off>
Off
-bottom_up_scripts_output_directory <output directory>
-virtual_pin_delay <delay in ns>
Current project directory
(1)
Note to Table 2–5:
(1)
No default.
The following example shows how to use the Tcl command:
load_package database_manager
set project test_proj
Altera Corporation
October 2007
2–103
Preliminary
Quartus II Handbook, Volume 1
project_open $project
generate_bottom_up_scripts -bottom_up_scripts_output_directory test \
-include_virtual_pin_timing on -virtual_pin_delay 1.2
project_close
Command Line Support
To generate scripts at the command prompt, type the following
command:
quartus_cdb <project name> --generate_bottom_up_scripts=on <options> r
Once again, the options map to the same as those in the GUI. To add an
option, append “--<option_name>=<val>” to the command line call.
The command prompt options are the same as those available in the GUI.
They are listed in Table 2–6.
Table 2–6. Options for Generating Bottom-Up Partition Scripts
Option
Default
--include_makefiles_with_bottom_up_scripts=<on|off>
On
--include_project_creation_in_bottom_up_scripts=<on|off>
On
--include_virtual_pins_in_bottom_up_scripts=<on|off>
On
--include_virtual_pin_timing_in_bottom_up_scripts=<on|off>
On
--bottom_up_scripts_virtual_pin_delay=<delay in ns>
(1)
--include_virtual_pin_locations_in_bottom_up_scripts=<on|off>
On
--include_logiclock_regions_in_bottom_up_scripts=<on|off>
On
--include_all_logiclock_regions_in_bottom_up_scripts=<on|off>
On
--include_global_signal_promotion_in_bottom_up_scripts=<on|off>
Off
--include_pin_locations_in_bottom_up_scripts=<on|off>
On
--include_timing_assignments_in_bottom_up_scripts=<on|off>
On
--include_design_partitions_in_bottom_up_scripts=<on|off>
On
--remove_existing_regions_in_bottom_up_scripts=<on|off>
On
--disable_auto_global_promotion_in_bottom_up_scripts=<on|off>
--bottom_up_scripts_output_directory=<output directory>
Off
Current project
directory
Note to Table 2–6:
(1)
No default. You must provide this option if you are including virtual pin timing.
2–104
Preliminary
Altera Corporation
October 2007
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Exporting a Partition to be Used in a Top-Level Project
Use the quartus_cdb executable to export a file for a bottom-up
incremental compilation flow with the following command:
quartus_cdb --INCREMENTAL_COMPILATION_EXPORT=<file> \
[--incremental_compilation_export_netlist_type=<POST_SYNTH|POST_FIT>] \
[--incremental_compilation_export_partition_name=<partition name>] \
[--incremental_compilation_export_routing=<on|off>]
The <file> argument is the file path to the exported file. The
<partition name> is the name of the partition, not its hierarchical path. If
you do not specify the options, the executable uses any settings in the QSF
file, or otherwise uses the default values. The default partition is the
top-level partition in the project, the default netlist type is post-fit, and the
default for routing is on (for all device families that support exported
routing).
The command reads the assignment
INCREMENTAL_COMPILATION_EXPORT_NETLIST_TYPE to determine
which netlist type to export; the default is post-fit.
You can also use the flow INCREMENTAL_COMPILATION_EXPORT in the
execute_flow Tcl command contained in the flow Tcl package.
Use the following commands to export a QXP file for a given partition,
choose the netlist type, and specify whether to export routing.
load_package flow
set_global_assignment –name INCREMENTAL_COMPILATION_EXPORT_FILE <filename>
set_global_assignment –name INCREMENTAL_COMPILATION_EXPORT_NETLIST_TYPE \
<POST_FIT|POST_SYNTH>
set_global_assignment -name \
INCREMENTAL_COMPILATION_EXPORT_PARTITION_NAME <partition name>
set_global_assignment -name INCREMENTAL_COMPILATION_EXPORT_ROUTING \
<on|off>
execute_flow –INCREMENTAL_COMPILATION_EXPORT
The default partition is the top-level partition in the project, the default
netlist type is post-fit, and the default for routing is on (for all device
families that support exported routing).
To turn on the option to always perform exportation following
compilation, use the following Tcl command:
set_global_assignment -name AUTO_EXPORT_INCREMENTAL_COMPILATION ON
Altera Corporation
October 2007
2–105
Preliminary
Quartus II Handbook, Volume 1
Importing a Lower-Level Partition into the Top-Level Project
Use the quartus_cdb executable to import a lower-level partition with
the following command:
quartus_cdb -- INCREMENTAL_COMPILATION_IMPORT r
You can also use the flow called INCREMENTAL_COMPILATION_IMPORT
in the execute_flow Tcl command contained in the flow Tcl package.
The following example script shows how to import a partition using a Tcl
script:
load_package flow
# commands to set the import-related assignments for each partition
execute_flow --INCREMENTAL_COMPILATION_IMPORT
Specify the location for the imported file with the
PARTITION_IMPORT_FILE assignment. Note that the file specified by
this assignment is read only during importation. For example, the project
is completely independent from any files from the lower-level projects
after importing. In the command-line and Tcl flow, any partition that has
this assignment set to a non-empty value will be imported.
The following assignments specify how the partition should be imported:
PARTITION_IMPORT_PROMOTE_ASSIGNMENTS = on | off
PARTITION_IMPORT_NEW_ASSIGNMENTS = on | off
PARTITION_IMPORT_EXISTING_ASSIGNMENTS = \
replace_conflicting | skip_conflicting
PARTITION_IMPORT_EXISTING_LOGICLOCK_REGIONS = \
replace_conflicting | update_conflicting | skip_conflicting
Makefiles
For an example of how to use incremental compilation with a
makefile as part of the bottom-up design flow, refer to the read_me.txt
file that accompanies the incr_comp example located in the
/qdesigns/incr_comp_makefile subdirectory. When using a bottom-up
incremental compilation flow, the Generate Bottom-Up Design Partition
Scripts feature can write makefiles that automatically export lower-level
design partitions and import them into the top-level project whenever
design files change.
2–106
Preliminary
Altera Corporation
October 2007
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Recommended Design Flows and Compilation Application
Examples
This section provides scripting examples that cover some of the topics
discussed in the main section of the chapter.
The script shown in Example 2–1 opens a project called AB_project,
sets up two partitions, entities A and B, for the first time, and performs an
initial complete compilation.
Example 2–1. AB_project
set project AB_project
package require ::quartus::flow
project_open $project
# Ensure that incremental compilation is turned on
set_global_assignment -name INCREMENTAL_COMPILATION \
FULL_INCREMENTAL_COMPILATION
# Set up the partitions
set_instance_assignment -name PARTITION_HIERARCHY \
db/A_inst -to A –section_id "Partition_A"
set_instance_assignment -name PARTITION_HIERARCHY \
db/B_inst -to B –section_id "Partition_B"
# Set the netlist types to post-fit for subsequent
# compilations (all partitions are compiled during the
# initial compilation since there are no post-fit
# netlists)
set_global_assignment –name PARTITION_NETLIST_TYPE \
POST_FIT –section_id "Partition_A"
set_global_assignment –name PARTITION_NETLIST_TYPE \
POST_FIT –section_id "Partition_B"
# Run initial compilation:
export_assignments
execute_flow -full_compile
project_close
Design Flow 1—Changing a Source File for One of Multiple Partitions in a
Top-Down Compilation Flow
Example background: You have run the initial compilation shown in the
example script under “Recommended Design Flows and Compilation
Application Examples” on page 2–62. You have modified the HDL source
file for partition A, and would like to recompile it.
Altera Corporation
October 2007
2–107
Preliminary
Quartus II Handbook, Volume 1
Run the standard flow compilation command in your Tcl script:
execute_flow –full_compile
Or, run the following command at a system command prompt:
quartus_sh --flow compile AB_projectr
Assuming the source files for partition B do not depend on A, only A is
recompiled. The placement of B and its timing performance is preserved,
which also saves significant compilation time.
Design Flow 2—Optimizing the Placement for One of Multiple Partitions
in a Top-Down Compilation Flow
Example background: You have run the initial compilation shown in the
example script under “Recommended Design Flows and Compilation
Application Examples” on page 2–62. You would like to apply Fitter
optimizations, such as physical synthesis, only to partition A. No changes
have been made to the HDL files.
To ensure the previous compilation result for partition B is preserved,
and to ensure that Fitter optimizations are applied to the post-synthesis
netlist of partition A, set the netlist type of B to Post-Fit (which was
already done in the initial compilation, but is repeated here for safety),
and the netlist type of A to Post-Synthesis, as shown in the following
script:
2–108
Preliminary
Altera Corporation
October 2007
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
set project AB_project
package require ::quartus::flow
project_open $project
# Turn on Physical Synthesis Optimization
set_global_assignment -name \
PHYSICAL_SYNTHESIS_REGISTER_RETIMING ON
# For A, set the netlist type to post-synthesis
set_global_assignment –name PARTITION_NETLIST_TYPE POST_SYNTH \
–section_id "Partition_A"
# For B, set the netlist type to post-fit
set_global_assignment –name PARTITION_NETLIST_TYPE POST_FIT \
–section_id "Partition_B"
# Run incremental compilation:
export_assignments
execute_flow -full_compile
project_close
Conclusion
With the Quartus II incremental compilation feature described in this
chapter, you can preserve the results and the performance of unchanged
logic in your design as you make changes elsewhere. The various
applications of incremental compilation enable you to improve your
productivity while designing for high-density FPGAs, using either
top-down or bottom-up design methodologies.
Referenced
Documents
This chapter references the following documents:
■
■
■
■
■
■
■
■
Altera Corporation
October 2007
Analyzing and Optimizing the Design Floorplan chapter in volume 2 of
the Quartus II Handbook
Area and Timing Optimization chapter in volume 2 of the Quartus II
Handbook
Command-Line Scripting chapter in volume 2 of the Quartus II
Handbook
Design Debugging Using the SignalTap II Embedded Logic Analyzer
chapter in volume 3 of the Quartus II Handbook
Engineering Change Management with the Chip Planner chapter in
volume 2 of the Quartus II Handbook
Introduction to Quartus II Manual
In-System Debugging Using External Logic Analyzers chapter in
volume 3 of the Quartus II Handbook
Quartus II Classic Timing Analyzer chapter in volume 3 of the
Quartus II Handbook
2–109
Preliminary
Quartus II Handbook, Volume 1
■
■
■
■
■
■
2–110
Preliminary
Quartus II Integrated Synthesis chapter in volume 1 of the Quartus II
Handbook
Quartus II Settings File Reference Manual
Quartus II TimeQuest Timing Analyzer chapter in volume 3 of the
Quartus II Handbook
Switching to the TimeQuest Timing Analyzer chapter in volume 3 of the
Quartus II Handbook
Synthesis section in volume 1 of the Quartus II Handbook
Tcl Scripting chapter in volume 2 of the Quartus II Handbook
Altera Corporation
October 2007
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
Document
Revision History
Table 2–7 shows the revision history for this chapter.
Table 2–7. Document Revision History (Part 1 of 2)
Date and
Document Version
October 2007
v7.2.0
Changes Made
●
●
●
●
●
●
●
●
●
May 2007
v7.1.0
●
●
●
●
●
●
●
●
●
March 2007
v7.0.0
Altera Corporation
October 2007
Summary of Changes
Updated for Quartus II
Updated “Introduction” on page 2–1.
software version 7.2.
Updated “Choosing a Quartus II Compilation Flow” on
page 2–3.
Changed title and updated “Preparing a Design for
Incremental Compilation” section to “Quick Start Guide –
Summary of Steps for an Incremental Compilation Flow” on
page 2–11.
Updated “Design Partition Assignments Compared to
Physical Placement Assignments” on page 2–18.
Updated “Creating Design Partitions” on page 2–19.
Updated “Creating a Design Floorplan With LogicLock
Location Assignments” on page 2–29.
Updated “Exporting and Importing Partitions for Bottom-Up
Design Flows” on page 2–32.
Updated “Guidelines for Creating Good Design Partitions and
LogicLock Regions” on page 2–46.
Updated “Incremental Compilation Restrictions” on
page 2–76.
Updated “Choosing a Quartus II Compilation Flow” on
page 2–3.Updated “Preparing a Design for Incremental
Compilation” on page 2–10.
Updated Tables 2–1 and 2–3.
Updated design in “Recommended Design Flows and
Compilation Application Examples” on page 2–61.
Added new examples to “Design Flow 7—Creating HardWired Macros for IP Reuse” on page 2–72.
Moved and simplified “Using Incremental Synthesis Only
Instead of Full Incremental Compilation” on page 2–76.
Updated “HardCopy Compilation Flows” on page 2–81.
Updated “Support for the TimeQuest Timing Analyzer and
SDC Constraints” on page 2–81.
Updated “Setting Properties of Design Partitions” on
page 2–98.
Added “Referenced Documents” on page 2–106.
No changes to chapter.
Removed several
dialog box figures.
Added support for
Arria GX devices.
Added Fitter
Preservation Level
Post-Fit Placement,
Routing, and Tiles.
—
2–111
Preliminary
Quartus II Handbook, Volume 1
Table 2–7. Document Revision History (Part 2 of 2)
Date and
Document Version
Changes Made
Summary of Changes
November 2006
v6.1.0
Chapter 2 was formerly Chapter 1 in version 6.0.0.
Reorganized chapter to group recommendations and guidelines
together.
Updated for the Quartus II software version 6.1:
● Added support for Stratix III devices.
● Added information on the Incremental Compilation Advisor.
● The full incremental compilation option is now turned on by
default.
● Added new feature for Exporting a Lower-Level Block within
a Project.
● Changed the location of the Automatically export design
partition after compilation option.
● Added support for HardCopy Compilation Flows.
● Added that routing can be exported in bottom-up flows.
● Added I/O port guidelines in Creating Good Design Partitions.
● Updated limitations: SignalProbe Pins and Engineering
Change Management with the Chip Planner.
Added support for
Stratix III devices.
Added information
about new features and
updates in the
Quartus II software
version 6.1.
May 2006
v6.0.0
Name changed to Quartus II Incremental Compilation for
Hierarchical and Team-Based Design.
Updated for the Quartus II software version 6.0.
● Added new device support information.
● Added top-down and bottom-up design flow information.
● Added incremental compilation design compiling information.
● Added recommendations for creating good floorplan location
assignments.
● Added register packing and partition boundary information.
● Added engineering management with the Chip Editor.
● Added information on how to check and save to reapply
SignalProbe.
● Added user scenarios.
—
December 2005
v5.1.1
Minor typographic update.
—
October 2005
v5.1.0
Updated for the Quartus II software version 5.1.
—
August 2005
v5.0.1
Added documentation on cross-partition register packing.
—
May 2005
v5.0.0
Initial release.
—
2–112
Preliminary
Altera Corporation
October 2007
3. Quartus II Design Flow for
MAX+PLUS II Users
QII51002-7.2.0
Introduction
The feature-rich Quartus® II software helps you shorten your design
cycles and reduce time-to-market. With support for FLEX®, ACEX®, and
MAX® device families, as well as all of Altera®’s newest devices, the
Quartus II software is the most widely accepted Altera design software
tool today.
This chapter describes how to convert MAX+PLUS® II designs to
Quartus II projects, as well as the similarities and differences between the
MAX+PLUS II and Quartus II design flows. This discussion includes
supported device families, graphical user interface (GUI) comparisons,
and the advantages of the Quartus II software.
There are many features in the Quartus II software to help MAX+PLUS II
users easily transition to the Quartus II software design environment.
These include a customizable Look & Feel feature, which changes the
GUI to display menus, toolbars, and utility windows as they appear in the
MAX+PLUS II software without sacrificing Quartus II software
functionality.
Chapter
Overview
Altera Corporation
October 2007
This chapter covers the following topics:
■
■
■
■
■
■
■
■
“Typical Design Flow” on page 3–2
“Device Support” on page 3–3
“Quartus II GUI Overview” on page 3–4
“Setting Up MAX+PLUS II Look and Feel in Quartus II” on page 3–6
“Compiler Tool” on page 3–9
“MAX+PLUS II Design Conversion” on page 3–12
“Quartus II Design Flow” on page 3–15
“Quick Menu Reference” on page 3–35
3–1
Quartus II Handbook, Volume 1
Typical Design
Flow
Figure 3–1 shows a typical design flow with the Quartus II software.
Figure 3–1. Quartus II Software Design Flow
Design Files
Analysis & Elaboration
Functional
Simulation
Integrated Analysis & Synthesis
Constraints
& Settings
Fitter
Constraints
& Settings
Functional
Netlist
Gate-Level
Timing
Simulation
Post Place-and-Route
Simulation Files
(.vo/.vho, .sdo)
Timing
and Area
Requirements
Satisfied?
No
Yes
Configuration/
Programming
Files (.sof/.pof)
Program/Configure Device
3–2
Altera Corporation
October 2007
Device Support
Device Support
The Quartus II software supports most of the devices supported in the
MAX+PLUS II software, but it does not support any obsolete devices or
packages. The devices supported by these two software packages are
shown in Table 3–1.
Table 3–1. Device Support Comparison
Device Supported
Quartus II
MAX+PLUS II
Arria GX™
v
—
Stratix® Series
v
—
Cyclone®
v
—
Hardcopy® Series
v
—
MAX®
v
—
Classic™
—
v
MAX 3000A
v
v
MAX 7000S/AE/B
v
v
MAX 7000E
—
v
MAX 9000
—
v
ACEX®
1K
v
v
FLEX®
6000
v
v
FLEX 8000
—
v
FLEX 10K
v (1)
v
FLEX 10KA
v
v
FLEX 10KE
v (2)
v
Mercury™
v
—
APEX™ II
v
—
APEX™ 20K
v
—
Series
II
Notes to Table 3–1:
(1)
(2)
Altera Corporation
October 2007
PGA packages (represented as package type G in the ordering code) are not
supported in the Quartus II software.
Some packages are not supported.
3–3
Quartus II Handbook, Volume 1
Quartus II GUI
Overview
The Quartus II software provides the following utility windows to assist
in the development of your designs:
■
■
■
■
■
■
Project Navigator
Node Finder
Tcl Console
Messages
Status
Change Manager
Project Navigator
The Hierarchy tab of the Project Navigator window is similar to the
MAX+PLUS II Hierarchy Display and provides additional information
such as logic cell, register, and memory bit resource utilization. The Files
and Design Units tabs of the Project Navigator window provide a list of
project files and design units.
Node Finder
The Node Finder window provides the equivalent functionality of the
MAX+PLUS II Search Node Database dialog box and allows you to find
and use any node name stored in the project database.
Tcl Console
The Tcl Console window allows access to the Quartus II Tcl shell from
within the GUI. You can use the Tcl Console window to enter Tcl
commands and source Tcl scripts to make assignments, perform
customized timing analysis, view information about devices, or fully
automate and customize the way you run all components of the
Quartus II software. There is no equivalent functionality in the
MAX+PLUS II software.
f
For more information on using Tcl with the Quartus II software, refer to
the Tcl Scripting chapter in volume 2 of the Quartus II Handbook.
Messages
The Messages window is similar to the Message Processor window in the
MAX+PLUS II software, providing detailed information, warnings, and
error messages.You also can use it to locate a node from a message to
various windows in the Quartus II software.
3–4
Altera Corporation
October 2007
Quartus II GUI Overview
Status
The Status window displays information similar to the MAX+PLUS II
Compiler window. Progress and elapsed time are shown for each stage of
the compilation.
Change Manager
The Change Manager provides detailed tracking information on all
design changes made with the Chip Planner.
f
For more information about the Engineering Change Manager and the
Chip Editor, refer to the Engineering Change Management with the Chip
Planner chapter in volume 2 of the Quartus II Handbook.
Figure 3–2 shows a typical Quartus II software display.
Figure 3–2. Quartus II Look and Feel
Altera Corporation
October 2007
3–5
Quartus II Handbook, Volume 1
Setting Up
MAX+PLUS II
Look and Feel in
Quartus II
You can choose the MAX+PLUS II look and feel by selecting
MAX+PLUS II in the Look & Feel box of the General tab of the
Customize dialog box on the Tools menu.
1
Any changes to the look and feel do not become effective until
you restart the Quartus II software.
By default, when you select the MAX+PLUS II look and feel, the
MAX+PLUS II quick menu (Figure 3–21 on page 3–35) appears on the
left side of the menu bar. You can turn the Quartus II and MAX+PLUS II
quick menus on or off. You also can change the preferred positions of the
two quick menus. To change these options, perform the following steps:
3–6
1.
On the Tools menu, click Customize. The Customize dialog box is
shown.
2.
Click the General tab.
3.
Under Quick menus, select your preferred options.
Altera Corporation
October 2007
MAX+PLUS II Look and Feel
MAX+PLUS II
Look and Feel
The MAX+PLUS II look and feel in the Quartus II software closely
resembles the MAX+PLUS II software. Figures 3–3 and 3–4 compare the
MAX+PLUS II software appearance with the Quartus II MAX+PLUS II
look and feel.
Figure 3–3. MAX+PLUS II Software GUI
Altera Corporation
October 2007
3–7
Quartus II Handbook, Volume 1
Figure 3–4. Quartus II Software with MAX+PLUS II Look and Feel
The standard MAX+PLUS II toolbar is also available in the Quartus II
software with the MAX+PLUS II look and feel in the Quartus II software
(Figure 3–5).
Figure 3–5. Standard MAX+PLUS II Toolbar
3–8
Altera Corporation
October 2007
Compiler Tool
Compiler Tool
The Quartus II Compiler Tool provides an intuitive MAX+PLUS II style
interface. You can edit the settings and view result files for the following
modules:
■
■
■
■
■
■
■
Analysis and Synthesis
Partition Merge
Fitter
Assembler
Timing Analyzer
EDA Netlist Writer
Design Assistant
Each of these modules is described later in this section.
To start a compilation using the Compiler Tool, click Compiler Tool from
either the MAX+PLUS II menu or the Tools menu and click Start in the
Compiler Tool. The Compiler Tool, shown in Figure 3–6, displays all
modules, including optional modules such as Partition Merge,
Assembler, EDA Netlist Writer, and the Design Assistant.
f
For information about using the Quartus II software modules at the
command line, refer to the Command-Line Scripting chapter in volume 2
of the Quartus II Handbook.
Figure 3–6. Running a Full Compilation with the Compiler Tool
Altera Corporation
October 2007
3–9
Quartus II Handbook, Volume 1
Analysis and Synthesis
The Quartus II Analysis and Synthesis module analyzes your design,
builds the design database, optimizes the design for the targeted
architecture, and maps the technology to the design logic.
In MAX+PLUS II software, these functions are performed by the
Compiler Netlist Extractor, Database Builder, and Logic Synthesizer.
There is no module in the Quartus II software similar to the
MAX+PLUS II Partitioner module.
Partition Merge
The optional Quartus II Partition Merge module merges the partitions to
create a flattened netlist for further stages of the Quartus II compilation
flow. The Partition Merge module is not similar to the MAX+PLUS II
Partitioner. This tool is available only if you turn on incremental
compilation. You can turn on incremental compilation by performing the
following steps:
1.
On the Assignment menu, click Settings. The Settings dialog box
appears.
2.
In the Category list, click the + icon to expand Compilation Process
Settings, and select Incremental Compilation. The Full
Incremental Compilation page appears.
3.
Under Incremental compilation, turn on Incremental Compilation.
Fitter
The Quartus II Fitter module uses the PowerFitTM fitter to fit your design
into the available resources of the targeted device. The Fitter places and
routes the design. The Fitter module is similar to the Fitter stage of the
MAX+PLUS II software.
3–10
Altera Corporation
October 2007
Compiler Tool
Assembler
The optional Quartus II Assembler module creates a device
programming image of your design so that you can configure your
device. You can select from the following types of programming images:
■
■
■
■
■
■
■
Programmer Object File (.pof)
SRAM Output File (.sof)
Hexadecimal (Intel-Format) Output File (.hexout)
Tabular Text File (.ttf)
Raw Binary File (.rbf)
Jam™ STAPL Byte Code 2.0 File (.jbc)
JEDEC STAPL Format File (.jam)
You can turn off the Assembler module during compilation by turning off
Run assembler in the Compilation Process Settings page in the Settings
dialog box. You also can turn off the Assembler by right-clicking in the
Compiler Tool window. The Assembler module is similar to the
Assembler stage of the MAX+PLUS II software.
Timing Analyzer
The Quartus II Timing Analyzer allows you to analyze more complex
clocking schemes than is possible with the MAX+PLUS II Timing
Analyzer. The Quartus II Timing Analyzer analyzes all clock domains in
your design, including paths that cross clock domains, and also reports
both fMAX and slack. Slack is the margin by which the timing requirement
is met or is not met. For more information on the Timing Analyzer, refer
to “Timing Analysis” on page 3–27.
EDA Netlist Writer
The optional Quartus II EDA Netlist Writer module generates a netlist for
simulation with an EDA simulation tool. The EDA Netlist Writer module
is comparable to the VHDL and Verilog Netlist Writer in the
MAX+PLUS II software.
Design Assistant
The optional Quartus II Design Assistant module checks the reliability of
your design based on a set of design rules. The Design Assistant analyzes
and generates messages for a design targeting any Altera device and is
especially useful for checking the reliability of a design to be converted to
HardCopy series devices. The Design Assistant is similar to the Design
Doctor in the MAX+PLUS II software.
Altera Corporation
October 2007
3–11
Quartus II Handbook, Volume 1
In the Quartus II software, you can reduce subsequent compilation time
significantly by turning Use Smart compilation on before compiling your
design. The Smart Compilation feature skips any compilation stages
which are not required and which may use more disk space. This
Quartus II smart compilation option is similar to the MAX+PLUS II
Smart Recompile command. To turn the Use Smart compilation option
on, perform the following steps:
MAX+PLUS II
Design
Conversion
1.
On the Assignments menu, click Settings. The Settings dialog box
appears.
2.
In the Category list, select Compilation Process Settings. The
Compilation Process Settings page appears.
3.
Turn on Use Smart compilation.
With the Quartus II software, you can open MAX+PLUS II designs and
convert MAX+PLUS II assignments and files.
The Quartus II software is project based. All the files for your design
(HDL input, simulation vectors, assignments, and other relevant files) are
associated with a project file. For more information about creating a new
project, refer to “Creating a New Project” on page 3–16.
Converting an Existing MAX+PLUS II Design
You can easily convert an existing MAX+PLUS II design for use with the
Quartus II software with the Convert MAX+PLUS II Project command
in the Quartus II software or the Open Project command. You can find
these commands on the File menu
If you use the Convert MAX+PLUS II Project command, browse to the
MAX+PLUS II Assignments and Configuration File (.acf) or top-level
design file (Figure 3–7) and click Open. The Convert MAX+PLUS II
Project command generates a Quartus II Project File (.qpf) and a
Quartus II Settings File (.qsf). The Quartus II software stores project and
design assignments in the Quartus II Settings File, which is equivalent to
the Assignments and Configuration File in the MAX+PLUS II software.
You also can open and convert a MAX+PLUS II design with the Open
Project command. In the Open Project dialog box, browse to the
Assignments and Configuration File or the top-level design file. Click
Open to display the Convert MAX+PLUS II Project dialog box.
3–12
Altera Corporation
October 2007
MAX+PLUS II Design Conversion
1
The Quartus II software can import all MAX+PLUS II-generated
files, but it cannot save files in the MAX+PLUS II format. You
cannot open a Quartus II project in the MAX+PLUS II software,
nor can you convert a Quartus II project to a MAX+PLUS II
project.
Figure 3–7. Convert MAX+PLUS II Project Dialog Box
The conversion process performs the following actions:
■
Converts the MAX+PLUS II Assignments and Configuration File
into a Quartus II Settings File (equivalent to importing all
MAX+PLUS II assignments)
■
Creates a Quartus II Project File
■
Displays all errors and warnings in the Quartus II message window
1
The Quartus II software can read MAX+PLUS II generated
Graphic Design Files (.gdf) and Simulation Channel Files (.scf)
without converting them. These files are not modified during a
MAX+PLUS II design conversion.
Converting MAX+PLUS II Graphic Design Files
The Quartus II Block Editor (similar to the MAX+PLUS II Graphic Editor)
saves files as Block Design Files (.bdf). You can convert your
MAX+PLUS II Graphic Design File into a Quartus II Block Design File
using one of the following methods:
Altera Corporation
October 2007
1.
Open the Graphic Design File and on the File menu, click Save As.
The Save As dialog box is shown.
2.
In the Save as type list, select Block Diagram/Schematic File
(*.bdf).
3–13
Quartus II Handbook, Volume 1
3.
Run the quartus_g2b.exe command line executable located in the
\<Quartus II installation>\bin directory. For example, to convert the
chiptrip.gdf file to a Block Design File, type the following command
at a command prompt:
quartus_g2b.exe chip_trip.gdf r
Importing MAX+PLUS II Assignments
You can import MAX+PLUS II assignments into an existing Quartus II
project. Open the project, and on the Assignments menu, click Import
Assignments. Browse to the Assignments and Configuration File
(Figure 3–8). You can also import Quartus II Settings Files and Entity
Setting Files (.esf).
Figure 3–8. Import Assignments Dialog Box
The Quartus II software accepts most MAX+PLUS II assignments.
However, some assignments can be imported incorrectly from the
MAX+ PLUS II software into the Quartus II software due to differences in
node naming conventions and the advanced Quartus II integrated
synthesis algorithms.
The differing node naming conventions in the Quartus II and
MAX+PLUS II software can cause improper mapping when importing
your design from MAX+PLUS II software into the Quartus II software.
Improper node names can interfere with the design logic if you are
unaware of these node name differences and do not take appropriate
3–14
Altera Corporation
October 2007
Quartus II Design Flow
steps to prevent improper node name mapping. Table 3–2 compares the
differences between the naming conventions used by the Quartus II and
MAX+PLUS II software.
Table 3–2. Quartus II and MAX+PLUS II Node and Pin Naming Conventions
Feature
Quartus II Format
MAX+PLUS II Format
Node name
auto_max:auto|q0
|auto_max:auto|q0
Pin name
d[0], d[1], d[2]
d0, d1, d2
When you import MAX+PLUS II assignments containing node names
that use numbers, such as signal0 or signal1, the Quartus II software
imports the original assignment and also creates an additional copy of the
assignment. The additional assignment has square brackets inserted
around the number, resulting in signal[0] or signal[1]. The square
bracket format is legal for signals that are part of a bus, but creates illegal
signal names for signals that are not part of a bus in the Quartus II
software. If your MAX+PLUS II design contains node names that end in
a number and are not part of a bus, you can edit the Quartus II Settings
File to remove the square brackets from the node names after importing
them.
1
You can remove obsolete assignments in the Remove
Assignments dialog box. Open this dialog box on the
Assignments menu by clicking Remove Assignments.
The Quartus II software may not recognize valid MAX+PLUS II node
names, or may split MAX+PLUS II nodes into two different nodes. As a
result, any assignments made to synthesized nodes are not recognized
during compilation.
f
Quartus II
Design Flow
f
Altera Corporation
October 2007
For more information about Quartus II node naming conventions, refer
to the Quartus II Integrated Synthesis chapter in volume 1 of the Quartus II
Handbook.
The following sections include information to help you get started using
the Quartus II software. They describe the similarities and differences
between the Quartus II software and the MAX+PLUS II software. The
following sections highlight improvements and benefits in the Quartus II
software.
For an overview of the Quartus II software features and design flow,
refer to the Introduction to Quartus II manual.
3–15
Quartus II Handbook, Volume 1
Creating a New Project
The Quartus II software provides a wizard to help you create new
projects. On the File menu, click New Project Wizard to start the New
Project Wizard. The New Project Wizard generates the Quartus II Project
File and Quartus II Settings File for your project.
Design Entry
The Quartus II software supports the following design entry methods:
■
■
■
■
■
■
Altera HDL (AHDL) Text Design File (.tdf)
Block Diagram File
EDIF Netlist File (.edf)
Verilog Quartus Mapping Netlist File (.vqm)
VHDL (.vhd)
Verilog HDL (.v)
The Quartus II software has an advanced integrated synthesis engine that
fully supports the Verilog HDL and VHDL languages and provides
options to control the synthesis process.
f
For more information, refer to the Quartus II Integrated Synthesis chapter
in volume 1 of the Quartus II Handbook.
To create a new design file, perform the following steps:
3–16
1.
On the File menu, click New. The New dialog box appears.
2.
Click the Device Design Files tab.
3.
Select a design entry type.
4.
Click OK (see Figure 3–9).
Altera Corporation
October 2007
Quartus II Design Flow
Figure 3–9. New Dialog Box
1
You can create other files from the Software Files tab and Other
Files tab of the New dialog box on the File menu. For example,
the Vector Waveform File (.vwf) is located in the Other Files tab.
To analyze a netlist file created by an EDA tool, perform the following
steps:
Altera Corporation
October 2007
1.
On the Assignments menu, click EDA Tool Settings. The Settings
dialog box appears.
2.
In the Category list, select Design Entry & Synthesis. The Design
Entry & Synthesis page appears.
3.
In the Tool name list, select the synthesis tool used to generate the
netlist (Figure 3–10).
3–17
Quartus II Handbook, Volume 1
Figure 3–10. Settings Dialog Box Specifying Design Entry Tool
The Quartus II Block Editor has many advantages over the MAX+PLUS II
Graphic Editor. The Block Editor offers an unlimited sheet size, multiple
region selections, an enhanced Symbol Editor, and conduits.
The Symbol Editor allows you to change the positions of the ports in a
symbol (refer to the three images in Figure 3–11). You can reduce wire
congestion around a symbol by changing the positions of the ports.
3–18
Altera Corporation
October 2007
Quartus II Design Flow
Figure 3–11. Various Port Position for a Symbol
To make changes to a symbol in a Block Design File, right-click a symbol
in the Block Editor and select Properties to display the Symbol
Properties dialog box. This dialog box allows you to change the instance
name, add parameters, and specify the line and text color.
You can use conduits to connect blocks (including pins) in the Block
Editor. Conduits contain signals for the connected objects
(see Figure 3–12). You can determine the connections between various
blocks in the Conduit Properties dialog box by right-clicking a conduit
and clicking Properties.
Altera Corporation
October 2007
3–19
Quartus II Handbook, Volume 1
Figure 3–12. Blocks and Pins Connected with Conduits
Making Assignments
The Quartus II software stores all project and design assignments in a
Quartus II Settings File, which is a collection of assignments stored as Tcl
commands and organized by the compilation stage and assignment type.
The Quartus II Settings File stores all assignments, regardless of how they
are made, from the Floorplan Editor, the Pin Planner, the Assignment
Editor, with Tcl, or any other method.
3–20
Altera Corporation
October 2007
Quartus II Design Flow
Assignment Editor
The Assignment Editor is an intuitive spreadsheet interface designed to
allow you to make, change, and manage a large number of assignments
easily. With the Assignment Editor, you can list all available pin numbers
and design pin names for efficiently creating pin assignments. You also
can filter all assignments based on assignment categories and node names
for viewing and creating assignments.
The Assignment Editor is composed of the Category Bar, Node Filter Bar,
Information Bar, Edit Bar, and spreadsheet.
To make an assignment, follow these steps:
1.
On the Assignments menu, click Assignment Editor. The
Assignment Editor window appears.
2.
Select an assignment category in the Category bar.
3.
Select a node name using the Node Finder or type a node name filter
into the Node Filter bar. (This step is optional; it excludes all
assignments unrelated to the node name.)
4.
Type the required values into the spreadsheet.
5.
On the File menu, click Save.
If you are unsure about the purpose of a cell in the spreadsheet, select the
cell and read the description displayed in the Information bar.
You can use the Edit bar to change the contents of multiple selected cells
simultaneously. Select cells in the spreadsheet and type the value in the
Edit box.
Other advantages of the Assignment Editor include clipboard support in
the spreadsheet and automatic font coloring to identify the status of
assignments.
f
Altera Corporation
October 2007
For more information, refer to the Assignment Editor chapter in volume 1
of the Quartus II Handbook.
3–21
Quartus II Handbook, Volume 1
Timing Assignments
You can use the timing wizard to help you set your timing requirements.
On the Assignments menu, click Timing Wizard to create global clock
and timing settings. The settings include fMAX, setup times, hold times,
clock to output delay times, and individual absolute or derived clocks.
You also can set timing settings manually by performing the following
steps:
1.
On the Assignments menu, click Settings. The Setting dialog box is
shown.
2.
In the Category list, select Timing Requirements & Options. The
Timing Requirements & Options page is shown.
3.
Set your timing settings.
You can make more complex timing assignments with the Quartus II
software than allowed by the MAX+PLUS II software, including
multicycle and point-to-point assignments using wildcards and time
groups.
1
A time group is a collection of design nodes grouped together
and represented as a single unit for the purpose of making
timing assignments to the collection.
Multicycle timing assignments allow you to identify register-to-register
paths in the design where you expect a delayed latch edge. This
assignment enables accurate timing analysis of your design.
Point-to-point timing assignments allow you to specify the required
delay between two pins, two registers, or a pin and a register. This
assignment helps you optimize and verify your design timing
requirements.
Wildcard characters “?” and “ * “ allow you to apply an assignment to a
large number of nodes with just a few assignments. For example,
Figure 3–13 shows a 4 ns tSU requirement assignment to all paths from
any node to the “d” bus in the Assignment Editor.
3–22
Altera Corporation
October 2007
Quartus II Design Flow
Figure 3–13. Single tSU Timing Assignment Applied to All Nodes of a Bus
f
For more information, refer to the Classic Timing Analyzer or the
TimeQuest Timing Analyzer chapter in volume 3 of the Quartus II
Handbook.
Synthesis
The Quartus II advanced integrated synthesis software fully supports the
hardware description languages, Verilog HDL, VHDL, and AHDL,
schematic entry, and also provides options to control the synthesis
process. With this synthesis support, the Quartus II software provides a
complete, easy-to-use, stand-alone solution for today's designs.
You can specify synthesis options in the Analysis & Synthesis Settings
page of the Settings dialog box. Similar to MAX+PLUS II synthesis
options, you select one of these optimization techniques: Speed, Area, or
Balanced.
To achieve higher design performance, you can turn on synthesis netlist
optimizations that are available when targeting certain devices. You can
unmap a netlist created by an EDA tool and remap the components in the
netlist back to Altera primitives by turning on Perform WYSIWYG
primitive resynthesis. Additionally, you can move registers across
combinational logic to balance timing without changing design
functionality by turning on Perform gate-level register retiming. Both of
these options are accessible from the Synthesis Netlist Optimizations
page under Analysis & Synthesis Settings in the Settings dialog box on
the Assignments menu.
f
Altera Corporation
October 2007
For more information, refer to the Quartus II Integrated Synthesis chapter
in volume 1 of the Quartus II Handbook.
3–23
Quartus II Handbook, Volume 1
Functional Simulation
Similar to the MAX+PLUS II Simulator, the Quartus II Simulator Tool
performs both functional and timing simulations.
To open the Simulator Tool, on MAX+PLUS II menu, click Simulator or
on the Tools menu, click Simulator Tool. Before you perform a functional
simulation, an internal functional simulation netlist is required. Click
Generate Functional Simulation Netlist in the Simulator Tool window
(Figure 3–14), or on the Processing menu, click Generate Functional
Simulation Netlist.
1
Generating a functional simulation netlist creates a separate
database that improves the performance of the simulation
significantly.
Figure 3–14. Simulator Tool Dialog Box
You can view and modify the simulator options on the Simulator page of
the Settings dialog box or in the Simulator Tool window. You can set the
simulation period and turn Check outputs on or off. You can choose to
display the simulation outputs in the simulation report or in the Vector
Waveform File. To display the simulation results in the simulation input
vector waveform file, which is the MAX+PLUS II behavior, turn on
Overwrite simulation input file with simulation results.
3–24
Altera Corporation
October 2007
Quartus II Design Flow
When using either the MAX+PLUS II or Quartus II software, you may
have to compile additional behavioral models to perform a simulation
with an EDA simulation tool. In the Quartus II software, behavioral
models for library of parameterized modules (LPM) functions and
Altera-specific megafunctions are available in the altera_mf and
220model library files, respectively. The 220model and altera_mf files
can be found in the \<Quartus II Installation>\eda\sim_lib directory.
The Quartus II schematic design files (Block Design File, or .bdf) are not
compatible with EDA simulation tools. To perform a register transfer
level (RTL) functional simulation of a Block Design File using an EDA
tool, convert your schematic designs to a VHDL or Verilog HDL design
file. Open the schematic design file and on the File menu, click
Create/Update > Create HDL Design File for Current File to create an
HDL design file that corresponds to your Block Design File.
You can export a Vector Waveform File or Simulator Channel File as a
Verilog HDL or VHDL test bench file for simulation with an EDA tool.
Open your Vector Waveform File or Simulator Channel File and on the
File menu, click Export. See Figure 3–15. Select Verilog or VHDL Test
Bench File (*.vt) from the Save as type list. Turn on Add self-checking
code to file to add additional self-checking code to the test bench.
Figure 3–15. Export Dialog Box
Altera Corporation
October 2007
3–25
Quartus II Handbook, Volume 1
Place and Route
The Quartus II PowerFit is an incremental fitter that performs
place-and-route to fit your design into the targeted device. You can
control the Fitter behavior with options in the Fitter Settings page of the
Settings dialog box on the Assignments menu.
High-density device families supported in the Quartus II software, such
as the Stratix series, sometimes require significant fitter effort to achieve
an optimal fit. The Quartus II software offers several options to reduce
the time required to fit a design. You can control the effort the Quartus II
Fitter expends to achieve your timing requirements with these options:
■
■
■
Optimize timing performs timing-based placement using the timing
requirements you specify for the design. You can use this option by
itself or with one or more of the options below.
Optimize hold timing optimizes the hold times within a device to
meet timing requirements and assignments you specify. You can
select this option only if the Optimize timing option is also chosen.
Optimize fast-corner timing instructs the Fitter, when optimizing
your design, to consider fast-corner delays, in addition to
slow-corner delays, from the fast-corner timing model (fastest
manufactured device, operating in low-temperature and
high-voltage conditions). You can select this option only if the
Optimize timing option is also chosen.
If minimizing compilation time is more important than achieving specific
timing results, you can turn these options off.
Another way to decrease the processing time and effort the Fitter expends
to fit your design is to select either Standard Fit or Fast Fit in the Fitter
Effort box of the Fitter Settings page in the Settings dialog box on the
Assignments menu. The option you select affects the Fitter behavior and
your design as described below.
■
■
Select Standard Fit for the Fitter to use the highest effort and
preserve the performance from previous compilations.
Select Fast Fit for up to 50% faster compilation times, although this
may reduce design performance.
You can also select Auto Fit to decrease compilation time by directing the
Fitter to reduce Fitter effort after meeting your timing requirements. The
Auto Fit option is available for select devices.
f
3–26
For more information, refer to the Area and Timing Optimization chapter
in volume 2 of the Quartus II Handbook.
Altera Corporation
October 2007
Quartus II Design Flow
To further reduce compilation times, turn on Limit to one fitting attempt
in the Fitter Settings page in the Settings dialog box on the Assignments
menu.
If your design is very close to meeting your timing requirements, you can
control the seed number used in the fitting algorithm by changing the
value in the Seed box of the Fitter Settings page of the Settings dialog
box on the Assignments menu. The default seed value is 1. You can
specify any non-negative integer value. Changing the value of the seed
only repositions the starting location of the Fitter, but does not affect
compilation time or the Fitter effort level. However, if your design is
difficult to fit optimally or takes a long time to fit, sometimes you can
improve results or processing time by changing the seed value.
Timing Analysis
Version 6.1 and later of the Quartus II software supports two native
timing analysis tools: TimeQuest Timing Analyzer and the Classic
Timing Analyzer. Both timing analysis tools provide more complex
clocking schemes than is possible with the MAX_PLUS II Timing
Analyzer. The TimeQuest analyzer uses the industry-standard Synopsys
Design Constraint (SDC) methodology for constraining designs and
reporting results. In general, the TimeQuest Timing Analyzer provides
more control in constraining a design as compared to the Classic Timing
Analyzer. However, the Classic Timing Analyzer incorporates a basic
graphical user interface and the timing analysis flow is similar to the flow
in the MAX_PLUS II software. As such, the section that follows provides
a more detailed look at timing analysis using the Classic Timing
Analyzer.
f
For more information on choosing between the TimeQuest Timing
Analyzer or the Classic Timing Analyzer, refer to the Timing Analysis
Section in the Introduction to Quartus II manual.
Launch the Classic Timing Analyzer tool on the MAX+PLUS II menu by
clicking Classic Timing Analyzer or by selecting Classic Timing
Analyzer Tool on the Processing menu. See Figure 3–16. To start the
analysis, click Start in the Timing Analyzer Tool or on the Processing
menu, by pointing to Start, and clicking Start Timing Analyzer.
Altera Corporation
October 2007
3–27
Quartus II Handbook, Volume 1
Figure 3–16. Registered Performance Tab of the Timing Analyzer Tool
The Quartus II Classic Timing Analyzer analyzes all clock domains in
your design, including paths that cross clock domains. You can ignore
paths that cross clock domains by using the following options in the
Timing Requirements & Options page in the Settings dialog box on the
Assignments menu:
■
■
Create a Cut Timing Path assignment
Turn on Cut paths between unrelated clock domains
To view the results from the Classic Timing Analyzer Tool, click the
Report button located at the bottom of the Classic Timing Analyzer
dialog box, or to get specific information, click on any of the following
tabs at the top of the Classic Timing Analyzer window:
■
■
■
■
■
■
3–28
Registered Performance
tPD
tSU
tCO
tH
Custom Delays
Altera Corporation
October 2007
Quartus II Design Flow
The Quartus II Classic Timing Analyzer reports both fMAX and slack.
Slack is the margin by which the timing requirement was met or not met.
A positive slack value, displayed in black, indicates the margin by which
a requirement was met. A negative slack value, displayed in red,
indicates the margin by which a requirement was not met.
To analyze a particular path in more detail, select a path in the Classic
Timing Analyzer Tool and click List Paths. This displays a detailed
description of the path in the System tab of the Messages window
(Figure 3–17).
Figure 3–17. Messages Window Displaying Detailed Timing Information
f
For more information, refer to the Classic Timing Analyzer or the
TimeQuest Timing Analyzer chapter in volume 3 of the Quartus II
Handbook.
Timing Closure Floorplan
The Quartus II Timing Closure Floorplan is similar to the MAX+PLUS II
Floorplan Editor but has many improvements to help you more
effectively view and debug your design. With its ability to display logic
cell usage, routing congestion, critical paths, and LogicLockTM regions,
the Timing Closure Floorplan also makes the task of improving your
design performance much easier.
Altera Corporation
October 2007
3–29
Quartus II Handbook, Volume 1
To view the Timing Closure Floorplan, on the MAX+PLUS II menu, click
Floorplan Editor or Timing Closure Floorplan.
The Timing Closure Floorplan Editor provides Interior Cell views
equivalent to the MAX+PLUS II logic array block (LAB) views. In
addition to these views, available from the View menu, you also can
select from the Interior MegaLABs (where applicable), Interior LABs, and
Field views.
1
The Pin Planner is equivalent to the MAX+PLUS II Device view.
The Pin Planner can be launched from the Timing Closure
Floorplan Editor by selecting Package (Top or Bottom) from the
View menu or on the Assignments menu by clicking Pin
Planner.
The Interior LABs view hides cell details for logic cells, Adaptive Logic
Modules (ALM), and macrocells, and shows LAB information
(see Figure 3–18). You can display the number of cells used in each LAB
on the View menu by clicking Show Usage Numbers.
Figure 3–18. Interior LAB View of the Timing Closure Floorplan
The Field view is a color-coded, high-level view of your device resources
that hides both cell and LAB details. In the Field view, you can see critical
paths and routing congestion in your design.
The View Critical Paths feature shows a percentage of all critical paths in
your floorplan. You can enable this feature on the View menu by clicking
Show Critical Paths. You can control the number of critical paths shown
by modifying the settings in the Critical Paths Settings dialog box on the
View menu.
The View Congestion feature displays routing congestion by coloring
and shading logic resources. Darker shading shows greater resource
utilization. This feature assists in identifying locations where there is a
lack of routing resources.
3–30
Altera Corporation
October 2007
Quartus II Design Flow
1
f
To show lower level details in any view, right-click on a resource
and click Show Details.
For more information, refer to the Timing Closure Floorplan chapter in
volume 2 of the Quartus II Handbook.
Timing Simulation
Timing simulation is an important part of the verification process. The
Quartus II software supports native timing simulation and exports
simulation netlists to third-party software for design verification.
Quartus II Simulator Tool
The Quartus II Simulator tool is an easy-to-use integrated solution that
uses the compiler database to simulate the logical and timing
performance of your design (Figure 3–19). When performing timing
simulation, the simulator uses place-and-route timing information.
Figure 3–19. Quartus II Simulator Tool
You can use Vector Table Output Files (.tbl), Vector Waveform Files,
Vector Files (.vec), or an existing Simulator Channel File as the vector
stimuli for your simulation.
Altera Corporation
October 2007
3–31
Quartus II Handbook, Volume 1
The simulation options available are similar to the options available in the
MAX+PLUS II Simulator. You can control the length of the simulation
and the type of checks performed by the Simulator. When the
MAX+PLUS II look and feel is selected, the Overwrite simulation input
file with simulation results option is on by default. If you turn it off, the
simulation results are written to the report file. To view the report file,
click Report in the Simulator Tool window.
EDA Timing Simulation
The Quartus II software also supports timing simulation with other EDA
simulation software. Performing timing simulation with other EDA
simulation software requires a Quartus II generated timing netlist file in
the form of a Verilog Output File (.vo) or VHDL Output File (.vho), a
Standard Delay Format Output File (.sdo), and a device-specific atom file
(or files), shown in Table 3–3.
Table 3–3. Altera Timing Simulation Library Files
Verilog
<device_family>_atoms.v
VHDL
<device_family>_atoms_87.vhd
<device_family>_atoms.vhd
<device_family>_components.vhd
Specify your EDA simulation tool by performing the following steps:
1.
On the Assignments menu, click EDA Tool 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 EDA Tool.
You can generate a timing netlist for the selected EDA simulator tool by
running a full compile or on the Processing menu, by pointing to Start
and clicking Start EDA Netlist Writer. The generated netlist and SDF file
are placed into the \<project directory>\simulation\<EDA simulator tool>
directory. The device-specific atom files are located in the
\<Quartus II Install>\eda\sim_lib directory.
3–32
Altera Corporation
October 2007
Quartus II Design Flow
Power Estimation
To develop an appropriate power budget and to design the power
supplies, voltage regulators, heat sink, and cooling system, you need an
accurate estimate of the power that your design consumes. You can
estimate power by using the PowerPlay Early Power Estimation
spreadsheet available on the Altera website at www.altera.com, or with
the PowerPlay Power Analyzer in the Quartus II software.
You can perform early power estimation with the PowerPlay Early Power
Estimation spreadsheet by entering device resource and performance
information. The Quartus II PowerPlay Analyzer tool performs
vector-based power analysis by reading either a Signal Activity File (.saf),
generated from a Quartus II simulation, or a Value Change Dump File
(VCD) generated from a third-party simulation.
f
For more information about how to use the PowerPlay Power Analyzer
tool, refer to the PowerPlay Power Analysis chapter in volume 3 of the
Quartus II Handbook.
Programming
The Quartus II Programmer has the same functionality as the
MAX+PLUS II Programmer, including programming, verifying,
examining, and blank checking operations. Additionally, the Quartus II
Programmer now supports the erase capability for CPLDs. To improve
usability, the Quartus II Programmer displays all programming-related
information in one window (Figure 3–20).
Click Add File or Add Device in the Programmer window to add a file
or device, respectively.
Altera Corporation
October 2007
3–33
Quartus II Handbook, Volume 1
Figure 3–20. Programmer Window
1
Figure 3–20 shows that the Programmer Window now supports
Erase capability.
You can save the programmer settings as a Chain Description File (.cdf).
The CDF is an ASCII text file that stores device name, device order, and
programming file name information.
Conclusion
3–34
The Quartus II software is the most comprehensive design environment
available for programmable logic designs. Features such as the
MAX+PLUS II look and feel help you make the transition from Altera’s
MAX+PLUS II design software and become more productive with the
Quartus II software. The Quartus II software has all the capabilities and
features of the MAX+PLUS II software and many more to speed up your
design cycle.
Altera Corporation
October 2007
Quick Menu Reference
Quick Menu
Reference
The commands displayed in the MAX+PLUS II Quick Menu and the
Quartus II Quick Menu vary based on whichever window is active
(Figures 3–21). In the following figure, the Graphic Editor window is
active.
Figure 3–21. MAX+PLUS II Quick Menus in MAX+PLUS II and Quartus II
Software
MAX+PLUS II Quick Menu
Altera Corporation
October 2007
MAX+PLUS II Quick Menu in Quartus II Software
3–35
Quartus II Handbook, Volume 1
Quartus II
Command
Reference for
MAX+PLUS II
Users
Table 3–4 lists the commands in the MAX+PLUS II software and gives
their equivalent commands in the Quartus II software.
NA means either Not Applicable or Not Available. If a command is not
listed, then the command is the same in both tools.
Table 3–4. Quartus II Command Reference for MAX+PLUS II Users (Part 1 of 10)
MAX+PLUS II Software
Quartus II Software
MAX+PLUS II Menu
Hierarchy Display
View menu, Utility Windows, Project Navigator
Graphic Editor
Block Editor
Symbol Editor
Block Symbol Editor
Text Editor
Text Editor
Waveform Editor
Waveform Editor
Floorplan Editor
Assignments menu, Timing Closure Floorplan
Compiler
Tools menu, Compiler Tool
Simulator
Tools menu, Simulator Tool
Timing Analyzer
Tools menu, Timing Analyzer Tool
Programmer
Tools menu, Programmer
Message Processor
View menu, Utility Windows, Messages
File Menu
3–36
File menu, Project, Name (Ctrl+J)
File menu, Open Project (Ctrl+J)
File menu, Project, Set Project to Current
File (Ctrl+Shift+J)
Project menu, Set as Top-Level Entity (Ctrl+Shift+J)
or
File menu, New Project Wizard
File menu, Project, Save & Check (Ctrl+K)
Processing menu, Start, Start Analysis & Synthesis
(Ctrl+K)
or
Processing menu, Start, Start Analysis &
Elaboration
File menu, Project, Save & Compile (Ctrl+L)
Processing menu, Start Compilation (Ctrl+L)
Altera Corporation
October 2007
Quartus II Command Reference for MAX+PLUS II Users
Table 3–4. Quartus II Command Reference for MAX+PLUS II Users (Part 2 of 10)
MAX+PLUS II Software
Quartus II Software
File menu, Project, Save & Simulate
(Ctrl+Shift+L)
Processing menu, Start Simulation (Ctrl+I)
File menu, Project, Compile & Simulate
(Ctrl+Shift+K)
Processing menu, Start Compilation & Simulation
(Ctrl+Shift+K)
File menu, Project, Archive
Project menu, Archive Project
File menu, Project, <Recent Projects>
File menu, <Recent Projects>
File menu, Delete File
NA
File menu, Retrieve
NA
File menu, Info (Ctrl+I)
File menu, File Properties
File menu, Create Default Symbol
File menu, Create/Update, Create Symbol Files for
Current File
File menu, Edit Symbol
(Block Editor) Edit menu, Edit Selected Symbol
File menu, Create Default Include File
File menu, Create/Update, Create AHDL Include Files for
Current File
File menu, Hierarchy Project Top (Ctrl+T)
Project menu, Hierarchy, Project Top (Ctrl+T)
File menu, Hierarchy, Up (Ctrl+U)
Project menu, Hierarchy, Up (Ctrl+U)
File menu, Hierarchy, Down (Ctrl+D)
Project menu, Hierarchy, Down (Ctrl+D)
File menu, Hierarchy, Top
NA
File menu, Hierarchy, Project Top (Ctrl+T)
Project menu, Hierarchy, Project Top (Ctrl+T)
File menu, MegaWizard Plug-In Manager
Tools menu, MegaWizard Plug-In Manager
(Graphic Editor) File menu, Size
NA
(Waveform Editor) File menu, End Time
(Waveform Editor) Edit menu, End Time
(Waveform Editor) File menu, Compare
(Waveform Editor) View menu, Compare to
Waveforms in File
(Waveform Editor) File menu, Import Vector File
File menu, Open (Ctrl+O)
(Waveform Editor) File menu, Create Table File
File menu, Save As
(Hierarchy Display) File menu, Select Hierarchy
NA
(Hierarchy Display) File menu, Open Editor
(Project Navigator) Double-click
(Hierarchy Display) File menu, Close Editor
NA
(Hierarchy Display) File menu, Change File Type
(Project Navigator) Select file in Files tab and select
Properties on right click menu
(Hierarchy Display) File menu, Print Selected
Files
NA
Altera Corporation
October 2007
3–37
Quartus II Handbook, Volume 1
Table 3–4. Quartus II Command Reference for MAX+PLUS II Users (Part 3 of 10)
MAX+PLUS II Software
Quartus II Software
(Programmer) File menu, Select Programming
File
File menu, Open
(Programmer) File menu, Save Programming
Data As
File menu, Save
(Programmer) File menu, Inputs/Outputs
NA
(Programmer) File menu, Convert SRAM Object
Files
File menu, Convert Programming Files
(Programmer) File menu, Archive JTAG
Programming Files
NA
(Programmer) File menu, Create Jam or SVF File File menu, Create/Update, Create JAM, SVF, or ISC File
(Message Processor) Select Messages
NA
(Message Processor) Save Messages As
(Messages) Save Messages on right click menu
(Timing Analyzer) Save Analysis As
Processing menu, Compilation Report - Save Current
Report on right click menu in Timing Analyzer sections
(Simulator) Create Table File
(Waveform Editor) File menu, Save As
(Simulator) Execute Command File
NA
(Simulator) Inputs/Outputs
NA
Edit Menu
(Waveform Editor) Edit menu, Overwrite
(Waveform Editor) Edit menu, Value
(Waveform Editor) Edit menu, Insert
(Waveform Editor) Edit menu, Insert Waveform Interval
(Waveform Editor) Edit menu, Align to Grid
(Ctrl+Y)
NA
(Waveform Editor) Edit menu, Repeat
(Waveform Editor) Edit menu, Repeat Paste
(Waveform Editor) Edit menu, Grow or Shrink
Edit menu, Grow or Shrink (Ctrl+Alt+G)
(Text Editor) Edit menu, Insert Page Break
(Text Editor) Edit menu, Increase Indent
(F2)
(Text Editor) Edit menu, Increase Indent
(Text Editor) Edit menu, Decrease Indent
(F3)
(Text Editor) Edit menu, Decrease Indent
(Graphic Editor) Edit menu, Toggle
Connection Dot (Double-Click)
(Block Editor) Edit menu, Toggle Connection Dot
(Graphic Editor) Edit menu, Flip Horizontal
(Block Editor) Edit menu, Flip Horizontal
(Graphic Editor) Edit menu, Flip Vertical
(Block Editor) Edit menu, Flip Vertical
(Graphic Editor) Edit menu, Rotate
3–38
(Text Editor) Edit menu, Insert Page Break
(Block Editor) Edit menu, Rotate by Degrees
Altera Corporation
October 2007
Quartus II Command Reference for MAX+PLUS II Users
Table 3–4. Quartus II Command Reference for MAX+PLUS II Users (Part 4 of 10)
MAX+PLUS II Software
Quartus II Software
View Menu
View menu, Fit in Window (Ctrl+W)
View menu, Fit in Window (Ctrl+W)
View menu, Zoom In (Ctrl+Space)
View menu, Zoom In (Ctrl+Space)
View menu, Zoom Out (Ctrl+Shift+Space)
View menu, Zoom Out (Ctrl+Shift+Space)
View menu, Normal Size (Ctrl+1)
NA
View menu, Maximum Size (Ctrl+2)
NA
(Hierarchy Display) View menu, Auto Fit in
Window
NA
(Waveform Editor) View menu, Time Range
View menu, Zoom
Assign menu, Device
Assignments menu, Device
or
Assignments menu, Settings (Ctrl+Shift+E)
Assign menu, Pin/Location/Chip
Assignments menu, Assignment Editor - Locations
category
Assign menu, Timing Requirements
Assignments menu, Assignment Editor - Timing
category
Assign menu, Clique
Assignments menu, Assignment Editor - Cliques
category
Assign menu, Logic Options
Assignments menu, Assignment Editor - Logic
Options category
Assign menu, Probe
NA
Assign menu, Connected Pins
Assignments menu, Assignment Editor - Simulation
category
Assign menu, Local Routing
Assignments menu, Assignment Editor - Local
Routing category
Assign menu, Global Project Device Options
Assignments menu, Device - Device and Pin Options
Assign menu, Global Project Parameters
Assignments menu, Settings - Analysis and
Synthesis - Default Parameters
Assign menu, Global Project Timing
Requirements
Assignments menu, Timing Settings
Assign menu, Global Project Logic Synthesis
Assignments menu, Settings - Analysis and
Synthesis
Assign menu, Ignore Project Assignments
Assignments menu, Assignment Editor - disable
Assign menu, Clear Project Assignments
Altera Corporation
October 2007
Assignments menu, Remove Assignments
3–39
Quartus II Handbook, Volume 1
Table 3–4. Quartus II Command Reference for MAX+PLUS II Users (Part 5 of 10)
MAX+PLUS II Software
Quartus II Software
Assign menu, Back-Annotate Project
Assignments menu, Back-Annotate Assignments
Assign menu, Convert Obsolete Assignment
Format
NA
Utilities Menu
Utilities menu, Find Text (Ctrl+F)
Edit menu, Find (Ctrl+F)
Utilities menu, Find Node in Design File
(Ctrl+B)
Project menu, Locate, Locate in Design File
Utilities menu, Find Node in Floorplan
Project menu, Locate, Locate in Timing Closure
Floorplan
Utilities menu, Find Clique in Floorplan
NA
Utilities menu, Find Node Source (Ctrl+Shift+S)
NA
Utilities menu, Find Node Destination
(Ctrl+Shift+D)
NA
Utilities menu, Find Next (Ctrl+N)
Edit menu, Find Next (F3)
Utilities menu, Find Previous (Ctrl+Shift+N)
NA
Utilities menu, Find Last Edit
NA
Utilities menu, Search and Replace (Ctrl+R)
Edit menu, Replace (Ctrl+H)
Utilities menu, Timing Analysis Source
(Ctrl+Alt+S)
NA
Utilities menu, Timing Analysis Destination
(Ctrl+Alt+D)
NA
Utilities menu, Timing Analysis Cutoff
(Ctrl+Alt+C)
NA
Utilities menu, Analyze Timing
NA
Utilities menu, Clear All Timing Analysis Tags
NA
(Text Editor) Utilities menu, Go To (Ctrl+G)
Edit menu, Go To (Ctrl+G)
(Text Editor) Utilities menu, Find Matching
Delimiter (Ctrl+M)
(Text Editor) Edit, Find Matching Delimiter (Ctrl+M)
(Waveform Editor) Utilities menu, Find Next
Transition (Right Arrow)
(Waveform Editor) View menu, Next Transition (Right
Arrow)
(Waveform Editor) Utilities menu, Find Previous
Transition (Left Arrow)
(Waveform Editor) View menu, Next Transition (Left
Arrow)
Options Menu
Options menu, User Libraries
3–40
Assignments menu, Settings (Ctrl+Shift+E)
Tools, Options, Global User LIbraries
Altera Corporation
October 2007
Quartus II Command Reference for MAX+PLUS II Users
Table 3–4. Quartus II Command Reference for MAX+PLUS II Users (Part 6 of 10)
MAX+PLUS II Software
Options menu, Color Palette
Quartus II Software
Tools menu, Options
Options menu, License Setup
Tools menu, License Setup
Options menu, Preferences
Tools menu, Options
(Hierarchy Display) Options menu, Orientation
NA
(Hierarchy Display) Options menu, Compact
Display
NA
(Hierarchy Display) Options menu, Show All
Hierarchy Branches
(Project Navigator) Expand All on right click menu
(Hierarchy Display) Options menu, Hide All
Hierarchy Branches
NA
(Editors) Options menu, Font
Tools menu, Options
(Editors) Options menu, Text Size
Tools menu, Options
(Graphic Editor) Options menu, Line Style
Edit menu, Line
(Graphic Editor) Options menu,
Rubberbanding
Tools menu, Options
(Graphic Editor) Options menu, Show Parameters
(Graphic Editor) Options menu, Show Probes
View menu, Show Parameter Assignments
NA
(Graphic Editor) Options menu, Show
Pins/Locations/Chips
View menu, Show Pin and Location Assignments
(Graphic Editor) Options menu, Show Clique,
Timing & Local Routing Assignments
NA
(Graphic Editor) Options menu, Show Logic
Options
NA
(Graphic Editor) Options menu, Show All
(Ctrl+Shift+M)
NA
(Graphic Editor) Options menu, Show Guidelines
(Ctrl+Shift+G)
Tools menu, Options - Block/Symbol Editor page
(Graphic Editor) Options menu, Guideline
Spacing
Tools menu, Options - Block/Symbol Editor page
(Symbol Editors) Options menu, Snap to Grid
Tools menu, Options - Block/Symbol Editor page
(Text Editor) Options menu, Tab Stops
Tools menu, Options - Text Editor page
(Text Editor) Options menu, Auto-Indent
Tools menu, Options - Text Editor page
(Text Editor) Options menu, Syntax Coloring
NA
(Waveform Editor) Options menu, Snap to Grid
View menu, Snap to Grid
(Waveform Editor) Options menu, Show Grid
(Ctrl+Shift+G)
Tools menu, Options - Waveform Editor page
(Waveform Editor) Options menu, Grid Size
Edit menu, Grid Size - Waveform Editor page
Altera Corporation
October 2007
3–41
Quartus II Handbook, Volume 1
Table 3–4. Quartus II Command Reference for MAX+PLUS II Users (Part 7 of 10)
MAX+PLUS II Software
(Floorplan Editor) Options menu, Routing
Statistics
Quartus II Software
NA
(Floorplan Editor) Options menu, Show
Node Fan-In
View menu, Routing, Show Fan-In
(Floorplan Editor) Options menu, Show
Node Fan-Out
View menu, Routing, Show Fan-Out
(Floorplan Editor) Options menu, Show Path
View menu, Routing, Show Paths between Nodes
(Floorplan Editor) Options menu, Show Moved
Nodes in Gray
NA
(Simulator) Options menu, Breakpoint
Processing menu, Simulation Debug, Breakpoints
(Simulator) Options menu, Hardware Setup
NA
(Timing Analyzer) Options menu, Time
Restrictions
Assignments menu, Timing Settings
(Timing Analyzer) Options menu,
Auto-Recalculate
NA
(Timing Analyzer) Options menu, Cell Width
NA
(Timing Analyzer) Options menu, Cut Off I/O Pin
Feedback
Assignments menu, Timing Settings
(Timing Analyzer) Options menu, Cut Off Clear &
Reset Paths
Assignments menu, Timing Settings
(Timing Analyzer) Options menu, Cut Off Read
During Write Paths
Assignments menu, Timing Settings
(Timing Analyzer) Options menu, List Only
Longest Path
NA
(Programmer) Options menu, Sound
NA
(Programmer) Options menu, Programming
Options
Tools menu, Options - Programmer page
(Programmer) Options menu, Select Device
(Programmer) Edit menu, Change Device
(Programmer) Options menu, Hardware Setup
(Programmer) Edit menu, Hardware Setup
Symbol (Graphic Editor)
Symbol menu, Enter Symbol (Double-Click)
(Block Editor) Edit menu, Insert Symbol (DoubleClick)
Symbol menu, Update Symbol
Edit menu, Update Symbol or Block
Symbol menu, Edit Ports/Parameters
Edit menu, Properties
Element (Symbol Editor)
Element menu, Enter Pinstub
3–42
Double-click on edge of symbol
Altera Corporation
October 2007
Quartus II Command Reference for MAX+PLUS II Users
Table 3–4. Quartus II Command Reference for MAX+PLUS II Users (Part 8 of 10)
MAX+PLUS II Software
Element menu, Enter Parameters
Quartus II Software
NA
Templates (Text Editor)
Templates
(Text Editor) Edit menu, Insert Template
Node (Waveform Editor)
Node menu, Insert Node (Double-Click)
Edit menu, Insert Node or Bus (Double-Click)
Node menu, Enter Nodes from SNF
Edit menu, Insert Node - click on Node Finder…
Node menu, Edit Node
Double-click on the Node
Node menu, Enter Group
Edit menu, Group
Node menu, Ungroup
Edit menu, Ungroup
Node menu, Sort Names
Node menu, Enter Separator
Edit menu, Sort
NA
Layout (Floorplan Editor)
Layout menu, Full Screen
View menu, Full Screen (Ctrl+Alt+Space)
Layout menu, Report File Equation Viewer
View menu, Equations
Layout menu, Device View (Double-Click)
View menu, Package Top
or
View menu, Package Bottom
Layout menu, LAB View (Double-Click)
View menu, Interior Labs
Layout menu, Current Assignments
Floorplan
View menu, Assignments, Show User Assignments
Layout menu, Last Compilation Floorplan
View menu, Assignments, Show Fitter
Assignments
Processing (Compiler)
Processing menu, Design Doctor
Processing menu, Start, Start Design Assistant
Processing menu, Design Doctor Settings
Assignments menu, Settings - Design Assistant
Processing menu, Functional SNF Extractor
Processing menu, Generate Functional Simulation
Netlist
Processing menu, Timing SNF Extractor
Processing menu, Start Analysis & Synthesis
Processing menu, Optimize Timing SNF
NA
Processing menu, Linked SNF Extractor
NA
Altera Corporation
October 2007
3–43
Quartus II Handbook, Volume 1
Table 3–4. Quartus II Command Reference for MAX+PLUS II Users (Part 9 of 10)
MAX+PLUS II Software
Quartus II Software
Processing menu, Fitter Settings
Assignments menu, Settings - Fitter Settings
Processing menu, Report File Settings
Assignments menu, Settings
Processing menu, Generate AHDL TDO File
NA
Processing menu, Smart Recompile
Assignments menu, Settings - Compilation Process
Processing menu, Total Recompile
Assignments menu, Settings - Compilation Process
Processing menu, Preserve All Node Name
Synonyms
Assignments menu, Settings - Compilation Process
Interfaces (Compiler)
Assignments menu, EDA Tool Settings
Initialize (Simulator)
Initialize menu, Initialize Nodes/Groups
NA
Initialize menu, Initialize Memory
NA
Initialize menu, Save Initialization As
NA
Initialize menu, Restore Initialization
NA
Initialize menu, Reset to Initial SNF Values
NA
Node (Timing Analyzer)
Node menu, Timing Analysis Source (Ctrl+Alt+S) NA
Node menu, Timing Analysis Destination
(Ctrl+Alt+D)
NA
Node menu, Timing Analysis Cutoff (Ctrl+Alt+C) NA
Analysis (Timing Analyzer)
Analysis menu, Delay Matrix
(Timing Analyzer Tool) Delay tab
Analysis menu, Setup/Hold Matrix
NA
Analysis menu, Registered Performance
(Timing Analyzer Tool) Registered Performance tab
JTAG (Programmer)
JTAG menu, Multi-Device JTAG Chain
(Programmer) Mode: JTAG
JTAG menu, Multi-Device JTAG Chain Setup
(Programmer) Window
JTAG menu, Save JCF
File menu, Save
JTAG menu, Restore JCF
File menu, Open
JTAG menu, Initiate Configuration from
Configuration Device
Tools menu, Options - Programmer page
3–44
Altera Corporation
October 2007
Referenced Documents
Table 3–4. Quartus II Command Reference for MAX+PLUS II Users (Part 10 of 10)
MAX+PLUS II Software
Quartus II Software
FLEX (Programmer)
FLEX menu, Multi-Device FLEX Chain
(Programmer) Mode: Passive Serial
FLEX menu, Multi-Device FLEX Chain Setup
(Programmer) Window
FLEX menu, Save FCF
File menu, Save
FLEX menu, Restore FCF
File menu, Open
Referenced
Documents
This chapter references the following documents:
■
■
■
■
■
■
■
■
■
■
Altera Corporation
October 2007
Area and Timing Optimization chapter in volume 2 of the Quartus II
Handbook
Command Line Scripting chapter in volume 2 of the Quartus II
Handbook
Engineering Change Management with the Chip Planner chapter in
volume 3 of the Quartus II Handbook
Introduction to Quartus II manual
PowerPlay Power Analysis chapter in volume 3 of the Quartus II
Handbook
Quartus II Classic Timing Analyzer chapter in volume 3 of the
Quartus II Handbook
Quartus II Integrated Synthesis chapter in volume 1 of the Quartus II
Handbook
Quartus II TimeQuest Timing Analyzer chapter in volume 3 of the
Quartus II Handbook
Tcl Scripting chapter in volume 2 of the Quartus II Handbook
Analyzing and Optimizing the Design Floorplan chapter in volume 2 of
the Quartus II Handbook
3–45
Quartus II Handbook, Volume 1
Document
Revision History
Table 3–5 show the revision history of this chapter.
Table 3–5. Document Revision History
Date and
Document Version
Changes Made
October 2007
v7.2.0
Reorganized “Referenced Documents”.
May 2007
v7.1.0
●
March 2007
v7.0.0
Consolidated the device support table (Table 1-3) to show
support for Stratix series and Cyclone series devices.
November 2006
v6.1.0
Added document revision history to chapter.
May 2006
v6.0.0
Minor updates for the Quartus II software version 6.0.
December 2005
v5.1.1
Minor typographic and formatting updates.
October 2005
v5.1.0
Updated for the Quartus II software version 5.1.
●
Added support for Arria GX in Table 3–1.
Added “Referenced Documents” section.
Summary of Changes
Updated for the
Quartus II 7.2 software
release.
Minor updates to
support Altera’s newest
device, Arria GX.
—
—
—
—
—
May 2005
v5.0.0
Chapter 2 was formerly Chapter 1 in version 4.2.
—
Dec. 2004
v2.1.0
Updated for Quartus II software version 4.2.
● Chapter 1 was formerly Chapter 2.
● General formatting, editing updates, and figure updates.
● FLEX® 600 device support added.
● Assignment Editor, Timing Assignments, and Synthesis
updated.
● APEX II support for balanced optimization technique
removed, MAX II support added.
● Minor updates to Place and Route.
● Tcl commands no longer supported for the Quartus II
Simulator Tool.
● Excel-based power calculator replaced by PowerPlay Early
Power Estimation spreadsheet.
● Added support for erase capability for CPLDs.
—
June 2004
v2.0
●
Feb. 2004
v1.0
Initial release.
3–46
●
Updates to tables, figures.
New functionality for Quartus II software 4.1.
—
—
Altera Corporation
October 2007
4. Quartus II Support for
HardCopy Series Devices
QII51004-7.2.0
Introduction
This chapter includes Quartus® II Support for HardCopy® II and
HardCopy Stratix® devices. This chapter is divided into the following
sections:
■
■
HardCopy II
Device Support
“HardCopy II Device Support” on page 4–1
“HardCopy Stratix Device Support” on page 4–34
Altera® HardCopy II devices feature 1.2-V, 90 nm process technology,
and provide a structured ASIC alternative to increasingly expensive
multi-million gate ASIC designs. The HardCopy II design methodology
offers a fast time-to-market schedule, providing ASIC designers with a
solution to long ASIC development cycles. Using the Quartus II software,
you can leverage a Stratix II FPGA as a prototype and seamlessly migrate
your design to a HardCopy II device for production.
This document discusses the following topics:
■
■
■
■
f
“HardCopy II Development Flow” on page 4–3
“HardCopy II Device Resource Guide” on page 4–8
“HardCopy II Recommended Settings in the Quartus II Software” on
page 4–12
“HardCopy II Utilities Menu” on page 4–25
For more information about HardCopy II, HardCopy Stratix, and
HardCopy APEX™ devices, refer to the respective device data sheets in
the HardCopy Series Handbook.
HardCopy II Design Benefits
Designing with HardCopy II structured ASICs offers substantial benefits
over other structured ASIC offerings:
■
■
■
Altera Corporation
October 2007
Prototyping using a Stratix II FPGA for functional verification and
system development reduces total project development time
Seamless migration from a Stratix II FPGA prototype to a
HardCopy II device reduces time to market and risk
Unified design methodology for Stratix II FPGA design and
HardCopy II design reduces the need for ASIC development
software
4–1
Preliminary
Quartus II Handbook, Volume 1
■
Low up-front development cost of HardCopy II devices reduces the
financial risk to your project
Quartus II Features for HardCopy II Planning
With the Quartus II software you can design a HardCopy II device using
a Stratix II device as a prototype. The Quartus II software contains the
following expanded features for HardCopy II device planning:
■
HardCopy II Companion Device Assignment—Identifies
compatible HardCopy II devices for migration with the Stratix II
device currently selected.
1
■
■
HardCopy II Utilities—The HardCopy II Utilities functions create
or overwrites HardCopy II companion revisions, change revisions to
use, and compare revisions for equivalency.
HardCopy II Advisor—The HardCopy II Advisor helps you follow
the necessary steps to successfully submit a HardCopy II design to
Altera’s HardCopy Design Center.
1
■
■
The HardCopy II Advisor is similar to the Resource
Optimization Advisor and Timing Optimization Advisor.
The HardCopy II Advisor provides guidelines you can
follow during development, reporting the tasks completed
as well as the tasks that remain to be completed during
development.
HardCopy II Floorplan—The Quartus II software can show a
preliminary floorplan view of your HardCopy II design’s Fitter
placement results.
HardCopy II Design Archiving—The Quartus II software archives
the HardCopy II design project’s files needed to handoff the design
to the HardCopy Design Center.
1
4–2
Preliminary
This feature constrains the pins of your Stratix II FPGA
prototype making it compatible with your HardCopy II
device. It also constrains the correct resources available for
the HardCopy II device making sure that your Stratix II
FPGA design does not become incompatible. In addition,
you are still required to compile the design targeting the
HardCopy II device to ensure that the design fits, routes,
and meets timing.
This feature is similar to the Quartus II software HardCopy
Files Wizard used for HardCopy Stratix and HardCopy
APEX families.
Altera Corporation
October 2007
HardCopy II Development Flow
■
■
■
HardCopy II
Development
Flow
HardCopy II Device Preliminary Timing—The Quartus II software
performs a timing analysis of HardCopy II devices based on
preliminary timing models and Fitter placements. Final timing
results for HardCopy II devices are provided by the HardCopy
Design Center.
HardCopy II Handoff Report-—The Quartus II software generates
a handoff report containing information about the HardCopy II
design used by the HardCopy Design Center in the design review
process.
Formal Verification—Cadence Encounter Conformal software can
now perform formal verification between the source RTL design files
and post-compile gate level netlist from a HardCopy II design.
In the Quartus II software, you have two methods for designing your
Stratix II FPGA and HardCopy II companion device together in one
Quartus II project.
■
■
Design the HardCopy II device first, and create the Stratix II FPGA
companion device second and build your prototype for in-system
verification
Design the Stratix II FPGA first and create a HardCopy II companion
device second
Both of these flows are illustrated at a high level in Figure 4–1. The added
features in the HardCopy II Utilities menu assist you in completing your
HardCopy II design for submission to Altera’s HardCopy Design Center
for back-end implementation.
Altera Corporation
October 2007
4–3
Preliminary
Quartus II Handbook, Volume 1
Figure 4–1. HardCopy II Flow in Quartus II Software
Prepare Design HDL
Design Stratix II First
Select Stratix II Device
& HardCopy II
Companion Device
Design Stratix II Second
Yes
Design
Stratix II
First?
No
Complete Stratix II
Device First Flow (1)
Select HardCopy II
Device & Stratix II
Companion Device
Complete HardCopy II
Device First Flow (2)
In-System Verification
of Stratix II
FPGA Design
Compare Stratix II
& HardCopy II
Design Revisions
Generate HardCopy II
Archive
Handoff Design Archive for
Back-End Migration
Notes for Figure 4–1:
(1)
(2)
Refer to Figure 4–2 on page 4–5 for an expanded description of this process.
Refer to Figure 4–3 on page 4–7 for an expanded description of this process.
Designing the Stratix II FPGA First
The HardCopy II development flow beginning with the Stratix II FPGA
prototype is very similar to a traditional Stratix II FPGA design flow, but
requires a few additional tasks be performed to migrate the design to the
HardCopy II companion device. To design your HardCopy II device
using the Stratix II FPGA as a prototype, complete the following tasks:
■
■
■
■
4–4
Preliminary
Specify a HardCopy II device for migration
Compile the Stratix II FPGA design
Create and compile the HardCopy II companion revision
Compare the HardCopy II companion revision compilation to the
Stratix II device compilation
Altera Corporation
October 2007
HardCopy II Development Flow
Figure 4–2 provides an overview highlighting the development process
for designing with a Stratix II FPGA first and creating a HardCopy II
companion device second.
Figure 4–2. Designing Stratix II Device First Flow
Stratix II Prototype Device Development Phase
Prepare Stratix II Design
Select HardCopy II Companion Device
Review HardCopy II Advisor
Apply Design Constraints
In-System Verification
Compile Stratix II Design
Any
Violations?
Yes
Fix Violations
No
Create or Overwrite HardCopy II
Companion Revision
HardCopy II Companion Device Development Phase
Compile HardCopy II Companion Revision
Select a Larger
HardCopy II Companion
Device?
Fits in
HardCopy II Device?
Compare Stratix II & HardCopy II Revisions
Any
Violations?
Yes
No
Design Submission & Back-End Implementation Phase
Generate Handoff Report
Archive Project for Handoff
Altera Corporation
October 2007
4–5
Preliminary
Quartus II Handbook, Volume 1
Prototype your HardCopy II design by selecting and then compiling a
Stratix II device in the Quartus II software.
After you compile the Stratix II design successfully, you can view the
HardCopy II Device Resource Guide in the Quartus II software Fitter
report to evaluate which HardCopy II devices meet your design’s
resource requirements. When you are satisfied with the compilation
results and the choice of Stratix II and HardCopy II devices, on the
Assignments menu, click Settings. In the Category list, select Device. In
the Device page, select a HardCopy II companion device.
After you select your HardCopy II companion device, do the following:
■
■
■
■
■
■
■
■
■
■
f
Review the HardCopy II Advisor for required and recommended
tasks to perform
Enable Design Assistant to run during compilation
Add timing and location assignments
Compile your Stratix II design
Create your HardCopy II companion revision
Compile your design for the HardCopy II companion device
Use the HardCopy II Utilities to compare the HardCopy II
companion device compilation with the Stratix II FPGA revision
Generate a HardCopy II Handoff Report using the HardCopy II
Utilities
Generate a HardCopy II Handoff Archive using the HardCopy II
Utilities
Arrange for submission of your HardCopy II handoff archive to
Altera’s HardCopy Design Center for back-end implementation
For more information about the overall design flow using the Quartus II
software, refer to the Introduction to Quartus II manual on the Altera
website at www.altera.com.
Designing the HardCopy II Device First
The HardCopy II family presents a new option in designing unavailable
in previous HardCopy families. You can design your HardCopy II device
first and create your Stratix II FPGA prototype second in the Quartus II
software. This allows you to see your potential maximum performance in
the HardCopy II device immediately during development, and you can
create a slower performing FPGA prototype of the design for in-system
verification. This design process is similar to the traditional HardCopy II
design flow where you build the FPGA first, but instead, you merely
change the starting device family. The remaining tasks to complete your
design for both Stratix II and HardCopy II devices roughly follow the
4–6
Preliminary
Altera Corporation
October 2007
HardCopy II Development Flow
same process (Figure 4–3). The HardCopy II Advisor adjusts its list of
tasks based on which device family you start with, Stratix II or
HardCopy II, to help you complete the process seamlessly.
Figure 4–3. Designing HardCopy II Device First Flow
Altera Corporation
October 2007
4–7
Preliminary
Quartus II Handbook, Volume 1
HardCopy II
Device Resource
Guide
The HardCopy II Device Resource Guide compares the resources
required to successfully compile a design with the resources available in
the various HardCopy II devices. The report rates each HardCopy II
device and each device resource for how well it fits the design. The
Quartus II software generates the HardCopy II Device Resource Guide
for all designs successfully compiled for Stratix II devices. This guide is
found in the Fitter folder of the Compilation Report. Figure 4–4 shows an
example of the HardCopy II Device Resource Guide. Refer to Table 4–1
for an explanation of the color codes in Figure 4–4.
Figure 4–4. HardCopy II Device Resource Guide
Use this report to determine which HardCopy II device is a potential
candidate for migration of your Stratix II design. The HardCopy II device
package must be compatible with the Stratix II device package. A logic
4–8
Preliminary
Altera Corporation
October 2007
HardCopy II Device Resource Guide
resource usage greater than 100% or a ratio greater than 1/1 in any
category indicates that the design does not fit in that particular
HardCopy II device.
Table 4–1. HardCopy II Device Resource Guide Color Legend
Color
Green
(High)
Package Resource (1)
The design can migrate to the Hardcopy II
package and the design has been fitted with
target device migration enabled in the
HardCopy II Companion Device dialog box.
The resource quantity is within the range of the
HardCopy II device and the design can likely
migrate if all other resources also fit.
You are still required to compile the HardCopy II
revision to make sure the design is able to route
and migrate all other resources.
The design can migrate to the Hardcopy II
package. However, the design has not been
fitted with target device migration enabled in the
HardCopy II Companion Device dialog box.
Orange
(Medium)
Red
(None)
Device Resources
The resource quantity is within the range of the
HardCopy II device. However, the resource is at
risk of exceeding the range for the HardCopy II
package.
If your target HardCopy II device falls in this
category, compile your design targeting the
HardCopy II device as soon as possible to check
if the design fits and is able to route and migrate
all other resources. You may need to migrate to
a larger device.
The design cannot migrate to the Hardcopy II
package.
The resource quantity exceeds the range of the
HardCopy II device. The design cannot migrate
to this HardCopy II device.
Note to Table 4–1:
(1)
The package resource is constrained by the Stratix II FPGA for which the design was compiled. Only vertical
migration devices within the same package are able to migrate to HardCopy II devices.
The HardCopy II architecture consists of an array of fine-grained HCells,
which are used to build logic equivalent to Stratix II adaptive logic
modules (ALMs) and digital signal processing (DSP) blocks. The DSP
blocks in HardCopy II devices match the functionality of the Stratix II
DSP blocks, though timing of these blocks is different than the FPGA DSP
blocks because they are constructed of HCell Macros. The M4K and
M-RAM memory blocks in HardCopy II devices are equivalent to the
Stratix II memory blocks. Preliminary timing reports of the HardCopy II
device are available in the Quartus II software. Final timing results of the
HardCopy II device are provided by the HardCopy Design Center after
back-end migration is complete.
Altera Corporation
October 2007
4–9
Preliminary
Quartus II Handbook, Volume 1
f
For more information about the HardCopy II device resources, refer to
the Introduction to HardCopy II Devices and the Description, Architecture
and Features chapters in the HardCopy II Device Family Data Sheet in the
HardCopy Series Handbook.
The report example in Figure 4–4 shows the resource comparisons for a
design compiled for a Stratix II EP2S130F1020 device. Based on the
report, the HC230F1020 device in the 1,020-pin FineLine BGA® package
is an appropriate HardCopy II device to migrate to. If the HC230F1020
device is not specified as a migration target during the compilation, its
package and migration compatibility is rated orange, or Medium. The
migration compatibilities of the other HardCopy II devices are rated red,
or None, because the package types are incompatible with the Stratix II
device. The 1,020-pin FBGA HC240 device is rated red because it is only
compatible with the Stratix II EP2S180F1020 device.
Figure 4–5 shows the report after the (unchanged) design was recompiled
with the HardCopy II HC230F1020 device specified as a migration target.
Now the HC230F1020 device package and migration compatibility is
rated green, or High.
Figure 4–5. HardCopy II Device Resource Guide with Target Migration Enabled
HardCopy II
Companion
Device Selection
In the Quartus II software, you can select a HardCopy II companion
device to help structure your design for migration from a Stratix II device
to a HardCopy II device. To make your HardCopy II companion device
selection, on the Assignments menu, click Settings. In the Settings dialog
box in the Category list, select Device (Figure 4–6) and select your
companion device from the Available devices list.
Selecting a HardCopy II Companion device to go with your Stratix II
prototype constrains the memory blocks, DSP blocks, and pin
assignments, so that your Stratix II and HardCopy II devices are
migration-compatible. Pin assignments are constrained in the Stratix II
design revision so that the HardCopy II device selected is
4–10
Preliminary
Altera Corporation
October 2007
HardCopy II Companion Device Selection
pin-compatible. The Quartus II software also constrains the Stratix II
design revision so it does not use M512 memory blocks or exceed the
number of M-RAM blocks in the HardCopy II companion device.
Figure 4–6. Quartus II Settings Dialog Box
You can also specify your HardCopy II companion device using the
following tool command language (Tcl) command:
set_global_assignment -name\
DEVICE_TECHNOLOGY_MIGRATION_LIST <HardCopy II Device Part Number>
For example, to select the HC230F1020 device as your HardCopy II
companion device for the EP2S130F1020C4 Stratix II FPGA, the Tcl
command is:
set_global_assignment -name\
DEVICE_TECHNOLOGY_MIGRATION_LIST HC230F1020C
Altera Corporation
October 2007
4–11
Preliminary
Quartus II Handbook, Volume 1
HardCopy II
Recommended
Settings in the
Quartus II
Software
The HardCopy II development flow involves additional planning and
preparation in the Quartus II software compared to a standard FPGA
design. This is because you are developing your design to be
implemented in two devices: a prototype of your design in a Stratix II
prototype FPGA, and a companion revision in a HardCopy II device for
production. You need additional settings and constraints to make the
Stratix II design compatible with the HardCopy II device and, in some
cases, you must remove certain settings in the design. This section
explains the additional settings and constraints necessary for your design
to be successful in both Stratix II FPGA and HardCopy II structured ASIC
devices.
Limit DSP and RAM to HardCopy II Device Resources
On the Assignments menu, click Settings to view the Settings dialog box.
In the Category list, select Device. In the Family list, select Stratix II.
Under Companion device, Limit DSP & RAM to HardCopy II device
resources is turned on by default (Figure 4–7). This maintains
compatibility between the Stratix II and HardCopy II devices by ensuring
your design does not use resources in the Stratix II device that are not
available in the selected HardCopy II device.
1
If you require additional memory blocks or DSP blocks for
debugging purposes using SignalTap® II, you can temporarily
turn this setting off to compile and verify your design in your
test environment. However, your final Stratix II and
HardCopy II designs submitted to Altera for back-end
migration must be compiled with this setting turned on.
Figure 4–7. Limit DSP & RAM to HardCopy II Device Resources Check Box
Enable Design Assistant to Run During Compile
You must use the Quartus II Design Assistant to check all HardCopy
series designs for design rule violations before submitting the designs to
the Altera HardCopy Design Center. Additionally, you must fix all
critical and high-level errors.
1
4–12
Preliminary
Altera recommends turning on the Design Assistant to run
automatically during each compile, so that during development,
you can see the violations you must fix.
Altera Corporation
October 2007
HardCopy II Recommended Settings in the Quartus II Software
f
For more information about the Design Assistant and the rules it uses,
refer to the Design Guidelines for HardCopy Series Devices chapter of the
HardCopy Series Handbook.
To enable the Design Assistant to run during compilation, on the
Assignment menu, click Settings. In the Category list, select Design
Assistant and turn on Run Design Assistant during compilation
(Figure 4–8) or by entering the following Tcl command in the Tcl Console:
set_global_assignment -name ENABLE_DRC_SETTINGS ON
Figure 4–8. Enabling Design Assistant
Timing Settings
Beginning in Quartus II Software version 7.1, TimeQuest is the
recommended timing analysis tool for all designs. Classic Timing
Analyzer is no longer supported and the HardCopy Design Center will
not accept any designs which use Classic Timing Analyzer for timing
closure.
If you are still using the Classic Timing Analyzer, Altera strongly
recommends that you switch to TimeQuest.
Altera Corporation
October 2007
4–13
Preliminary
Quartus II Handbook, Volume 1
1
For more information on how to switch to TimeQuest, refer to
the Switching to the TimeQuest Timing Analyzer chapter of the
Quartus II Handbook, volume 3, on the Altera website at
www.altera.com.
When you specify the TimeQuest analyzer as the timing analysis tool, the
TimeQuest analyzer guides the Fitter and analyzes timing results after
compilation.
TimeQuest
The TimeQuest Timing Analyzer is a powerful ASIC-style timing
analysis tool that validates timing in your design by using an
industry-standard constraint, analysis, and reporting methodology. You
can 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.
The TimeQuest Timing Analyzer is a complete static timing analysis tool
that you can use as a sign-off tool for Altera FPGAs and structured ASICs.
Setting Up the TimeQuest Timing Analyzer
If you want use TimeQuest for timing analysis, from the Assignments tab
in the Quartus II software, click on Timing Analysis Settings, and in the
pop-up window, click the Use TimeQuest Timing Analyzer during
compilation tab.
4–14
Preliminary
Altera Corporation
October 2007
HardCopy II Recommended Settings in the Quartus II Software
Use the following Tcl command to use TimeQuest as your timing analysis
engine:
set_global_assignment -name \
USE_TIMEQUEST_TIMING_ANALYZER ON
You can launch the TimeQuest analyzer in one of the following modes:
■
■
■
Directly from the Quartus II software
Stand-alone mode
Command-line mode
In order to perform a thorough Static Timing Analysis, you would need
to specify all the timing requirements. The most important timing
requirements are clocks and generated clocks, input and output delays,
false paths and multi-cycle paths, minimum and maximum delays.
In TimeQuest, clock latency, and recovery and removal analysis are
enabled by default.
f
For more information about TimeQuest, refer to the Quartus II TimeQuest
Timing Analyzer chapter in volume 3 of the Quartus II Handbook on the
Altera website at www.altera.com.
Constraints for Clock Effect Characteristics
The create_clock, create_generated_clock commands create
ideal clocks and do not account for board effects. In order to account for
clock effect characteristics, you can use the following commands:
■
■
1
set_clock_latency
set_clock_uncertainty
For more information about how to use these commands, refer
to the Quartus II TimeQuest Timing Analyzer chapter in volume 3
of the Quartus II Handbook.
Beginning in Quartus II version 7.1, you can use the new command
derive_clock_uncertainty to automatically derive the clock
uncertainties. This command is useful when you are not sure what the
clock uncertainties might be. The calculated clock uncertainty values are
based on I/O buffer, static phase errors (SPE) and jitter in the PLL's, clock
networks, and core noises.
Altera Corporation
October 2007
4–15
Preliminary
Quartus II Handbook, Volume 1
The derive_clock_uncertainty command applies inter-clock,
intra-clock, and I/O interface uncertainties. This command automatically
calculates and applies setup and hold clock uncertainties for each
clock-to-clock transfer found in your design.
In order to get I/O interface uncertainty, you must create a virtual clock,
then assign delays to the input/output ports by using the
set_input_delay and set_output_delay commands for that
virtual clock.
1
These uncertainties are applied in addition to those you
specified using the set_clock_uncertainty command.
However, if a clock uncertainty assignment for a source and
destination pair was already defined, the new one will be
ignored. In this case, you can use either the -overwrite
command to overwrite the previous clock uncertainty
command or manually remove them by using the
remove_clock_uncertainty command.
The syntax for the derive_clock_uncertainty is as follows:
derive_clock_uncertainty [-h | -help] [-long_help]
[-dtw] [-overwrite]
where the arguments are listed in Table 4–2:
Table 4–2. Arguments for derive_clock_uncertainty
Option
Description
-h | -help
Short help
-long_help
Long help with examples and possible return values
-dtw
Creates PLLJ_PLLSPE_INFO.txt file
-overwrite
Overwrites previously performed clock uncertainty assignments
When the dtw option is used, a PLLJ_PLLSPE_INFO.txt file is generated.
This file lists the name of the PLLs, as well as their jitter and SPE values
in the design. This text file can be used by HCII_DTW_CU_Calculator.
When this option is used, clock uncertainties are not calculated.
f
4–16
Preliminary
For more information on the derive_clock_uncertainty command,
refer to the Quartus II TimeQuest Timing Analyzer chapter in volume 3 of
the Quartus II Handbook.
Altera Corporation
October 2007
HardCopy II Recommended Settings in the Quartus II Software
Altera strongly recommends that you use the
derive_clock_uncertainty command in the HardCopy II revision.
The HardCopy Design Center will not be accepting designs that do not
have clock uncertainty constraint by either using the
derive_clock_uncertainty command or the HardCopy II Clock
Uncertainty Calculator, and then using the set_clock_uncertainty
command.
f
For more information on how to use the HardCopy II Clock Uncertainty
Calculator, refer to the HardCopy II Clock Uncertainty User Guide available
on the Altera website at www.altera.com.
Quartus II Software Features Supported for HardCopy II Designs
The Quartus II software supports optimization features for HardCopy II
prototype development, including:
■
■
■
■
■
Physical Synthesis Optimization
LogicLock Regions
PowerPlay Power Analyzer
Incremental Compilation (Synthesis and Fitter)
Maximum Fan-Out Assignments
Physical Synthesis Optimization
To enable Physical Synthesis Optimizations for the Stratix II FPGA
revision of the design, on the Assignments menu, click Settings. In the
Settings dialog box, in the Category list, select Fitter Settings. These
optimizations are migrated into the HardCopy II companion revision for
placement and timing closure. When designing with a HardCopy II
device first, physical synthesis optimizations can be enabled for the
HardCopy II device, and these post-fit optimizations are migrated to the
Stratix II FPGA revision.
LogicLock™ Regions
The use of LogicLock Regions in the Stratix II FPGA is supported for
designs migrating to HardCopy II. However, LogicLock Regions are not
passed into the HardCopy II Companion Revision. You can use
LogicLock in the HardCopy II design but you must create new
LogicLock Regions in the HardCopy II companion revision. In addition,
LogicLock Regions in HardCopy II devices can not have their properties
set to Auto Size. However, Floating LogicLock regions are supported.
HardCopy II LogicLock Regions must be manually sized and placed in
the floorplan. When LogicLock Regions are created in a HardCopy II
device, they start with width and height dimensions set to (1,1), and the
origin coordinates for placement are at X1_Y1 in the lower left corner of
Altera Corporation
October 2007
4–17
Preliminary
Quartus II Handbook, Volume 1
the floorplan. You must adjust the size and location of the LogicLock
Regions you created in the HardCopy II device before compiling the
design.
f
For information about using LogicLock Regions, refer to the Quartus II
Analyzing and Optimizing Design Floorplan chapter in volume 2 of the
Quartus II Handbook.
PowerPlay Power Analyzer
You can perform power estimation and analysis of your HardCopy II and
Stratix II devices using the PowerPlay Early Power Estimator. Use the
PowerPlay Power Analyzer for more accurate estimation of your device’s
power consumption. The PowerPlay Early Power Estimator is available
in the Quartus II software version 5.1 and later. The PowerPlay Power
Analyzer supports HardCopy II devices in version 6.0 and later of the
Quartus II software.
f
For more information about using the PowerPlay Power Analyzer, refer
to the Quartus II PowerPlay Power Analysis chapter in volume 3 of the
Quartus II Handbook on the Altera website at www.altera.com.
Incremental Compilation
The use of the Quartus II Incremental Compilation in the Stratix II FPGA
is supported when migrating a design to a HardCopy II device.
Incremental compilation is supported in the Stratix II First design flow or
HardCopy II First design flow.
To take advantage of Quartus II Incremental Compilation, organize your
design into logical and physical partitions for synthesis and fitting (or
place-and-route). Incremental compilation preserves the compilation
results and performance of unchanged partitions in your design. This
feature dramatically reduces your design iteration time by focusing new
compilations only on changed design partitions. New compilation results
are then merged with the previous compilation results from unchanged
design partitions. You can also target optimization techniques, such as
physical synthesis, to specific partitions while leaving other partitions
untouched.
In addition, be aware of the following guidelines:
●
●
4–18
Preliminary
User partitions and synthesis results are migrated to a
companion device.
LogicLock regions are suggested for user partitions, but are not
migrated automatically.
Altera Corporation
October 2007
HardCopy II Recommended Settings in the Quartus II Software
●
●
●
●
f
The first compilation after migration to a companion device
requires a full compilation (all partitions are compiled), but
subsequent compilations can be incremental if changes to the
source RTL are not required. For example, PLL phase changes
can be implemented incrementally if the blocks are partitioned.
The entire design must be migrated between Stratix II and
HardCopy II companion devices. The Quartus II software does
not support migration of partitions between companion
devices.
Bottom-up Quartus II Incremental Compilation is not supported
for HardCopy II devices.
Physical Synthesis can be run on individual partitions within
the originating device only. The resulting optimizations are
preserved in the migration to the companion device.
For information about using Quartus II Incremental Compilation, refer
to the Quartus II Incremental Compilation for Hierarchical and Team-Based
Design chapter in volume 1 of the Quartus II Handbook.
Maximum Fanout Assignments
This feature is supported beginning in Quartus II 6.1. In order to meet
timing, it may be necessary to limit the number of fanouts of a net in your
design. You can limit the maximum fanout of a given net by using this
feature.
For example, you can use the following Tcl command to enable the
maximum fanout setting:
set_instance_assignment -name MAX_FANOUT <number>
- to\ <net name>
For example, if you want to limit the maximum fanout of net called
"m3122_combout_1" to 25, the Tcl command is as follows:
set_instance_assignment -name MAX_FANOUT 25 -to\
m3122_combout_1
Altera Corporation
October 2007
4–19
Preliminary
Quartus II Handbook, Volume 1
Performing
ECOs with
Quartus II
Engineering
Change
Management
with the Chip
Planner
As designs grow larger and larger in density, the need to analyze the
design for performance, routing congestion, logic placement, and
executing Engineering Change Orders (ECOs) becomes critical. In
addition to design analysis, you can use various bottom-up and
top-down flows to implement and manage the design. This becomes
difficult to manage since ECOs are often implemented as last minute
changes to your design.
With the Altera Chip Planner tool, you can shorten the design cycle time
significantly. When changes are made to your design as ECOs, you do not
have to perform a full compilation in the Quartus II software. Instead,
you would make changes directly to the post place-and-route netlist,
generate a new programming file, test the revised design by performing
a gate-level simulation and timing analysis, and proceed to verify the fix
on the system (if you are using a Stratix II FPGA as a prototype). Once the
fix has been verified on the Stratix II FPGA, switch to the HardCopy II
revision, apply the same ECOs, run the timing analyzer and assembler,
perform a revision compare and then run the HardCopy II Netlist Writer
for design submission.
There are three scenarios from a migration point of view:
■
■
■
There are changes which can map one-to-one (that is, the same
change can be implemented on each architecture—Stratix II FPGA
and HardCopy II).
There are changes that must be implemented differently on the two
architectures to achieve the same result.
There are some changes that cannot be implemented on both
architectures.
The following sections outline the methods for migrating each of these
types of changes.
Migrating One-to-One Changes
One-to-one changes are implemented using identical commands in both
architectures. In general, such changes include those that affect only I/O
cells or PLL cells. Some examples of one-to-one changes are changes such
as creating, deleting or moving pins, changing pin or PLL properties, or
changing pin connectivity (provided the source and destination of the
connectivity changes are I/Os or PLLs). These can be implemented
identically on both architectures.
If such changes are exported to Tcl, a direct reapplication of the generated
Tcl script (with a minor text edit) on the companion revision should
implement the appropriate changes as follows:
4–20
Preliminary
Altera Corporation
October 2007
Performing ECOs with Quartus II Engineering Change Management with the Chip Planner
■
■
■
Export the changes from the Change Manager to Tcl.
Open the generated Tcl script, change the line "project_open
<project> -revision <revision>" to refer to the appropriate companion
revision.
Apply the Tcl script to the companion revision.
A partial list of examples of this type are as follows:
■
■
■
■
I/O creation, deletion, and moves
I/O property changes (for example, I/O standards, delay chain
settings, etc.)
PLL property changes
Connectivity changes between non-LCELL_COMB atoms (for
example, PLL to I/O, DSP to I/O, etc.)
Migrating Changes that Must be Implemented Differently
Some changes must be implemented differently on the two architectures.
Changes affecting the logic of the design may fall into this category.
Examples are LUTMASK changes, LC_COMB/HSADDER creation and
deletion, and connectivity changes not covered in the previous section.
Another example of this would be to have different PLL settings for the
Stratix II and the HardCopy II revisions.
f
For more information about how to use different PLL settings for the
Stratix II and HardCopy II Devices, refer to AN432: Using Different PLL
Settings Between Stratix II and HardCopy II Devices.
Table 4–3 summarizes suggested implementation for various changes.
Table 4–3. Implementation Suggestions for Various Changes (Part 1 of 2)
Change Type
Altera Corporation
October 2007
Suggested Implementation
LUTMASK changes
Because a single Stratix II atom may require
multiple HardCopy II atoms to implement, it may be
necessary to change multiple HardCopy II atoms to
implement the change, including adding or
modifying connectivity
Make/Delete LC_COMB
If you are using a Stratix II LC_COMB in extended
mode (7-LUT) or using a SHARE chain, you must
create multiple atoms to implement the same logic
functions in HardCopy II. Additionally, the
placement of the LC_COMB cell has no meaning in
the companion revision as the underlying
resources are different.
4–21
Preliminary
Quartus II Handbook, Volume 1
Table 4–3. Implementation Suggestions for Various Changes (Part 2 of 2)
Change Type
Suggested Implementation
Make/Delete LC_FF
The basic creation and deletion is the same on both
architectures. However, as with LC_COMB
creation and deletion, the location of an LC_FF in a
HardCopy II revision has no meaning in the
Stratix II revision and vice versa.
Editing Logic Connectivity
Because a Stratix II LCELL_COMB atom may have
to be broken up into several HardCopy II
LCELL_COMB atoms, the source or destination
ports for connectivity changes may need to be
analyzed to properly implement the change in the
companion revision.
Changes that Cannot be Migrated
A small set of changes cannot be implemented in the other architecture
because they do not make sense in the other architecture. The best
example of this occurs when moving logic in a design; because the logic
fabric is different between the two architectures, locations in Stratix II
make no sense in HardCopy II and vice versa.
Overall
Migration Flow
This section outlines the migration flow and the suggested procedure for
implementing changes in both revisions to ensure a successful Revision
Compare such that the design can be submitted to the HardCopy Design
Center.
Preparing the Revisions
The general procedure for migrating changes between devices is the
same, whether going from Stratix II to HardCopy II or vice versa. The
major steps are as follows:
1.
2.
3.
4.
Compile the design on the initial device.
Migrate the design from the initial device to the target device in the
companion revision.
Compile the companion revision.
Perform a Revision Compare operation. The two revisions should
pass the Revision Compare.
If testing identifies problems requiring ECO changes, equivalent changes
can be applied to both Stratix II and HardCopy II revisions, as described
in the next section.
4–22
Preliminary
Altera Corporation
October 2007
Overall Migration Flow
Applying ECO Changes
The general flow for applying equivalent changes in companion revisions
is as follows:
1.
Make changes in one revision using the Chip Planner tools (Chip
Planner, Resource Property Editor, and Change Manager), then
verify and export these changes. The procedure for doing this is as
follows:
a. Make changes using the Chip Planner tool.
b.
Perform a netlist check using the Check and Save All Netlist
Changes command.
c.
Verify correctness using timing analysis, simulation, and
prototyping (Stratix II only). If more changes are required,
repeat steps a-b.
d.
Export change records from the Change Manager to Tcl scripts,
or .csv or .txt file formats.
This exported file is used to assist in making the equivalent
changes in the companion revision.
2.
Open the companion revision in the Quartus II software.
3.
Using the exported file, manually reapply the changes using the
Chip Planner tool.
As stated previously, some changes can be reapplied directly to the
companion revision (either manually or by applying the Tcl
commands), while others require some modifications.
4.
Perform a Revision Compare operation. The revisions should now
match once again.
5.
Verify the correctness of all changes (you may need to run timing
analysis).
6.
Run the HardCopy II Assembler and the HardCopy II Netlist Writer
for design submission along with handoff files.
The Tcl command for running the HardCopy II Assembler is as follows:
execute_module -tool asm -args "-read_settings_files=\ off --write_settings_files=off"
Altera Corporation
October 2007
4–23
Preliminary
Quartus II Handbook, Volume 1
The Tcl command for the HardCopy II Netlist Writer is as follows:
execute_module -tool cdb \
-args "--generate_hardcopyii_files"\
f
Formal
Verification of
Stratix II and
HardCopy II
Revisions
For more information about using Chip Planner, refer to the Quartus II
Engineering Change Management with Chip Planner chapter in volume 3 of
the Quartus II Handbook at www.altera.com.
Third-party formal verification software is available for your
HardCopy II design. Cadence Encounter Conformal verification software
is used for Stratix II and HardCopy II families, as well as several other
Altera product families.
To use the Conformal software with the Quartus II software project for
your Stratix II and HardCopy II design revisions, you must enable the
EDA Netlist Writer. It is necessary to turn on the EDA Netlist Writer so
it can generate the necessary netlists and command files needed to run the
Conformal software. To automatically run the EDA Netlist Writer during
the compile of your Stratix II and HardCopy II design revisions, perform
the following steps:
1.
On the Assignment menu, click EDA Tool Settings. The Settings
dialog box displays.
2.
In the EDA Tool Settings list, select Formal Verification, and in the
Tool name list, select Conformal LEC.
3.
Compile your Stratix II and Hardcopy II design revisions, with both
the EDA Tool Settings and the Conformal LEC turned on so the
EDA Netlist Writer automatically runs.
The Quartus II EDA Netlist Writer produces one netlist for Stratix II
when it is run on that revision, and generates a second netlist when it runs
on the HardCopy II revision. You can compare your Stratix II
post-compile netlist to your RTL source code using the scripts generated
by the EDA Netlist Writer. Similarly, you can compare your HardCopy II
post-compile netlist to your RTL source code with scripts provided by
the EDA Netlist Writer.
f
4–24
Preliminary
For more information about using the Cadence Encounter Conformal
verification software, refer to the Cadence Encounter Conformal Support
chapter in volume 3 of the Quartus II Handbook.
Altera Corporation
October 2007
HardCopy II Utilities Menu
HardCopy II
Utilities Menu
The HardCopy II Utilities menu in the Quartus II software is shown
Figure 4–9. To access this menu, on the Project menu, click HardCopy II
Utilities. This menu contains the main functions you use to develop your
HardCopy II design and Stratix II FPGA prototype companion revision.
From the HardCopy II Utilities menu, you can:
■
■
■
■
■
■
Create or update HardCopy II companion revisions
Set which HardCopy II companion revision is the current revision
Generate a HardCopy II Handoff Report for design reviews
Archive HardCopy II Handoff Files for submission to the HardCopy
Design Center
Compare the companion revisions for functional equivalence
Track your design progress using the HardCopy II Advisor
Figure 4–9. HardCopy II Utilities Menu
Altera Corporation
October 2007
4–25
Preliminary
Quartus II Handbook, Volume 1
Each of the features within HardCopy II Utilities is summarized in
Table 4–4. The process for using each of these features is explained in the
following sections.
Table 4–4. HardCopy II Utilities Menu Options
Menu
Description
Applicable Design
Revision
Restrictions
Create a new companion
Create/Overwrite
revision or update an existing
HardCopy II
Companion Revision companion revision for your
Stratix II and HardCopy II
design.
Stratix II prototype
design and HardCopy II
Companion Revision
Specify which companion
Set Current
revision to associate with
HardCopy II
Companion Revision current design revision.
Companion Revision must
Stratix II prototype
design and HardCopy II already exist
Companion Revision
Compare
HardCopy II
Companion
Revisions
●
Generate a Quartus II Archive HardCopy II
File specifically for submitting Companion Revision
the design to the HardCopy
Design Center. Similar to the
HardCopy Files Wizard for
HardCopy Stratix and APEX.
●
●
●
●
●
HardCopy II Advisor
Must disable Auto Device
selection
Must set a Stratix II device
and a HardCopy II
companion device
Compilation of both revisions
Compares the Stratix II design Stratix II prototype
revision with the HardCopy II design and HardCopy II must be complete
Companion Revision
companion design revision
and generates a report.
Generate a report containing Stratix II prototype
Generate
HardCopy II Handoff important design information design and HardCopy II
files and messages generated Companion Revision
Report
by the Quartus II compile
Archive HardCopy II
Handoff Files
●
Compilation of both
revisions must be complete
Compare HardCopy II
Companion Revisions
must have been executed
Compilation of both
revisions must be
completed
Compare HardCopy II
Companion Revisions
must have been executed
Generate HardCopy
Handoff Report must have
been executed
None
Open an Advisor, similar to the Stratix II prototype
design and HardCopy II
Resource Optimization
Companion Revision
Advisor, helping you through
the steps of creating a
HardCopy II project.
Companion Revisions
HardCopy II designs follow a different development flow in the
Quartus II software compared with previous HardCopy families. You
can create multiple revisions of your Stratix II prototype design, but you
can also create separate revisions of your design for a HardCopy II
device. The Quartus II software creates specific HardCopy II design
4–26
Preliminary
Altera Corporation
October 2007
HardCopy II Utilities Menu
revisions of the project in conjunction to the regular project revisions.
These parallel design revisions for HardCopy II devices are called
companion revisions.
1
Although you can create multiple project revisions, Altera
recommends that you maintain only one Stratix II FPGA
revision once you have created the HardCopy II companion
revision.
When you have successfully compiled your Stratix II prototype FPGA,
you can create a HardCopy II companion revision of your design and
proceed with compiling the HardCopy II companion revision. To create
a companion revision, on the Project menu, point to HardCopy II Utilities
and click Create/Overwrite HardCopy II Companion Revision. Use the
dialog box to create a new companion revision or overwrite an existing
companion revision (Figure 4–10).
Figure 4–10. Create or Overwrite HardCopy II Companion Revision
You can associate only one Stratix II revision to one HardCopy II
companion revision. If you created more than one revision or more than
one companion revision, set the current companion for the revision you
are working on. On the Project menu, point to HardCopy II Utilities and
click Set Current HardCopy II Companion Revision (Figure 4–11).
Figure 4–11. Set Current HardCopy II Companion Revision
Altera Corporation
October 2007
4–27
Preliminary
Quartus II Handbook, Volume 1
Compiling the HardCopy II Companion Revision
The Quartus II software allows you to compile your HardCopy II design
with preliminary timing information. The timing constraints for the
HardCopy II companion revision can be the same as the Stratix II design
used to create the revision. The Quartus II software contains preliminary
timing models for HardCopy II devices and you can gauge how much
performance improvement you can achieve in the HardCopy II device
compared to the Stratix II FPGA. Altera verifies that the HardCopy II
Companion Device timing requirements are met in the HardCopy Design
Center.
After you create your HardCopy II companion revision from your
compiled Stratix II design, select the companion revision in the Quartus II
software design revision drop-down box (Figure 4–12) or from the
Revisions list. Compile the HardCopy II companion revision. After the
Quartus II software compiles your design, you can perform a comparison
check of the HardCopy II companion revision to the Stratix II prototype
revision.
Figure 4–12. Changing Current Revision
Comparing HardCopy II and Stratix II Companion Revisions
Altera uses the companion revisions in a single Quartus II project to
maintain the seamless migration of your design from a Stratix II FPGA to
a HardCopy II structured ASIC. This methodology allows you to design
with one set of Register Transfer Level (RTL) code to be used in both
Stratix II FPGA and HardCopy II structured ASIC, guaranteeing
functional equivalency.
When making changes to companion revisions, use the Compare
HardCopy II Companion Revisions feature to ensure that your Stratix II
design matches your HardCopy II design functionality and compilation
settings. To compare companion revisions, on the Project menu, point to
HardCopy II Utilities and click Compare HardCopy II Companion
Revisions.
1
4–28
Preliminary
You must perform this comparison after both Stratix II and
HardCopy II designs are compiled in order to hand off the
design to Altera’s HardCopy Design Center.
Altera Corporation
October 2007
HardCopy II Utilities Menu
The Comparison Revision Summary is found in the Compilation Report
and identifies where assignments were changed between revisions or if
there is a change in the logic resource count due to different compilation
settings.
Generate a HardCopy II Handoff Report
In order to submit a design to the HardCopy Design Center, you must
generate a HardCopy II Handoff Report providing important
information about the design that you want the HardCopy Design Center
to review. To generate the HardCopy II Handoff Report, you must:
■
■
Successfully compile both Stratix II and HardCopy II revisions of
your design
Successfully run the Compare HardCopy II Companion Revisions
utility
Once you generate the HardCopy II Handoff Report, you can archive the
design using the Archive HardCopy II Handoff Files utility described in
“Archive HardCopy II Handoff Files” on page 4–29.
Archive HardCopy II Handoff Files
The last step in the HardCopy II design methodology is to archive the
HardCopy II project for submission to the HardCopy Design Center for
back-end migration. The HardCopy II archive utility creates a different
Quartus II Archive File than the standard Quartus II project archive
utility generates. This archive contains only the necessary data from the
Quartus II project needed to implement the design in the HardCopy
Design Center.
In order to use the Archive HardCopy II Handoff Files utility, you must
complete the following:
■
■
■
Compile both the Stratix II and HardCopy II revisions of your design
Run the Compare HardCopy II Revisions utility
Generate the HardCopy II Handoff Report
To select this option, on the Project menu, point to HardCopy II Utilities
and click Archive HardCopy II Handoff File utility.
Altera Corporation
October 2007
4–29
Preliminary
Quartus II Handbook, Volume 1
HardCopy II Advisor
The HardCopy II Advisor provides the list of tasks you should follow to
develop your Stratix II prototype and your HardCopy II design. To run
the HardCopy II Advisor, on the Project menu, point to HardCopy II
Utilities and click HardCopy II Advisor. The following list highlights the
checkpoints that the HardCopy II Advisor reviews. This list includes the
major check points in the design process; it does not show every step in
the process for completing your Stratix II and HardCopy II designs:
1.
Select a Stratix II device.
2.
Select a HardCopy II device.
3.
Turn on the Design Assistant.
4.
Set up timing constraints.
5.
Check for incompatible assignments.
6.
Compile and check the Stratix II design.
7.
Create or overwrite the companion revision.
8.
Compile and check the HardCopy II companion results.
9.
Compare companion revisions.
10. Generate a Handoff Report.
11. Archive Handoff Files and send to Altera.
The HardCopy II Advisor shows the necessary steps that pertain to your
current selected device. The Advisor shows a slightly different view for a
design with Stratix II selected as compared to a design with HardCopy II
selected.
In the Quartus II software, you can start designing with the HardCopy II
device selected first, and build a Stratix II companion revision second.
When you use this approach, the HardCopy II Advisor task list adjusts
automatically to guide you from HardCopy II development through
Stratix II FPGA prototyping, then completes the comparison archiving
and handoff to Altera.
When your design uses the Stratix II FPGA as your starting point, Altera
recommends following the Advisor guidelines for your Stratix II FPGA
until you complete the prototype revision.
4–30
Preliminary
Altera Corporation
October 2007
HardCopy II Utilities Menu
When the Stratix II FPGA design is complete, create and switch to your
HardCopy II companion revision and follow the Advisor steps shown in
that revision until you are finished with the HardCopy II revision and are
ready to submit the design to Altera for back-end migration.
Each category in the HardCopy II Advisor list has an explanation of the
recommended settings and constraints, as well as quick links to the
features in the Quartus II software that are needed for each section. The
HardCopy II Advisor displays:
■
■
■
1
A green check box when you have successfully completed one of the
steps
A yellow caution sign for steps that must be completed before
submitting your design to Altera for HardCopy development
An information callout for items you must verify
Selecting an item within the HardCopy II flow menu provides a
description of the task and recommended action. The view in
the HardCopy II Advisor differs depending on the device you
select.
Figure 4–13 shows the HardCopy II Advisor with the Stratix II device
selected.
Figure 4–13. HardCopy II Advisor with Stratix II Selected
Altera Corporation
October 2007
4–31
Preliminary
Quartus II Handbook, Volume 1
Figure 4–14 shows the HardCopy II Advisor with the HardCopy II device
selected.
Figure 4–14. HardCopy II Advisor with HardCopy II Device Selected
HardCopy II Floorplan View
The Quartus II software displays the preliminary timing closure
floorplan and placement of your HardCopy II companion revision. This
floorplan shows the preliminary placement and connectivity of all I/O
pins, PLLs, memory blocks, HCell macros, and DSP HCell macros.
Congestion mapping of routing connections can be viewed using the
Layers Setting dialog box (in the View menu) settings. This is useful in
analyzing densely packed areas of your floorplan that could be reducing
the peak performance of your design. The HardCopy Design Center
verifies final HCell macro timing and placement to guarantee timing
closure is achieved.
4–32
Preliminary
Altera Corporation
October 2007
HardCopy II Utilities Menu
Figure 4–15 shows an example of the HC230F1020 device floorplan.
Figure 4–15. HC230F1020 Device Floorplan
In this small example design, the logic is placed near the bottom edge.
You can see the placement of a DSP block constructed of HCell Macros,
various logic HCell Macros, and an M4K memory block. A labeled
close-up view of this region is shown in Figure 4–16.
Figure 4–16. Close-Up View of Floorplan
Altera Corporation
October 2007
4–33
Preliminary
Quartus II Handbook, Volume 1
The HardCopy Design Center performs final placement and timing
closure on your HardCopy II design based on the timing constraints
provided in the Stratix II design.
f
HardCopy Stratix
Device Support
For more information about the HardCopy Design Center’s process,
refer to the Back-End Design Flow for HardCopy Series Devices chapter in
volume 1 of the HardCopy Series Device Handbook.
Altera HardCopy devices provide a comprehensive alternative to ASICs.
HardCopy structured ASICs offer a complete solution from prototype to
high-volume production, and maintain the powerful features and
high-performance architecture of their equivalent FPGAs with the
programmability removed. You can use the Quartus II design software to
design HardCopy devices in a manner similar to the traditional ASIC
design flow and you can prototype with Altera’s high density Stratix,
APEX 20KC, and APEX 20KE FPGAs before seamlessly migrating to the
corresponding HardCopy device for high-volume production.
HardCopy structured ASICs provide the following key benefits:
■
■
■
■
■
Improves performance, on the average, by 40% over the
corresponding -6 speed grade FPGA device
Lowers power consumption, on the average, by 40% over the
corresponding FPGA
Preserves the FPGA architecture and features and minimizes risk
Guarantees first-silicon success through a proven, seamless
migration process from the FPGA to the equivalent HardCopy
device
Offers a quick turnaround of the FPGA design to a structured ASIC
device—samples are available in about eight weeks
Altera’s Quartus II software has built-in support for HardCopy Stratix
devices. The HardCopy design flow in Quartus II software offers the
following advantages:
■
■
■
■
4–34
Preliminary
Unified design flow from prototype to production
Performance estimation of the HardCopy Stratix device allows you
to design systems for maximum throughput
Easy-to-use and inexpensive design tools from a single vendor
An integrated design methodology that enables system-on-a-chip
designs
Altera Corporation
October 2007
Features
This section discusses the following areas:
■
■
■
■
Features
Altera Corporation
October 2007
How to design HardCopy Stratix and HardCopy APEX structured
ASICs using the Quartus II software
An explanation of what the HARDCOPY_FPGA_PROTOTYPE
devices are and how to target designs to these devices
Performance and power estimation of HardCopy Stratix devices
How to generate the HardCopy design database for submitting
HardCopy Stratix and HardCopy APEX designs to the HardCopy
Design Center
Beginning with version 4.2, the Quartus II software contains several
powerful features that facilitate design of HardCopy Stratix and
HardCopy APEX devices:
■
HARDCOPY_FPGA_PROTOTYPE Devices
These are virtual Stratix FPGA devices with features identical to
HardCopy Stratix devices. You must use these FPGA devices to
prototype your designs and verify the functionality in silicon.
■
HardCopy Timing Optimization Wizard
Using this feature, you can target your design to HardCopy Stratix
devices, providing an estimate of the design’s performance in a
HardCopy Stratix device.
■
HardCopy Stratix Floorplans and Timing Models
The Quartus II software supports post-migration HardCopy Stratix
device floorplans and timing models and facilitates design
optimization for design performance.
■
Placement Constraints
Location and LogicLock constraints are supported at the HardCopy
Stratix floorplan level to improve overall performance.
■
Improved Timing Estimation
Beginning with version 4.2, the Quartus II software determines
routing and associated buffer insertion for HardCopy Stratix
designs, and provides the Timing Analyzer with more accurate
information about the delays than was possible in previous versions
of the Quartus II software. The Quartus II Archive File automatically
receives buffer insertion information, which greatly enhances the
timing closure process in the back-end migration of your HardCopy
Stratix device.
4–35
Preliminary
Quartus II Handbook, Volume 1
f
HARDCOPY_FPGA
_PROTOTYPE,
HardCopy Stratix
and Stratix
Devices
■
Design Assistant
This feature checks your design for compliance with all HardCopy
device design rules and establishes a seamless migration path in the
quickest time.
■
HardCopy Files Wizard
This wizard allows you to deliver to Altera the design database and
all the deliverables required for migration. This feature is used for
HardCopy Stratix and HardCopy APEX devices.
The HardCopy Stratix and HardCopy APEX PowerPlay Early Power
Estimator is available on the Altera website at www.altera.com.
You must use the HARDCOPY_FPGA_PROTOTYPE virtual devices
available in the Quartus II software to target your designs to the actual
resources and package options available in the equivalent post-migration
HardCopy Stratix device. The programming file generated for the
HARDCOPY_FPGA_PROTOTYPE can be used in the corresponding
Stratix FPGA device.
The purpose of the HARDCOPY_FPGA_PROTOTYPE is to guarantee
seamless migration to HardCopy by making sure that your design only
uses resources in the FPGA that can be used in the HardCopy device after
migration. You can use the equivalent Stratix FPGAs to verify the
design’s functionality in-system, then generate the design database
necessary to migrate to a HardCopy device. This process ensures the
seamless migration of the design from a prototyping device to a
production device in high volume. It also minimizes risk, assures samples
in about eight weeks, and guarantees first-silicon success.
1
HARDCOPY_FPGA_PROTOTYPE devices are only available
for HardCopy Stratix devices and are not available for the
HardCopy II or HardCopy APEX device families.
Table 4–5 compares HARDCOPY_FPGA_PROTOTYPE devices, Stratix
devices, and HardCopy Stratix devices.
Table 4–5. Qualitative Comparison of HARDCOPY_FPGA_PROTOTYPE to Stratix and HardCopy Stratix
Devices (Part 1 of 2)
Stratix Device
HARDCOPY_FPGA_PROTOTYPE Device
HardCopy Stratix Device
FPGA
Virtual FPGA
Structured ASIC
FPGA
Architecture identical to Stratix FPGA
Architecture identical to Stratix FPGA
4–36
Preliminary
Altera Corporation
October 2007
HARDCOPY_FPGA_PROTOTYPE, HardCopy Stratix and Stratix Devices
Table 4–5. Qualitative Comparison of HARDCOPY_FPGA_PROTOTYPE to Stratix and HardCopy Stratix
Devices (Part 2 of 2)
Stratix Device
HARDCOPY_FPGA_PROTOTYPE Device
HardCopy Stratix Device
FPGA
Resources identical to HardCopy Stratix device
M-RAM resources different than
Stratix FPGA in some devices
Ordered through
Altera part number
Cannot be ordered, use the Altera Stratix FPGA
part number
Ordered by Altera part number
Table 4–6 lists the resources available in each of the HardCopy Stratix
devices.
Table 4–6. HardCopy Stratix Device Physical Resources
LEs
ASIC Equivalent
Gates (K) (1)
M512
Blocks
M4K
Blocks
M-RAM
Blocks
DSP
Blocks
PLLs
Maximum
User I/O Pins
25,660
250
224
138
2
10
6
473
Device
HC1S25F672
HC1S30F780
32,470
325
295
171
2 (2)
12
6
597
HC1S40F780
41,250
410
384
183
2 (2)
14
6
615
HC1S60F1020
57,120
570
574
292
6
18
12
773
HC1S80F1020
79,040
800
767
364
6 (2)
22
12
773
Notes to Table 4–6:
(1)
(2)
Combinational and registered logic do not include DSP blocks, on-chip RAM, or PLLs.
The M-RAM resources for these HardCopy devices differ from the corresponding Stratix FPGA.
For a given device, the number of available M-RAM blocks in
HardCopy Stratix devices is identical with the corresponding
HARDCOPY_FPGA_PROTOTYPE devices, but may be different from
the corresponding Stratix devices. Maintaining the identical resources
between HARDCOPY_FPGA_PROTOTYPE and HardCopy Stratix
devices facilitates seamless migration from the FPGA to the structured
ASIC device.
f
For more information about HardCopy Stratix devices, refer to the
HardCopy Stratix Device Family Data Sheet section in volume 1 of the
HardCopy Series Handbook.
The three devices, Stratix FPGA, HARDCOPY_FPGA_PROTOTYPE, and
HardCopy device, are distinct devices in the Quartus II software. The
HARDCOPY_FPGA_PROTOTYPE programming files are used in the
Stratix FPGA for your design. The three devices are tied together with the
same netlist, thus a single SRAM Object File (.sof) can be used to achieve
the various goals at each stage. The same SRAM Object File is generated
Altera Corporation
October 2007
4–37
Preliminary
Quartus II Handbook, Volume 1
in the HARDCOPY_FPGA_PROTOTYPE design, and is used to program
the Stratix FPGA device, the same way that it is used to generate the
HardCopy Stratix device, guaranteeing a seamless migration.
f
HardCopy
Design Flow
For more information about the SRAM Object File and programming
Stratix FPGA devices, refer to the Programming and Configuration chapter
of the Introduction to Quartus II Manual.
Figure 4–17 shows a HardCopy design flow diagram. The design steps
are explained in detail in the following sections of this chapter. The
HardCopy Stratix design flow utilizes the HardCopy Timing
Optimization Wizard to automate the migration process into a one-step
process. The remainder of this section explains the tasks performed by
this automated process.
For a detailed description of the HardCopy Timing Optimization Wizard
and HardCopy Files Wizard, refer to “HardCopy Timing Optimization
Wizard” on page 4–42 and “Generating the HardCopy Design Database”
on page 4–53.
4–38
Preliminary
Altera Corporation
October 2007
HardCopy Design Flow
Figure 4–17. HardCopy Stratix and HardCopy APEX Design Flow Diagram
Start Quartus HardCopy Flow
Stratix
Select Stratix
HARDCOPY_FPGA_PROTOTYPE
Device
Compile
APEX
Select FPGA Family
Select APEX FPGA
Device Supported by
HardCopy APEX
One Step Process (3)
Two Step Process (2)
Compile
Compile
Mirgrate the
Compiled Project
Migrate Only (1)
Migrate the
Compiled Project
Migrate the
Compiled Project
Close the Quartus II
FPGA Project
Close the Quartus II
FPGA Project
Close the Quartus II
FPGA Project
Open the Quartus II
HardCopy Project
Open the Quartus II
HardCopy Project
Open the Quartus II
HardCopy Project
Compile to HardCopy
Stratix Device (Actual
HardCopy Floorplan)
Compile to HardCopy
Stratix Device (Actual
HardCopy Floorplan)
Compile to HardCopy
Stratix Device (Actual
HardCopy Floorplan)
Placement
Info for
HardCopy
Run HardCopy Files
Wizard (Quartus II
Archive File for
delivery to Altera)
Notes for Figure 4–17:
(1)
(2)
(3)
Migrate-Only Process: The displayed flow is completed manually.
Two-Step Process: Migration and Compilation are done automatically (shaded area).
One-Step Process: Full HardCopy Compilation. The entire process is completed automatically (shaded area).
The Design Flow Steps of the One-Step Process
The following sections describe each step of the full HardCopy
compilation (the One Step Process), as shown in Figure 4–17.
Compile the Design for an FPGA
This step compiles the design for a HARDCOPY_FPGA_PROTOTYPE
device and gives you the resource utilization and performance of the
FPGA.
Altera Corporation
October 2007
4–39
Preliminary
Quartus II Handbook, Volume 1
Migrate the Compiled Project
This step generates the Quartus II Project File (.qpf) and the other files
required for HardCopy implementation. The Quartus II software also
assigns the appropriate HardCopy Stratix device for the design
migration.
Close the Quartus FPGA Project
Because you must compile the project for a HardCopy Stratix device, you
must close the existing project which you have targeted your design to a
HARDCOPY_FPGA_PROTOTYPE device.
Open the Quartus HardCopy Project
Open the Quartus II project that you created in the “Migrate the
Compiled Project” step. The selected device is one of the devices from the
HardCopy Stratix family that was assigned during that step.
Compile for HardCopy Stratix Device
Compile the design for a HardCopy Stratix device. After successful
compilation, the Timing Analysis section of the compilation report shows
the performance of the design implemented in the HardCopy device.
How to Design
HardCopy Stratix
Devices
This section describes the process for designing for a HardCopy Stratix
device using the HARDCOPY_FPGA_PROTOTYPE as your initial
selected device. In order to use the HardCopy Timing Optimization
Wizard, you must first design with the
HARDCOPY_FPGA_PROTOTYPE in order for the design to migrate to a
HardCopy Stratix device.
To target a design to a HardCopy Stratix device in the Quartus II
software, follow these steps:
4–40
Preliminary
1.
If you have not yet done so, create a new project or open an existing
project.
2.
On the Assignments menu, click Settings. In the Category list, select
Device.
3.
On the Device page, in the Family list, select Stratix. Select the
desired HARDCOPY_FPGA_PROTOTYPE device in the Available
Devices list (Figure 4–18).
Altera Corporation
October 2007
How to Design HardCopy Stratix Devices
Figure 4–18. Selecting a HARDCOPY_FPGA_PROTOTYPE Device
By choosing the HARDCOPY_FPGA_PROTOTYPE device, all the
design information, available resources, package option, and pin
assignments are constrained to guarantee a seamless migration of
your project to the HardCopy Stratix device. The netlist resulting
from the HARDCOPY_FPGA_PROTOTYPE device compilation
contains information about the electrical connectivity, resources
used, I/O placements, and the unused resources in the FPGA device.
Altera Corporation
October 2007
4.
On the Assignments menu, click Settings. In the Category list, select
HardCopy Settings and specify the input transition timing to be
modeled for both clock and data input pins. These transition times
are used in static timing analysis during back-end timing closure of
the HardCopy device.
5.
Add constraints to your HARDCOPY_FPGA_PROTOTYPE device,
and on the Processing menu, click Start Compilation to compile the
design.
4–41
Preliminary
Quartus II Handbook, Volume 1
HardCopy Timing Optimization Wizard
After you have successfully compiled your design in the
HARDCOPY_FPGA_PROTOTYPE, you must migrate the design to the
HardCopy Stratix device to get a performance estimation of the
HardCopy Stratix device. This migration is required before submitting
the design to Altera for the HardCopy Stratix device implementation. To
perform the required migration, on the Project menu, point to HardCopy
Utilities and click HardCopy Timing Optimization Wizard.
At this point, you are presented with the following three choices to target
the designs to HardCopy Stratix devices (Figure 4–19):
■
Migration Only: You can select this option after compiling the
HARDCOPY_FPGA_PROTOTYPE project to migrate the project to a
HardCopy Stratix project.
You can now perform the following tasks manually to target the
design to a HardCopy Stratix device. Refer to“Performance
Estimation” on page 4–45 for additional information about how to
perform these tasks.
●
Close the existing project
●
Open the migrated HardCopy Stratix project
●
Compile the HardCopy Stratix project for a HardCopy Stratix
device
4–42
Preliminary
■
Migration and Compilation: You can select this option after
compiling the project. This option results in the following actions:
●
Migrating the project to a HardCopy Stratix project
●
Opening the migrated HardCopy Stratix project and compiling
the project for a HardCopy Stratix device
■
Full HardCopy Compilation: Selecting this option results in the
following actions:
●
Compiling the existing HARDCOPY_FPGA_PROTOTYPE
project
●
Migrating the project to a HardCopy Stratix project
●
Opening the migrated HardCopy Stratix project and compiling
it for a HardCopy Stratix device
Altera Corporation
October 2007
How to Design HardCopy Stratix Devices
Figure 4–19. HardCopy Timing Optimization Wizard Options
The main benefit of the HardCopy Timing Wizard’s three options is
flexibility of the conversion process automation. The first time you
migrate your HARDCOPY_FPGA_PROTOTYPE project to a HardCopy
Stratix device, you may want to use Migration Only, and then work on
the HardCopy Stratix project in the Quartus II software. As your
prototype FPGA project and HardCopy Stratix project constraints
stabilize and you have fewer changes, the Full HardCopy Compilation is
ideal for one-click compiling of your HARDCOPY_FPGA_PROTOTYPE
and HardCopy Stratix projects.
Altera Corporation
October 2007
4–43
Preliminary
Quartus II Handbook, Volume 1
After selecting the wizard you want to run, the “HardCopy Timing
Optimization Wizard: Summary” page shows you details about the
settings you made in the Wizard, as shown in Figure 4–20.
Figure 4–20. HardCopy Timing Optimization Wizard Summary Page
When either of the second two options in Figure 4–19 are selected
(Migration and Compilation or Full HardCopy Compilation), designs
are targeted to HardCopy Stratix devices and optimized using the
HardCopy Stratix placement and timing analysis to estimate
performance. For details on the performance optimization and estimation
steps, refer to “Performance Estimation” on page 4–45. If the performance
requirement is not met, you can modify your RTL source, optimize the
FPGA design, and estimate timing until you reach timing closure.
Tcl Support for HardCopy Migration
To complement the GUI features for HardCopy migration, the Quartus II
software provides the following command-line executables (which
provide the tool command language (Tcl) shell to run the --flow Tcl
command) to migrate the HARDCOPY_FPGA_PROTOTYPE project to
HardCopy Stratix devices:
quartus_sh --flow migrate_to_hardcopy <project_name> [-c <revision>] r
This command migrates the project compiled for the
HARDCOPY_FPGA_PROTOTYPE device to a HardCopy Stratix device.
quartus_sh --flow hardcopy_full_compile <project_name> [-c <revision>] r
4–44
Preliminary
Altera Corporation
October 2007
Design Optimization and Performance Estimation
This command performs the following tasks:
■
■
■
Design
Optimization
and
Performance
Estimation
Compiles the exsisting project for a
HARDCOPY_FPGA_PROTOTYPE device.
Migrates the project to a HardCopy Stratix project.
Opens the migrated HardCopy Stratix project and compiles it for a
HardCopy Stratix device.
The HardCopy Timing Optimization Wizard creates the HardCopy
Stratix project in the Quartus II software, where you can perform design
optimization and performance estimation of your HardCopy Stratix
device.
Design Optimization
Beginning with version 4.2, the Quartus II software supports HardCopy
Stratix design optimization by providing floorplans for placement
optimization and HardCopy Stratix timing models. These features allows
you to refine placement of logic array blocks (LAB) and optimize the
HardCopy design further than the FPGA performance. Customized
routing and buffer insertion done in the Quartus II software are then used
to estimate the design’s performance in the migrated device. The
HardCopy device floorplan, routing, and timing estimates in the
Quartus II software reflect the actual placement of the design in the
HardCopy Stratix device, and can be used to see the available resources,
and the location of the resources in the actual device.
Performance Estimation
Figure 4–21 illustrates the design flow for estimating performance and
optimizing your design. You can target your designs to
HARDCOPY_FPGA_PROTOTYPE devices, migrate the design to the
HardCopy Stratix device, and get placement optimization and timing
estimation of your HardCopy Stratix device.
In the event that the required performance is not met, you can:
■
Work to improve LAB placement in the HardCopy Stratix project.
or
■
Altera Corporation
October 2007
Go back to the HARDCOPY_FPGA_PROTOTYPE project and
optimize that design, modify your RTL source code, repeat the
migration to the HardCopy Stratix device, and perform the
optimization and timing estimation steps.
4–45
Preliminary
Quartus II Handbook, Volume 1
1
On average, HardCopy Stratix devices are 40% faster than the
equivalent -6 speed grade Stratix FPGA device. These
performance numbers are highly design dependent, and you
must obtain final performance numbers from Altera.
Figure 4–21. Obtaining a HardCopy Performance Estimation
Proven Netlist,
Pin Assignments, & Timing
Constraints
HardCopy Placement
Stratix FPGA
& Timing Analysis
Timing
Met?
Proven Netlist & New
Timing & Placement
Constraint
Yes
HardCopy Stratix
No
To perform Timing Analysis for a HardCopy Stratix device, follow these
steps:
1.
Open an existing project compiled for a
HARDCOPY_FPGA_PROTOYPE device.
2.
On the Project menu, point to HardCopy Utilities and click
HardCopy Timing Optimization Wizard.
3.
Select a destination directory for the migrated project and complete
the HardCopy Timing Optimization Wizard process.
On completion of the HardCopy Timing Optimization Wizard, the
destination directory created contains the Quartus II project file, and
all files required for HardCopy Stratix implementation. At this stage,
the design is copied from the HARDCOPY_FPGA_PROTOTYPE
project directory to a new directory to perform the timing analysis.
This two-project directory structure enables you to move back and
forth between the HARDCOPY_FPGA_PROTOTYPE design
database and the HardCopy Stratix design database. The Quartus II
software creates the <project name>_hardcopy_optimization
directory.
You do not have to select the HardCopy Stratix device while
performing performance estimation. When you run the HardCopy
Timing Optimization Wizard, the Quartus II software selects the
HardCopy Stratix device corresponding to the specified
HARDCOPY_FPGA_PROTOTYPE FPGA. Thus, the information
necessary for the HardCopy Stratix device is available from the
earlier HARDCOPY_FPGA_PROTOTYPE device selection.
4–46
Preliminary
Altera Corporation
October 2007
Design Optimization and Performance Estimation
All constraints related to the design are also transferred to the new
project directory. You can modify these constraints, if necessary, in
your optimized design environment to achieve the necessary timing
closure. However, if the design is optimized at the
HARDCOPY_FPGA_PROTOTYPE device level by modifying the
RTL code or the device constraints, you must migrate the project
with the HardCopy Timing Optimization Wizard.
c
If an existing project directory is selected when the HardCopy
Timing Optimization Wizard is run, the existing information is
overwritten with the new compile results.
The project directory is the directory that you chose for the migrated
project. A snapshot of the files inside the
<project name>_hardcopy_optimization directory is shown in
Table 4–7.
Table 4–7. Directory Structure Generated by the HardCopy Timing
Optimization Wizard
<project name>_hardcopy_optimization\
<project name>.qsf
<project name>.qpf
<project name>.sof
<project name>.macr
<project name>.gclk
db\
hardcopy_fpga_prototype\
fpga_<project name>_violations.datasheet
fpga_<project name>_target.datasheet
fpga_<project name>_rba_pt_hcpy_v.tcl
fpga_<project name>_pt_hcpy_v.tcl
fpga_<project name>_hcpy_v.sdo
fpga_<project name>_hcpy.vo
fpga_<project name>_cpld.datasheet
fpga_<project name>_cksum.datasheet
fpga_<project name>.tan.rpt
fpga_<project name>.map.rpt
fpga_<project name>.map.atm
fpga_<project name>.fit.rpt
fpga_<project name>.db_info
fpga_<project name>.cmp.xml
fpga_<project name>.cmp.rcf
fpga_<project name>.cmp.atm
fpga_<project name>.asm.rpt
fpga_<project name>.qarlog
fpga_<project name>.qar
fpga_<project name>.qsf
fpga_<project name>.pin
fpga_<project name>.qpf
db_export\
<project name>.map.atm
<project name>.map.hdbx
<project name>.db_info
Altera Corporation
October 2007
4–47
Preliminary
Quartus II Handbook, Volume 1
4.
Open the migrated Quartus II project created in Step 3.
5.
Perform a full compilation.
After successful compilation, the Timing Analysis section of the
Compilation Report shows the performance of the design.
1
Performance estimation is not supported for HardCopy APEX
devices in the Quartus II software. Your design can be
optimized by modifying the RTL code or the FPGA design and
the constraints. You should contact Altera to discuss any desired
performance improvements with HardCopy APEX devices.
Buffer Insertion
Beginning with version 4.2, the Quartus II software provides improved
HardCopy Stratix device timing closure and estimation, to more
accurately reflect the results expected after back-end migration. The
Quartus II software performs the necessary buffer insertion in your
HardCopy Stratix device during the Fitter process, and stores the location
of these buffers and necessary routing information in the Quartus II
Archive File. This buffer insertion improves the estimation of the
Quartus II Timing Analyzer for the HardCopy Stratix device.
Placement Constraints
Beginning with version 4.2, the Quartus II software supports placement
constraints and LogicLock regions for HardCopy Stratix devices.
Figure 4–22 shows an iterative process to modify the placement
constraints until the best placement for the HardCopy Stratix device is
achieved.
4–48
Preliminary
Altera Corporation
October 2007
Location Constraints
Figure 4–22. Placement Constraints Flow for HardCopy Stratix Devices
Compile the Design for
HARDCOPY_FPGA_PROTOTYPE
Migrate to HardCopy Stratix
Device Using the HardCopy
Timing Optimization Wizard
Add/Update
Placement Constraints
Add/Update
LogicLock Constraints
Compile for HardCopy
Stratix Device
No
Performance
Met?
Yes
Generate HardCopy Files
Location
Constraints
This section provides information about HardCopy Stratix logic location
constraints.
LAB Assignments
Logic placement in HardCopy Stratix is limited to LAB placement and
optimization of the interconnecting signals between them. In a Stratix
FPGA, individual logic elements (LE) are placed by the Quartus II Fitter
into LABs. The HardCopy Stratix migration process requires that LAB
contents cannot change after the Timing Optimization Wizard task is
done. Therefore, you can only make LAB-level placement optimization
and location assignments after migrating the
HARDCOPY_FPGA_PROTOTYPE project to the HardCopy Stratix
device.
Altera Corporation
October 2007
4–49
Preliminary
Quartus II Handbook, Volume 1
The Quartus II software supports these LAB location constraints for
HardCopy Stratix devices. The entire contents of a LAB is moved to an
empty LAB when using LAB location assignments. If you want to move
the logic contents of LAB A to LAB B, the entire contents of LAB A are
moved to an empty LAB B. For example, the logic contents of
LAB_X33_Y65 can be moved to an empty LAB at LAB_X43_Y56 but
individual logic cell LC_X33_Y65_N1 can not be moved by itself in the
HardCopy Stratix Timing Closure Floorplan.
LogicLock Assignments
The LogicLock feature of the Quartus II software provides a block-based
design approach. Using this technique you can partition your design and
create each block of logic independently, optimize placement and area,
and integrate all blocks into the top level design.
f
To learn more about this methodology, refer to the Quartus II Analyzing
and Optimizing Design Floorplan chapter in volume 2 of the Quartus II
Handbook.
LogicLock constraints are supported when you migrate the project from
a HARDCOPY_FPGA_PROTOTYPE project to a HardCopy Stratix
project. If the LogicLock region was specified as “Size=Fixed” and
“Location=Locked” in the HARDCOPY_FPGA_PROTOTYPE project, it
is converted to have “Size=Auto” and “Location=Floating” as shown in
the following LogicLock examples. This modification is necessary
because the floorplan of a HardCopy Stratix device is different from that
of the Stratix device, and the assigned coordinates in the
HARDCOPY_FPGA_PROTOTYPE do not match the HardCopy Stratix
floorplan. If this modification did not occur, LogicLock assignments
would lead to incorrect placement in the Quartus II Fitter. Making the
regions auto-size and floating, maintains your LogicLock assignments,
allowing you to easily adjust the LogicLock regions as required and lock
their locations again after HardCopy Stratix placement.
Example 4–1 and Example 4–2 show two examples of LogicLock
assignments.
Example 4–1. LogicLock Region Definition in the HARDCOPY_FPGA_PROTOTYPE Quartus II Settings File
set_global_assignment -name LL_HEIGHT 15 -entity risc8 -section_id test
set_global_assignment -name LL_WIDTH 15 -entity risc8 -section_id test
set_global_assignment -name LL_STATE LOCKED -entity risc8 -section_id test
set_global_assignment -name LL_AUTO_SIZE OFF -entity risc8 -section_id test
4–50
Preliminary
Altera Corporation
October 2007
Checking Designs for HardCopy Design Guidelines
Example 4–2. LogicLock Region Definition in the Migrated HardCopy Stratix Quartus II Settings File
set_global_assignment -name LL_HEIGHT 15 -entity risc8 -section_id test
set_global_assignment -name LL_WIDTH 15 -entity risc8 -section_id test
set_global_assignment -name LL_STATE FLOATING -entity risc8 -section_id
test
set_global_assignment -name LL_AUTO_SIZE ON -entity risc8 -section_id test
Checking
Designs for
HardCopy
Design
Guidelines
When you develop a design with HardCopy migration in mind, you must
follow Altera-recommended design practices that ensure a
straightforward migration process or the design will not be able to be
implemented in a HardCopy device. Prior to starting migration of the
design to a HardCopy device, you must review the design and identify
and address all the design issues. Any design issues that have not been
addressed can jeopardize silicon success.
Altera-Recommended HDL Coding Guidelines
Designing for Altera PLD, FPGA, and HardCopy structured ASIC
devices requires certain specific design guidelines and hardware
description language (HDL) coding style recommendations be followed.
f
For more information about design recommendations and HDL coding
styles, refer to the Design Guidelines section in volume 1 of the Quartus II
Handbook.
Design Assistant
The Quartus II software includes the Design Assistant feature to check
your design against the HardCopy design guidelines. Some of the design
rule checks performed by the Design Assistant include the following
rules:
■
■
■
Design should not contain combinational loops
Design should not contain delay chains
Design should not contain latches
To use the Design Assistant, you must run Analysis and Synthesis on the
design in the Quartus II software. Altera recommends that you run the
Design Assistant to check for compliance with the HardCopy design
guidelines early in the design process and after every compilation.
Altera Corporation
October 2007
4–51
Preliminary
Quartus II Handbook, Volume 1
Design Assistant Settings
You must select the design rules in the Design Assistant page prior to
running the design. On the Assignments menu, click Settings. In the
Settings dialog box, in the Category list, select Design Assistant and turn
on Run Design Assistant during compilation. Altera recommends
enabling this feature to run the Design Assistant automatically during
compilation of your design.
Running Design Assistant
To run Design Assistant independently of other Quartus II features, on
the Processing menu, point to Start and click Start Design Assistant.
The Design Assistant automatically runs in the background of the
Quartus II software when the HardCopy Timing Optimization Wizard is
launched, and does not display the Design Assistant results immediately
to the display. The design is checked before the Quartus II software
migrates the design and creates a new project directory for performing
timing analysis.
Also, the Design Assistant runs automatically whenever you generate the
HardCopy design database with the HardCopy Files Wizard. The Design
Assistant report generated is used by the Altera HardCopy Design Center
to review your design.
Reports and Summary
The results of running the Design Assistant on your design are available
in the Design Assistant Results section of the Compilation Report. The
Design Assistant also generates the summary report in the
<project name>\hardcopy subdirectory of the project directory. This
report file is titled <project name>_violations.datasheet. Reports include
the settings, run summary, results summary, and details of the results
and messages. The Design Assistant report indicates the rule name,
severity of the violation, and the circuit path where any violation
occurred.
f
4–52
Preliminary
To learn about the design rules and standard design practices to comply
with HardCopy design rules, refer to the Quartus II Help and the
HardCopy Series Design Guidelines chapter in volume 1 of the HardCopy
Series Handbook.
Altera Corporation
October 2007
Generating the HardCopy Design Database
Generating the
HardCopy
Design
Database
You can use the HardCopy Files Wizard to generate the complete set of
deliverables required for migrating the design to a HardCopy device in a
single click. The HardCopy Files Wizard asks questions related to the
design and archives your design, settings, results, and database files for
delivery to Altera. Your responses to the design details are stored in
<project name>_hardcopy_optimization\<project name>.hps.txt.
You can generate the archive of the HardCopy design database only after
compiling the design to a HardCopy Stratix device. The Quartus II
Archive File is generated at the same directory level as the targeted
project, either before or after optimization.
1
Altera Corporation
October 2007
The Design Assistant automatically runs when the HardCopy
Files Wizard is started.
4–53
Preliminary
Quartus II Handbook, Volume 1
Table 4–8 shows the archive directory structure and files collected by the
HardCopy Files Wizard.
Table 4–8. HardCopy Stratix Design Files Collected by the HardCopy Files
Wizard
<project name>_hardcopy_optimization\
<project name>.flow.rpt
<project name>.qpf
<project name>.asm.rpt
<project name>.blf
<project name>.fit.rpt
<project name>.gclk
<project name>.hps.txt
<project name>.macr
<project name>.pin
<project name>.qsf
<project name>.sof
<project name>.tan.rpt
hardcopy\
<project name>.apc
<project name>_cksum.datasheet
<project name>_cpld.datasheet
<project name>_hcpy.vo
<project name>_hcpy_v.sdo
<project name>_pt_hcpy_v.tcl
<project name>_rba_pt_hcpy_v.tcl
<project name>_target.datasheet
<project name>_violations.datasheet
hardcopy_fpga_prototype\
fpga_<project name>.asm.rpt
fpga_<project name>.cmp.rcf
fpga_<project name>.cmp.xml
fpga_<project name>.db_info
fpga_<project name>.fit.rpt
fpga_<project name>.map.atm
fpga_<project name>.map.rpt
fpga_<project name>.pin
fpga_<project name>.qsf
fpga_<project name>.tan.rpt
fpga_<project name>_cksum.datasheet
fpga_<project name>_cpld.datasheet
fpga_<project name>_hcpy.vo
fpga_<project name>_hcpy_v.sdo
fpga_<project name>_pt_hcpy_v.tcl
fpga_<project name>_rba_pt_hcpy_v.tcl
fpga_<project name>_target.datasheet
fpga_<project name>_violations.datasheet
db_export\
<project name>.db_info
<project name>.map.atm
<project name>.map.hdbx
After creating the migration database with the HardCopy
Timing Optimization Wizard, you must compile the design
before generating the project archive. You will receive an error
if you create the archive before compiling the design.
4–54
Preliminary
Altera Corporation
October 2007
Static Timing Analysis
Static Timing
Analysis
In addition to performing timing analysis, the Quartus II software also
provides all of the requisite netlists and Tcl scripts to perform static
timing analysis (STA) using the Synopsys STA tool, PrimeTime. The
following files, necessary for timing analysis with the PrimeTime tool, are
generated by the HardCopy Files Wizard:
■
■
■
<project name>_hcpy.vo—Verilog HDL output format
<project name>_hpcy_v.sdo—Standard Delay Format Output File
<project name>_pt_hcpy_v.tcl—Tcl script
These files are available in the <project name>\hardcopy directory.
PrimeTime libraries for the HardCopy Stratix and Stratix devices are
included with the Quartus II software.
1
f
Early Power
Estimation
Use the HardCopy Stratix libraries for PrimeTime to perform
STA during timing analysis of designs targeted to
HARDCOPY_FPGA_PROTOTYPE device.
For more information about static timing analysis, refer to the Classic
Timing Analyzer and the Synopsys PrimeTime Support chapters in
volume 3 of the Quartus II Handbook.
You can use PowerPlay Early Power Estimation to estimate the amount
of power your HardCopy Stratix or HardCopy APEX device will
consume. This tool is available on the Altera website. Using the Early
Power Estimator requires some knowledge of your design resources and
specifications, including:
■
■
■
■
■
Target device and package
Clock networks used in the design
Resource usage for LEs, DSP blocks, PLL, and RAM blocks
High speed differential interfaces (HSDI), general I/O power
consumption requirements, and pin counts
Environmental and thermal conditions
HardCopy Stratix Early Power Estimation
The PowerPlay Early Power Estimator provides an initial estimate of ICC
for any HardCopy Stratix device based on typical conditions. This
calculation saves significant time and effort in gaining a quick
understanding of the power requirements for the device. No stimulus
vectors are necessary for power estimation, which is established by the
clock frequency and toggle rate in each clock domain.
Altera Corporation
October 2007
4–55
Preliminary
Quartus II Handbook, Volume 1
This calculation should only be used as an estimation of power, not as a
specification. The actual ICC should be verified during operation because
this estimate is sensitive to the actual logic in the device and the
environmental operating conditions.
f
For more information about simulation-based power estimation, refer to
the Power Estimation and Analysis Section in volume 3 of the Quartus II
Handbook.
1
On average, HardCopy Stratix devices are expected to consume
40% less power than the equivalent FPGA.
HardCopy APEX Early Power Estimation
The PowerPlay Early Power Estimator can be run from the Altera website
in the device support section
(http://www.altera.com/support/devices/dvs-index.html). You cannot
open this feature in the Quartus II software.
With the HardCopy APEX PowerPlay Early Power Estimator, you can
estimate the power consumed by HardCopy APEX devices and design
systems with the appropriate power budget. Refer to the web page for
instructions on using the HardCopy APEX PowerPlay Early Power
Estimator.
1
Tcl Support for
HardCopy Stratix
f
4–56
Preliminary
HardCopy APEX devices are generally expected to consume
about 40% less power than the equivalent APEX 20KE or
APEX 20KC FPGA devices.
The Quartus II software also supports the HardCopy Stratix design flow
at the command prompt using Tcl scripts.
For details on Quartus II support for Tcl scripting, refer to the
Tcl Scripting chapter in volume 2 of the Quartus II Handbook.
Altera Corporation
October 2007
Targeting Designs to HardCopy APEX Devices
Targeting
Designs to
HardCopy APEX
Devices
Beginning with version 4.2, the Quartus II software supports targeting
designs to HardCopy APEX device families. After compiling your design
for one of the APEX 20KC or APEX 20KE FPGA devices supported by a
HardCopy APEX device, run the HardCopy Files Wizard to generate the
necessary set of files for HardCopy migration.
The HardCopy APEX device requires a different set of design files for
migration than HardCopy Stratix. Table 4–9 shows the files collected for
HardCopy APEX by the HardCopy Files Wizard.
Table 4–9. HardCopy APEX Files Collected by the HardCopy Files Wizard
<project name>.tan.rpt
<project name>.asm.rpt
<project name>.fit.rpt
<project name>.hps.txt
<project name>.map.rpt
<project name>.pin
<project name>.sof
<project name>.qsf
<project name>_cksum.datasheet
<project name>_cpld.datasheet
<project name>_hcpy.vo
<project name>_hcpy_v.sdo
<project name>_pt_hcpy_v.tcl
<project name>_rba_pt_hcpy_v.tcl
<project name>_target.datasheet
<project name>_violations.datasheet
Refer to “Generating the HardCopy Design Database” on page 4–53 for
information about generating the complete set of deliverables required
for migrating the design to a HardCopy APEX device. After you have
successfully run the HardCopy Files Wizard, you can submit your design
archive to Altera to implement your design in a HardCopy device. You
should contact Altera for more information about this process.
Conclusion
Altera Corporation
October 2007
The methodology for designing HardCopy Stratix devices using the
Quartus II software is the same as that for designing the Stratix FPGA
equivalent. You can use the familiar Quartus II software tools and design
flow, target designs to HardCopy Stratix devices, optimize designs for
higher performance and lower power consumption than the Stratix
FPGAs, and deliver the design database for migration to a HardCopy
Stratix device. Compatible APEX FPGA designs can migrate to
HardCopy APEX after compilation using the HardCopy Files Wizard to
archive the design files. Submit the files to the HardCopy Design Center
to complete the back-end migration.
4–57
Preliminary
Quartus II Handbook, Volume 1
Referenced
Documents
This chapter references the following documents:
■
■
■
■
■
■
■
■
■
■
■
■
■
■
■
■
■
■
■
■
4–58
Preliminary
AN432: Using Different PLL Settings Between Stratix II and HardCopy II
Devices
Back-End Design Flow for HardCopy Series Devices chapter in volume 1 of
the HardCopy Series Device Handbook
Cadence Encounter Conformal Support chapter in volume 3 of the
Quartus II Handbook
Classic Timing Analyzer chapter in volume 3 of the Quartus II Handbook
Description, Architecture and Features chapter in the HardCopy II Device
Family Data Sheet in the HardCopy Series Handbook
Design Guidelines for HardCopy Series Devices chapter of the HardCopy
Series Handbook
Design Guidelines Section in volume 1 of the Quartus II Handbook
HardCopy Series Handbook
HardCopy Stratix Device Family Data Sheet section in volume 1 of the
HardCopy Series Handbook
Introduction to Quartus II Manual
Introduction to HardCopy II Devices chapter in the HardCopy II Device
Family Data Sheet in the HardCopy Series Handbook
Power Estimation and Analysis section in volume 3 of the Quartus II
Handbook
Programming and Configuration chapter of the Introduction to Quartus II
Manual
Quartus II Analyzing and Optimizing Design Floorplan chapter in
volume 2 of the Quartus II Handbook
Quartus II Handbook
Quartus II Incremental Compilation for Hierarchical and Team-Based
Design chapter in volume 1 of the Quartus II Handbook
Quartus II PowerPlay Power Analysis chapter in volume 3 of the
Quartus II Handbook
Quartus II TimeQuest Timing Analyzer chapter in volume 3 of the
Quartus II Handbook
Synopsys PrimeTime Support chapter in volume 3 of the Quartus II
Handbook
Tcl Scripting chapter in volume 2 of the Quartus II Handbook
Altera Corporation
October 2007
Document Revision History
Document
Revision History
Table 4–10 shows the revision history for this chapter.
Table 4–10. Document Revision History (Part 1 of 2)
Date and Document
Version
Changes Made
October 2007
v7.2.0
Reorganized “Referenced Documents” on page 4–58.
May 2007
v7.1.0
●
●
●
●
●
●
●
Updated Timing Settings.
Updated TimeQuest.
Added Setting Up the TimeQuest Timing Analzyer.
Added Constraints for Clock Effect Characteristics.
Changed Performing ECOs with Change Manager and
Chip Planner title to Performing ECOs with Quartus II
Engineering Change Management with the Chip
Planner.
Updated Migrating Changes that must be Implemented
Differently.
Added Referenced Documents.
March 2007 v7.0.0
Updated Quartus II software 7.0 revision and date only. No
other changes made to chapter.
November 2006
v6.1.0
Minor updates for the Quartus II software version 6.1
● Added Performing ECOs with Change Manager and
Chip Planner and Overall Migration Flow sections.
● Updated Quartus II Software Features Supported for
HardCopy II Designs section.
May 2006 v6.0.0
Minor updates for the Quartus II software version 6.0.
Summary of Changes
Updated for Quartus II
version 7.2
Updated for Quartus II
version 7.1
—
A medium update to the
chapter, due to changes in
the Quartus II software
version 6.1 release; most
changes were in the
Performing ECOs with
Change Manager and Chip
Planner and Overall
Migration Flow sections.
—
October 2005 v5.1.0 Updated for the Quartus II software version 5.1.
—
May 2005 v5.0.0
Chapter 3 was formerly Chapter 2.
Updated for consistency with the Quartus II Support for
HardCopy II Devices and Quartus II Support for
HardCopy Stratix Devices chapters in the HardCopy
Series Handbook.
—
●
●
Jan. 2005 v2.1
●
Added HardCopy II Device Material.
—
Dec. 2004 v2.1
●
Chapter 2 was formerly Chapter 3.
Updates to tables, figures.
New functionality for Quartus II software 4.2
—
●
●
Altera Corporation
October 2007
4–59
Preliminary
Quartus II Handbook, Volume 1
Table 4–10. Document Revision History (Part 2 of 2)
Date and Document
Version
June 2004 v2.0
Changes Made
●
●
Feb. 2004 v1.0
4–60
Preliminary
Updates to tables, figures.
New functionality for Quartus II software 4.1.
Initial release.
Summary of Changes
—
—
Altera Corporation
October 2007
Section II. Design
Guidelines
Today's programmable logic device (PLD) applications have reached the
complexity and performance requirements of ASICs. In the development
of such complex system designs, good design practices have an
enormous impact on your device's timing performance, logic utilization,
and system reliability. Designs coded optimally will behave in a
predictable and reliable manner, even when re-targeted to different
device families or speed grades. This section presents design and coding
style recommendations for Altera® devices.
This section includes the following chapters:
■
■
1
Altera Corporation
Chapter 5, Design Recommendations for Altera Devices and the
Quartus II Design Assistant
Chapter 6, Recommended HDL Coding Styles
For information about the revision history for chapters in this
section, refer to each individual chapter for that chapter’s
revision history.
Section II–i
Preliminary
Design Guidelines
Section II–ii
Preliminary
Quartus II Handbook, Volume 1
Altera Corporation
5. Design Recommendations
for Altera Devices and the
Quartus II Design Assistant
QII51006-7.2.0
Introduction
Current FPGA applications have reached the complexity and
performance requirements of ASICs. In the development of such complex
system designs, good design practices have an enormous impact on your
device’s timing performance, logic utilization, and system reliability.
Well-coded designs behave in a predictable and reliable manner even
when re-targeted to different families or speed grades. Good design
practices also aid in successful design migration between FPGA and
HardCopy® or ASIC implementations for prototyping and production.
For optimal performance, reliability, and faster time-to-market when
designing with Altera® devices, you should adhere to the following
guidelines:
■
■
■
Understand the impact of synchronous design practices
Follow recommended design techniques including hierarchical
design partitioning
Take advantage of the architectural features in the targeted device
This chapter presents design recommendations in these areas, and
describes the Quartus® II Design Assistant that can help you check your
design for violations of design recommendations.
This chapter contains the following sections:
■
■
■
■
f
Altera Corporation
October 2007
“Synchronous FPGA Design Practices” on page 5–2
“Design Guidelines” on page 5–4
“Checking Design Violations Using the Design Assistant” on
page 5–15
“Targeting Clock and Register-Control Architectural Features” on
page 5–44
For specific HDL coding examples and recommendations, including
coding guidelines for targeting dedicated device hardware, such as
memory and DSP blocks, refer to the Recommended HDL Coding Styles
chapter in volume 1 of the Quartus II Handbook. For information about
migrating designs to HardCopy devices, refer to the Design Guidelines for
HardCopy Series Devices chapter in the HardCopy Series Handbook. For
guidelines on partitioning a hierarchical design for incremental
compilation, refer to the Quartus II Incremental Compilation for Hierarchical
and Team-Based Design chapter in volume 1 of the Quartus II Handbook.
5–1
Preliminary
Quartus II Handbook, Volume 1
Synchronous
FPGA Design
Practices
The first step in a good design methodology is to understand the
implications of your design practices and techniques. This section
outlines some of the benefits of optimal synchronous design practices and
the hazards involved in other techniques. Good synchronous design
practices can help you meet your design goals consistently. Problems
with other design techniques can include reliance on propagation delays
in a device, incomplete timing analysis, and possible glitches.
In a synchronous design, a clock signal triggers all events. As long as all
of the registers’ timing requirements are met, a synchronous design
behaves in a predictable and reliable manner for all process, voltage, and
temperature (PVT) conditions. You can easily target synchronous designs
to different device families or speed grades. In addition, synchronous
design practices help ensure successful migration if you plan to migrate
your design to a high-volume solution such as Altera HardCopy devices,
or if you are prototyping an ASIC.
Fundamentals of Synchronous Design
In a synchronous design, everything is related to the clock signal. On
every active edge of the clock (usually the rising edge), the data inputs of
registers are sampled and transferred to outputs. Following an active
clock edge, the outputs of combinational logic feeding the data inputs of
registers change values. This change triggers a period of instability due to
propagation delays through the logic as the signals go through a number
of transitions and finally settle to new values. Changes happening on data
inputs of registers do not affect the values of their outputs until the next
active clock edge.
Because the internal circuitry of registers isolates data outputs from
inputs, instability in the combinational logic does not affect the operation
of the design as long as the following timing requirements are met:
■
■
Before an active clock edge, the data input has been stable for at least
the setup time of the register
After an active clock edge, the data input remains stable for at least
the hold time of the register
When you specify all of your clock frequencies and other timing
requirements, the Quartus II Classic Timing Analyzer issues actual
hardware requirements for the setup times (tSU) and hold times (tH) for
every pin of your design. By meeting these external pin requirements and
following synchronous design techniques, you ensure that you satisfy the
setup and hold times for all registers within the Altera device.
5–2
Preliminary
Altera Corporation
October 2007
Synchronous FPGA Design Practices
1
To meet setup and hold time requirements on all input pins, any
inputs to combinational logic that feeds a register should have a
synchronous relationship with the clock of the register. If signals
are asynchronous, you can register the signals at the input of the
Altera device to help prevent a violation of the required setup
and hold times.
When the setup or hold time of a register is violated, the output can be set
to an intermediate voltage level between the high and low levels, called a
metastable state. In this unstable state, small perturbations like noise in
power rails can cause the register to assume either the high or low voltage
level, resulting in an unpredictable valid state. Various undesirable effects
can occur, including increased propagation delays and incorrect output
states. In some cases, the output can even oscillate between the two valid
states for a relatively long period of time.
f
For details about timing requirements and analysis in the Quartus II
software, refer to the Quartus II Classic Timing Analyzer or the Quartus II
TimeQuest Timing Analyzer chapters in volume 3 of the Quartus II
Handbook.
Hazards of Asynchronous Design
In the past, designers have often used asynchronous techniques such as
ripple counters or pulse generators in programmable logic device (PLD)
designs, enabling them to take “short cuts” to save device resources.
Asynchronous design techniques have inherent problems such as relying
on propagation delays in a device, which can result in incomplete timing
constraints and possible glitches and spikes. Because current FPGAs
provide many high-performance logic gates, registers, and memory,
resource and performance trade-offs have changed. Now it is more
important to focus on design practices that help you meet design goals
consistently than to save device resources using problematic
asynchronous techniques.
Some asynchronous design structures rely on the relative propagation
delays of signals to function correctly. In these cases, race conditions can
arise where the order of signal changes can affect the output of the logic.
PLD designs can have varying timing delays, depending on how the
design is placed and routed in the device with each compilation.
Therefore, it is almost impossible to determine the timing delay
associated with a particular block of logic ahead of time. As devices
become faster because of device process improvements, the delays in an
asynchronous design may decrease, resulting in a design that does not
function as expected. Specific examples are provided in “Design
Altera Corporation
October 2007
5–3
Preliminary
Quartus II Handbook, Volume 1
Guidelines” on page 5–4. Relying on a particular delay also makes
asynchronous designs very difficult to migrate to different architectures,
devices, or speed grades.
The timing of asynchronous design structures is often difficult or
impossible to model with timing assignments and constraints. If you do
not have complete or accurate timing constraints, the timing-driven
algorithms used by your synthesis and place-and-route tools may not be
able to perform the best optimizations, and reported results may not be
complete.
Some asynchronous design structures can generate harmful glitches,
which are pulses that are very short compared with clock periods. Most
glitches are generated by combinational logic. When the inputs of
combinational logic change, the outputs exhibit a number of glitches
before they settle to their new values. These glitches can propagate
through the combinational logic, leading to incorrect values on the
outputs in asynchronous designs. In a synchronous design, glitches on
the data inputs of registers are normal events that have no negative
consequences because the data is not processed until the clock edge.
Design
Guidelines
When designing with HDL code, it is important to understand how a
synthesis tool interprets different HDL design techniques and what
results to expect. Your design techniques can affect logic utilization and
timing performance, as well as the design’s reliability. This section
discusses some basic design techniques that ensure optimal synthesis
results for designs targeted to Altera devices while avoiding several
common causes of unreliability and instability. Design your
combinational logic carefully to avoid potential problems and pay
attention to your clocking schemes so you can maintain synchronous
functionality and avoid timing problems.
Combinational Logic Structures
Combinational logic structures consist of logic functions that depend
only on the current state of the inputs. In Altera FPGAs, these functions
are implemented in the look-up tables (LUTs) of the device’s architecture,
using either logic elements (LEs) or adaptive logic modules (ALMs). For
some cases in which combinational logic feeds registers, the register
control signals can also be used to implement part of the logic function to
save LUT resources. By following the recommendations in this section,
you can improve the reliability of your combinational design.
5–4
Preliminary
Altera Corporation
October 2007
Design Guidelines
Combinational Loops
Combinational loops are among the most common causes of instability
and unreliability in digital designs, and should be avoided whenever
possible. In a synchronous design, feedback loops should include
registers. Combinational loops generally violate synchronous design
principles by establishing a direct feedback loop that contains no
registers. For example, a combinational loop occurs when the left-hand
side of an arithmetic expression also appears on the right-hand side in
HDL code. A combinational loop also occurs when you feed back the
output of a register to an asynchronous pin of the same register through
combinational logic, as shown in Figure 5–1.
Figure 5–1. Combinational Loop through Asynchronous Control Pin
D
Q
Logic
CLRN
1
Use recovery and removal analysis to perform timing analysis
on asynchronous ports such as clear or reset in the
Quartus II software. On the Assignments menu, click Settings.
In the Settings dialog box, under Timing Analysis Settings,
select Classic Timing Analyzer Settings. On the Classic Timing
Analyzer Settings page, click More Settings, and turn on the
Enable Recovery/Removal Analysis option.
Combinational loops are inherently high-risk design structures for the
following reasons:
■
■
Combinational loop behavior generally depends on the relative
propagation delays through the logic involved in the loop. As
discussed, propagation delays can change, which means the
behavior of the loop is unpredictable.
Combinational loops can cause endless computation loops in many
design tools. Most tools break open combinational loops to process
the design. The various tools used in the design flow may open a
given loop in a different manner, processing it in a way that is
inconsistent with the original design intent.
Latches
A latch is a small combinational loop that holds the value of a signal until
a new value is assigned. Latches can also be inferred from HDL code
when you did not intend to use a latch. FPGA architectures are based on
Altera Corporation
October 2007
5–5
Preliminary
Quartus II Handbook, Volume 1
registers. In FPGA devices, latches actually use more logic resources and
lead to lower performance than registers. This is different from other
device architectures where latches may add less delay and can be
implemented with less silicon area than registers.
Latches can cause various difficulties in the design. Although latches are
memory elements, they are fundamentally different from registers. When
a latch is in feed-through or transparent mode, there is a direct path
between the data input and the output. Glitches on the data input can
pass through the output. The timing for latches is also inherently
ambiguous. For example, when analyzing a design with a D-latch, the
software cannot determine whether you intended to transfer data to the
output on the leading edge of the clock or on the trailing edge. In many
cases, only the original designer knows the full intent of the design;
therefore, another designer cannot easily modify the design or reuse the
code.
In some cases, your synthesis tool can infer a latch that does not exhibit
problems with glitches. Inferring the Altera lpm_latch function ensures
that the implementation is glitch-free in Altera architectures. Some thirdparty synthesis tools list the number of lpm_latch functions that are
inferred. When using Quartus II integrated synthesis, these latches are
reported in the User-Specified and Inferred Latches section of the
Compilation Report. If a latch or combinational loop in your design is not
listed in this report, it means that it was not inferred as a “safe” latch by
the software and is not considered glitch-free.
However, even glitch-free latches may not be analyzed completely during
timing analysis. The Analyze latches as synchronous elements option in
the Quartus II software allows you to treat latches as start and end points
for timing analysis (a typical analysis performed in FPGA design tools).
With this option turned on, latches are analyzed as registers (with an
inverted clock). The Quartus II software does not perform
cycle-borrowing analysis, such as that performed by third-party timing
analysis tools such as Synopsys PrimeTime.
In addition, latches have a limited support in formal verification tools.
Therefore, it is especially important to ensure that you do not use latches
when using formal verification.
Altera recommends avoiding using latches to ensure that you can
completely analyze and verify the timing performance and reliability of
your design.
5–6
Preliminary
Altera Corporation
October 2007
Design Guidelines
Delay Chains
Delay chains occur when two or more consecutive nodes with a single
fan-in and a single fan-out are used to cause delay. Inverters are often
chained together to add delay. Delay chains are sometimes used to
resolve race conditions created by other asynchronous design practices.
As described earlier in this chapter, delays in PLD designs can change
with each place-and-route cycle. Effects such as rise/fall time differences
and on-chip variation mean that delay chains, especially those placed on
clock paths, can cause significant problems in your design. See “Hazards
of Asynchronous Design” on page 5–3 for examples of the kinds of
problems that delay chains can cause. Avoid using delay chains to
prevent these kind of problems.
In some ASIC designs, delays are used for buffering signals as they are
routed around the device. This functionality is not needed in FPGA
devices because the routing structure provides buffers throughout the
device.
Pulse Generators and Multivibrators
Delay chains are sometimes used to generate either one pulse (pulse
generators) or a series of pulses (multivibrators). There are two common
methods for pulse generation, as shown in Figure 5–2. These techniques
are purely asynchronous and should be avoided.
Figure 5–2. Asynchronous Pulse Generators
Using an AND Gate
Pulse
Trigger
Using a Register
Trigger
Clock
D
Q
Pulse
Q
CLRN
In “Using an AND Gate” (Figure 5–2), a trigger signal feeds both inputs
of a 2-input AND gate, but the design inverts or adds a delay chain to one
of the inputs. The width of the pulse depends on the relative delays of the
path that feeds the gate directly and the one that goes through the delay.
Altera Corporation
October 2007
5–7
Preliminary
Quartus II Handbook, Volume 1
This is the same mechanism responsible for the generation of glitches in
combinational logic following a change of input values. This technique
artificially increases the width of the glitch by using a delay chain.
In “Using a Register” (Figure 5–2), a register’s output drives the same
register’s asynchronous reset signal through a delay chain. The register
resets itself asynchronously after a certain delay.
The width of pulses generated in this way are difficult for synthesis and
place-and-route software to determine, set, or verify. The actual pulse
width can only be determined after placement and routing, when routing
and propagation delays are known. You cannot reliably determine the
width of the pulse when creating HDL code, and it cannot be set by EDA
tools. The pulse may not be wide enough for the application under all
PVT conditions, and the pulse width changes if you change to a different
device. In addition, static timing analysis cannot be used to verify the
pulse width, so verification is very difficult.
Multivibrators use a glitch generator to create pulses, together with a
combinational loop that turns the circuit into an oscillator. This creates
additional problems because of the number of pulses involved. In
addition, when the structures generate multiple pulses, they also create a
new artificial clock in the design that has to be analyzed by the design
tools.
When you must use a pulse generator, use synchronous techniques, as
shown in Figure 5–3.
Figure 5–3. Recommended Pulse-Generation Technique
Pulse
Trigger Signal
D
Q
D
Q
Clock
In this design, the pulse width is always equal to the clock period. This
pulse generator is predictable, can be verified with timing analysis, and is
easily moved to other architectures, devices, or speed grades.
5–8
Preliminary
Altera Corporation
October 2007
Design Guidelines
Clocking Schemes
Like combinational logic, clocking schemes have a large effect on your
design’s performance and reliability. Avoid using internally generated
clocks wherever possible because they can cause functional and timing
problems in the design. Clocks generated with combinational logic can
introduce glitches that create functional problems, and the delay inherent
in combinational logic can lead to timing problems. The following
sections provide some specific examples and recommendations for
avoiding these problems.
1
Specify all clock relationships in the Quartus II software to allow
for the best timing-driven optimizations during fitting and to
allow correct timing analysis. Use clock setting assignments on
any derived or internal clocks to specify their relationship to the
base clock.
Altera recommends using global device-wide, low-skew
dedicated routing for all internally-generated clocks, instead of
routing clocks on regular routing lines. See “Clock Network
Resources” on page 5–44 for a detailed explanation.
Avoid data transfers between different clocks wherever
possible. If a data transfer between different clocks is needed,
use FIFO circuitry. You can use the clock uncertainty features in
the Quartus II software to compensate for the variable delays
between clock domains. Consider setting a Clock Setup
Uncertainty and Clock Hold Uncertainty value of 10% to 15% of
the clock delay.
Internally Generated Clocks
If you use the output from combinational logic as a clock signal or as an
asynchronous reset signal, you should expect to see glitches in your
design. In a synchronous design, glitches on data inputs of registers are
normal events that have no consequences. However, a glitch or a spike on
the clock input (or an asynchronous input) to a register can have
significant consequences. Narrow glitches can violate the register’s
minimum pulse width requirements. Setup and hold times may also be
violated if the data input of the register is changing when a glitch reaches
the clock input. Even if the design does not violate timing requirements,
the register output can change value unexpectedly and cause functional
hazards elsewhere in the design.
Because of these problems, always register the output of combinational
logic before you use it as a clock signal. See Figure 5–4.
Altera Corporation
October 2007
5–9
Preliminary
Quartus II Handbook, Volume 1
Figure 5–4. Recommended Clock-Generation Technique
D
D
Q
Clock
Generation
Logic
D
Q
D
Q
Q
Internally Generated Clock
Routed on Global Clock Resource
Registering the output of combinational logic ensures that the glitches
generated by the combinational logic are blocked at the data input of the
register.
Divided Clocks
Designs often require clocks created by dividing a master clock. Most
Altera FPGAs provide dedicated phase-locked loop (PLL) circuitry for
clock division. Using dedicated PLL circuitry can help you to avoid many
of the problems that can be introduced by asynchronous clock division
logic.
When you must use logic to divide a master clock, always use
synchronous counters or state machines. In addition, create your design
so that registers always directly generate divided clock signals, as
described in “Internally Generated Clocks” on page 5–9, and route the
clock on global clock resources. To avoid glitches, you should not decode
the outputs of a counter or a state machine to generate clock signals.
Ripple Counters
To simplify verification, Altera recommends avoiding ripple counters in
your design. In the past, FPGA designers implemented ripple counters to
divide clocks by a power of two because the counters are easy to design
and may use fewer gates than their synchronous counterparts. Ripple
counters use cascaded registers, in which the output pin of each register
feeds the clock pin of the register in the next stage. This cascading can
cause problems because the counter creates a ripple clock at each stage.
These ripple clocks have to be handled properly during timing analysis,
which can be difficult and may require you to make complicated timing
assignments in your synthesis and place-and-route tools.
5–10
Preliminary
Altera Corporation
October 2007
Design Guidelines
Ripple clock structures are often used to make ripple counters out of the
smallest amount of logic possible. However, in all Altera devices
supported by the Quartus II software, using a ripple clock structure to
reduce the amount of logic used for a counter is unnecessary because the
device allows you to construct a counter using one logic element per
counter bit. Altera recommends that you avoid using ripple counters
under any circumstances.
Multiplexed Clocks
Clock multiplexing can be used to operate the same logic function with
different clock sources. In these designs, multiplexing selects a clock
source, as in Figure 5–5. For example, telecommunications applications
that deal with multiple frequency standards often use multiplexed clocks.
Figure 5–5. Multiplexing Logic and Clock Sources
Multiplexed Clock Routed
on Global Clock Resource
Clock 1
D
Q
D
Q
D
Q
Clock 2
Select Signal
Adding multiplexing logic to the clock signal can create the problems
addressed in the previous sections, but requirements for multiplexed
clocks vary widely depending on the application. Clock multiplexing is
acceptable when the clock signal uses global clock routing resources, if
the following criteria are met:
■
■
■
■
Altera Corporation
October 2007
The clock multiplexing logic does not change after initial
configuration
The design uses multiplexing logic to select a clock for testing
purposes
Registers are always reset when the clock switches
A temporarily incorrect response following clock switching has no
negative consequences
5–11
Preliminary
Quartus II Handbook, Volume 1
If the design switches clocks in real time with no reset signal, and your
design cannot tolerate a temporarily incorrect response, you must use a
synchronous design so that there are no timing violations on the registers,
no glitches on clock signals, and no race conditions or other logical
problems. By default, the Quartus II software optimizes and analyzes all
possible paths through the multiplexer and between both internal clocks
that may come from the multiplexer. This may lead to more restrictive
analysis than required if the multiplexer is always selecting one particular
clock. If you do not need the more complete analysis, you can assign the
output of the multiplexer as a base clock in the Quartus II software, so
that all register-register paths are analyzed using that clock.
Altera recommends using dedicated hardware to perform clock
multiplexing when it is available, instead of using multiplexing logic. For
example, you can use the Clock Switchover feature or the Clock Control
Block available in certain Altera devices. These dedicated hardware
blocks ensure that you use global low-skew routing lines and avoid any
possible hold time problems on the device due to logic delay on the clock
line.
f
Refer to the appropriate device data sheet or handbook for
device-specific information about clocking structures.
Gated Clocks
Gated clocks turn a clock signal on and off using an enable signal that
controls some sort of gating circuitry, as shown in Figure 5–6. When a
clock is turned off, the corresponding clock domain is shut down and
becomes functionally inactive.
Figure 5–6. Gated Clock
D
Q
D
Q
Clock
Gating Signal
Gated Clock
You can use gated clocks to reduce power consumption in some device
architectures by effectively shutting down portions of a digital circuit
when they are not in use. When a clock is gated, both the clock network
and the registers driven by it stop toggling, thereby eliminating their
contributions to power consumption. However, gated clocks are not part
of a synchronous scheme and therefore can significantly increase the
5–12
Preliminary
Altera Corporation
October 2007
Design Guidelines
effort required for design implementation and verification. Gated clocks
contribute to clock skew and make device migration difficult. These
clocks are also sensitive to glitches, which can cause design failure.
Altera recommends that you use dedicated hardware to perform clock
gating rather than using multiplexing logic, if it is available in your target
device. For example, you can use the clock control block in newer Altera
devices to shut down an entire clock network. Dedicated hardware blocks
ensure that you use global routing with low skew and avoid any possible
hold time problems on the device due to logic delay on the clock line.
f
Refer to the appropriate device data sheet or handbook for
device-specific information about clocking structures.
From a functional point of view, you can shut down a clock domain in a
purely synchronous manner using a synchronous clock enable signal.
However, when using a synchronous clock enable scheme, the clock
network continues toggling. This practice does not reduce power
consumption as much as gating the clock at the source does. In most
cases, you should use a synchronous scheme such as those described in
“Synchronous Clock Enables”. For improved power reduction when
gating clocks with logic, refer to “Recommended Clock-Gating Methods”
on page 5–14.
Synchronous Clock Enables
To turn off a clock domain in a synchronous manner, use a synchronous
clock enable signal. FPGAs efficiently support clock enable signals
because there is a dedicated clock enable signal available on all device
registers. This scheme does not reduce power consumption as much as
gating the clock at the source because the clock network keeps toggling,
but it will perform the same function as a gated clock by disabling a set of
registers. Insert a multiplexer in front of the data input of every register
to either load new data or copy the output of the register (Figure 5–7).
Figure 5–7. Synchronous Clock Enable
D
Q
Data
Enable
Altera Corporation
October 2007
5–13
Preliminary
Quartus II Handbook, Volume 1
Recommended Clock-Gating Methods
Use gated clocks only when your target application requires power
reduction and when gated clocks are able to provide the required
reduction in your device architecture. If you must use clocks gated by
logic, implement these clocks using the robust clock-gating technique
shown in Figure 5–8 and ensure that the gated clock signal uses dedicated
global clock routing.
You can gate a clock signal at the source of the clock network, at each
register, or somewhere in between. Because the clock network contributes
to switching power consumption, gate the clock at the source whenever
possible, so you can shut down the entire clock network instead of gating
it further along the clock network at the registers.
Figure 5–8. Recommended Clock Gating Technique
D
Q
D
Q
Clock
Gating Signal
D
Q
Enable
Gated Clock Routed on
Global Clock Resources
In the technique shown in Figure 5–8, a register generates the enable
signal to ensure that the signal is free of glitches and spikes. The register
that generates the enable signal is triggered on the inactive edge of the
clock to be gated (use the falling edge when gating a clock that is active
on the rising edge, as shown in Figure 5–8). Using this technique, only
one input of the gate that turns the clock on and off changes at a time. This
prevents any glitches or spikes on the output. Use an AND gate to gate a
clock that is active on the rising edge. For a clock that is active on the
falling edge, use an OR gate to gate the clock and register the enable
command with a positive edge-triggered register.
When using this technique, pay attention to the duty cycle of the clock
and the delay through the logic that generates the enable signal, because
the enable signal must be generated in half the clock cycle. This situation
might cause problems if the logic that generates the enable command is
particularly complex, or if the duty cycle of the clock is severely
unbalanced. However, careful management of the duty cycle and logic
delay may be an acceptable solution when compared with problems
created by other methods of gating clocks.
5–14
Preliminary
Altera Corporation
October 2007
Checking Design Violations Using the Design Assistant
Ensure that you apply a clock setting to the gated clock in the Quartus II
software. As shown in Figure 5–8, apply a clock setting to the output of
the AND gate. Otherwise, the timing analyzer may analyze the circuit
using the clock path through the register as the longest clock path and the
path that skips the register as the shortest clock path, resulting in artificial
clock skew.
Checking Design
Violations Using
the Design
Assistant
To improve the reliability, timing performance, and logic utilization of
your design, practicing good design methodology and understanding
how to avoid design rule violations are important. The Quartus II
software provides a tool that automatically checks for design rule
violations, and tells you where they occur.
The Design Assistant is a design rule checking tool that allows you to
check for design issues early in the design flow. The Design Assistant
checks your design for adherence to Altera-recommended design
guidelines. You can specify which rules you want the Design Assistant to
apply to your design. This is useful if you know that your design violates
particular rules that are not critical, so you want to allow these rule
violations. The Design Assistant generates design violation reports with
clear details about each violation, based on the settings you specified.
The first parts in this section provide an introduction to the Quartus II
design flow with Design Assistant, message severity levels, and an
explanation about how to set up the Design Assistant. The last parts of the
section describe the design rules and the reports generated by the Design
Assistant.
Quartus II Design Flow with the Design Assistant
You can run the Design Assistant after Analysis and Elaboration,
Analysis and Synthesis, fitting, or a full compilation. To run the Design
Assistant, on the Processing menu, point to Start, and click Start Design
Assistant.
To set the Design Assistant to run automatically during compilation, on
the Assignments menu, click Settings. In the Category list, select Design
Assistant. Turn on Run Design Assistant during compilation. This
enables the Design Assistant to perform a post-fitting netlist analysis of
your design. The default is to apply all of the rules to your project. But if
there are some rules that are unimportant to your design, you can turn off
the rules that you do not want the Design Assistant to use. Refer to “The
Design Assistant Settings Page” on page 5–17.
Altera Corporation
October 2007
5–15
Preliminary
Quartus II Handbook, Volume 1
Figure 5–9 shows the Quartus II software design flow with the Design
Assistant.
Figure 5–9. Quartus II Design Flow with the Design Assistant
Design Files
Analysis &
Elaboration
Pre-Synthesis
Netlist
Synthesis
(Logic Synthesis &
Technology Mapping
Design Assistant
Post-Synthesis
Netlist
Rule Violation
Report
Fitter
Post-Fitting
Netlist
Timing Analysis
The Design Assistant analyzes your design netlist at different stages of
the compilation flow and may yield different warnings or errors, even
though the netlists are functionally the same. Your pre-synthesis,
post-synthesis, and post-fitting netlists may be different due to
optimizations performed by the Quartus II software. For example, a
warning message in a pre-synthesis netlist may be removed after the
netlist has been synthesized into a post-synthesis or post-fitting netlist.
When you run the Design Assistant after running a full compilation or
fitting, the Design Assistant performs a post-fitting analysis on the
design. When you start the Design Assistant after performing Analysis
and Synthesis, the Design Assistant performs post-synthesis analysis on
the design. When you start the Design Assistant after performing
Analysis and Elaboration, the Design Assistant performs a pre-synthesis
analysis on the design. You can also perform pre-synthesis analysis with
the Design Assistant using the command-line. You can use -rtl option
with the quartus_drc executable, as shown in the following example:
quartus_drc <project_name> --rtl=on r
5–16
Preliminary
Altera Corporation
October 2007
Checking Design Violations Using the Design Assistant
The Design Assistant generates warning messages when your design
violates design rules, and generates information messages to provide
information regarding the rules. The Design Assistant supports all Altera
devices supported by the Quartus II software.
The Design Assistant Settings Page
To apply design rules in the Design Assistant, on the Assignments menu,
click Settings. In the Settings dialog box, in the Category list, select
Design Assistant. In the Design Assistant page, turn on the rules that
you want the Design Assistant to apply during analysis. By default, all of
the rules except the finite state machine rules are turned on.
In the Timing Closure category, if Nodes with more than specified
number of fan-outs or Top nodes with highest fan-out are turned on,
you can use the High Fan-Out Net Settings dialog box to specify the
number of fan-out a node must have to be reported by the Design
Assistant. To open the High Fan-Out Net Settings dialog box, in the
Design Assistant page, in the Timing Closure category, select Nodes
with more than specified number of fan-outs or Top nodes with highest
fan-out. Click High Fan-Out Net Settings.
In the Clock category, if you turn on Clock signal should be a global
signal, you can use the Global Clock Threshold Settings dialog box to
specify the number of nodes with the highest fan-out which you want the
Design Assistant to report. To open the Global Clock Threshold Settings
dialog box, on the Design Assistant page, in the Clock category, select
Clock signal should be a global signal. Click Global Clock Threshold
Settings.
To specify the maximum number of messages reported by the Design
Assistant, on the Design Assistant page, click Report Settings, and enter
the maximum number of violation messages and detail messages to be
reported.
Altera Corporation
October 2007
5–17
Preliminary
Quartus II Handbook, Volume 1
Message Severity Levels
The Design Assistant classifies messages and rules using the four severity
levels described in Table 5–1. Following Altera guidelines is very
important for designs that are migrated to the HardCopy series of
devices, therefore the table highlights the impact of a rule violation on a
HardCopy migration. Designs that adhere to Altera recommended
design guidelines do not produce any messages with critical, high, or
medium level of severity.
Table 5–1. Design Assistant Message Severity Levels
Severity Level
Explanation
Critical
A violation of the rule critically affects the reliability of the design. Altera may not
be able to implement the design successfully without closely reviewing the
violations with the designer for HardCopy device conversions.
High
A violation of the rule affects the reliability of the design. Altera must review the
violation before implementing the design for HardCopy device conversions.
Medium
The rule violation may result in implementation complexity which may have an
impact for HardCopy device conversions.
Information Only
The rule provides information regarding the design.
Design Assistant Rules
This section describes the Design Assistant rules and details some of the
reasons that Altera recommends following certain guidelines. Many of
the Design Assistant rules enforce the design guidelines discussed in
previous sections of this chapter.
Every rule is represented by a rule ID and has its own severity level. The
rule ID is normally used in Tcl commands for rule suppression. The letter
in each rule ID corresponds to the group of rules based on the following
scheme.
■
■
■
■
■
■
■
■
5–18
Preliminary
A—Asynchronous design structure rules
C—Clock rules
R—Reset rules
S—Signal race rules
T—Timing closure rules
D—Asynchronous clock domain rules
H—HardCopy rules
M—Finite state machine rules
Altera Corporation
October 2007
Checking Design Violations Using the Design Assistant
For example, the rule “Design Should Not Contain Combinational
Loops” is the first rule in the asynchronous design structure rules;
therefore it is represented by rule ID A101.
1
The finite state machine rules are applicable only to RTL level
verification.
Summary of Rules and IDs
Table 5–2 lists the rules, their rule IDs, and their severity level.
Table 5–2. Summary of Rules and IDs (Part 1 of 2)
Rule ID
Rule Name
Severity Level
A101
Design Should Not Contain Combinational Loops
Critical
A102
Register Output Should Not Drive Its Own Control Signal Directly or through
Combinational Logic
Critical
A103
Design Should Not Contain Delay Chains
A104
Design Should Not Contain Ripple Clock Structures
Medium
A105
Pulses Should Not Be Implemented Asynchronously
Critical
A106
Multiple Pulses Should Not Be Generated in the Design
Critical
A107
Design Should Not Contain SR Latches
A108
Design Should Not Contain Latches
A109
Combinational Logic Should Not Directly Drive Write Enable Signal of Asynchronous
RAM
Medium
A110
Design Should Not Contain Asynchronous Memory
Medium
C101
Gated Clocks Should Be Implemented According to Altera Standard Scheme
Critical
C102
Logic Cell Should Not Be Used to Generate Inverted Clock
High
C103
Gated Clock Is Not Feeding At Least A Pre-Defined Number Of Clock Ports to
Effectively Save Power: <n>
High
C104
Clock Signal Source Should Drive Only Input Clock Ports
C105
Clock Signal Should Be a Global Signal
C106
Clock Signal Source Should Not Drive Registers that Are Triggered by Different
Clock Edges
R101
Combinational Logic Used as a Reset Signal Should Be Synchronized
R102
External Reset Should Be Synchronized Using Two Cascaded Registers
R103
External Reset Should Be Synchronized Correctly
High
R104
Reset Signal Generated in One Clock Domain and Used in Other Asynchronous
Clock Domains Should Be Synchronized Correctly
High
R105
Reset Signal Generated in One Clock Domain and Used in Other Asynchronous
Clock Domains Should Be Synchronized
Medium
Altera Corporation
October 2007
High
High
High
Medium
High
Medium
High
Medium
5–19
Preliminary
Quartus II Handbook, Volume 1
Table 5–2. Summary of Rules and IDs (Part 2 of 2)
Rule ID
Rule Name
Severity Level
S101
Output Enable and Input of the Same Tri-state Nodes Should Not Be Driven by the
Same Signal Source
High
S102
Synchronous Port and Asynchronous Port of the Same Register Should Not Be
Driven by the Same Signal Source
High
S103
More Than One Asynchronous Signal Source of the Same Register Should Not Be
Driven by the Same Source
High
S104
Clock Port and Any Other Signal Port of the Same Register Should Not Be Driven
by the Same Signal Source
High
T101
Nodes with More Than Specified Number of Fan-outs: <n>
Information Only
Information Only
T102
Top Nodes with Highest Fan-out: <n>
D101
Data Bits Are Not Synchronized When Transferred between Asynchronous Clock
Domains
D102
Multiple Data Bits Transferred Across Asynchronous Clock Domains Are
Synchronized, But Not All Bits May Be Aligned in the Receiving Clock Domain
D103
Data Bits Are Not Correctly Synchronized When Transferred Between
Asynchronous Clock Domains
H101
Only One VREF Pin Should Be Assigned to HardCopy Test Pin in an I/O Bank
Medium
Medium
H102
A PLL Drives Multiple Clock Network Types
M101
Data Bits Are Not Synchronized When Transferred to the State Machine of
Asynchronous Clock Domains
M102
No Reset Signal Defined to Initialize the State Machine
High
Medium
High
High
Medium
M103
State Machine Should Not Contain Unreachable State
Medium
M104
State Machine Should Not Contain a Deadlock State
Medium
M105
State Machine Should Not Contain a Dead Transition
Medium
Design Should Not Contain Combinational Loops
Severity Level: Critical
Rule ID: A101
A combinational loop is created by establishing a direct feedback loop on
combinational logic that is not synchronized by a register. A
combinational loop also occurs when the output of a register is fed back
to an asynchronous pin of the same register through combinational logic.
Combinational loops are among the most common causes of instability
and reliability in your designs, and should be avoided whenever possible.
Refer to “Combinational Loops” on page 5–5 for examples of the kinds of
problems that combinational loops can cause.
5–20
Preliminary
Altera Corporation
October 2007
Checking Design Violations Using the Design Assistant
Register Output Should Not Drive Its Own Control Signal Directly or
through Combinational Logic
Severity Level: Critical
Rule ID: A102
A combinational loop occurs when you feed back the output of a register
to an asynchronous pin of the same register (for example, the register’s
preset or asynchronous load signal), or the register drives combinational
logic that drives one of the control signals on the same register.
Combinational loops are among the most common causes of instability
and reliability in your designs, and should be avoided whenever possible.
Refer to “Combinational Loops” on page 5–5 for examples of the kinds of
problems that combinational loops can cause.
Design Should Not Contain Delay Chains
Severity Level: High
Rule ID: A103
Delay chains are created when one or more consecutive nodes with a
single fan-in and a single fan-out are used to cause delay. Delay chains are
sometimes used to create intentional delay to resolve race conditions.
Delay chains may cause significant problems, because they affect the rise
and fall time differences in your design.
This rule applies only for delay chains implemented in logic cells, and is
limited to the clock and reset path of your design. This rule does not apply
to delay chains in the data path. Altera recommends that you do not
instantiate a cell that does not benefit the design, and is used only to delay
the signal. Refer to “Delay Chains” on page 5–7 for examples of the kinds
of problems that delay chains can cause.
Design Should Not Contain Ripple Clock Structures
Severity Level: Medium
Rule ID: A104
Designs should not contain ripple clock structures. These structures use
two or more cascaded registers in which the output of each register feeds
the clock pin of the register in the next stage. Cascading structures cause
large skew in the output signal because each stage of the structure causes
a new clock domain to be defined. The additional clock domains from
each stage of the ripple clock are difficult for static timing analysis tools
to analyze. Refer to “Ripple Counters” on page 5–10 for examples of the
kinds of problems that ripple clock structures can cause.
Altera Corporation
October 2007
5–21
Preliminary
Quartus II Handbook, Volume 1
Pulses Should Not Be Implemented Asynchronously
Severity Level: Critical
Rule ID: A105
There are two common methods for pulse generation:
■
■
Increasing the width of a glitch using a 2-input AND, NAND, OR, or NOR
gate, where the source for the two gate inputs are the same, but one
of the gate inputs is inverted
Using a register where the register output drives the register’s own
asynchronous reset signal through a delay chain (refer to “Delay
Chains” on page 5–7 for more details).
These techniques are purely asynchronous and therefore should be
avoided. Refer to “Pulse Generators and Multivibrators” on page 5–7 for
recommended pulse generation guidelines.
Multiple Pulses Should Not Be Generated in the Design
Severity Level: Critical
Rule ID: A106
A common asynchronous multiple-pulse-generation technique consists
of a combinational logic gate in which the inverted output feeds back to
one of the inputs of the same gate. This feedback path causes a
combinational loop which forces the output to change state, and therefore
oscillate. Sometimes multiple pulse generators or multivibrator circuits
are built out of a series of cascaded inverters in a structure called a “ring
oscillator.” Oscillation creates a new artificial clock in your design that is
difficult for the Quartus II software to determine, set, or verify.
Structures that generate multiple pulses cause more problems than pulse
generators because of the number of pulses involved. In addition,
multi-pulse generators also increase the frequency of the design. See
“Pulse Generators and Multivibrators” on page 5–7 for recommended
pulse generation guidelines.
5–22
Preliminary
Altera Corporation
October 2007
Checking Design Violations Using the Design Assistant
Design Should Not Contain SR Latches
Severity Level: High
Rule ID: A107
A latch is a combinational loop that holds the value of a signal until a new
value is assigned. Combinational loops are hazardous to your design and
are the most common causes of instability and reliability. Refer to
“Combinational Loops” on page 5–5 for examples of the kinds of
problems that combinational loops can cause.
Rule A107 triggers only when your design contains SR latches. An SR
latch can cause glitches and ambiguous timing, which complicates the
timing analysis of your design. Refer to “Latches” on page 5–5 for details
about latches, and for more examples of the kinds of problems that latches
can cause.
Design Should Not Contain Latches
Severity Level: High
Rule ID: A108
The Design Assistant generates warnings when it identifies one or more
structures as latches.
Refer to “Latches” on page 5–5 for details about latches, and for examples
of the kinds of problems that latches can cause.
1
The difference between A107 (“Design Should Not Contain SR
Latches”) and A108 is that A107 triggers only when an SR latch
is detected. A108 triggers when there’s an unidentified latch in
your design.
Combinational Logic Should Not Directly Drive Write Enable Signal of
Asynchronous RAM
Severity Level: Medium
Rule ID: A109
Altera FPGA devices contain flexible embedded memory structures that
can be configured into many different modes. One possible mode is
asynchronous RAM. The definition of an asynchronous RAM circuit is
one in which the write-enable signal driving into the RAM causes data to
be written into it without a clock being required.
Altera Corporation
October 2007
5–23
Preliminary
Quartus II Handbook, Volume 1
You should not use combinational logic to directly drive the write-enable
signal of an asynchronous RAM. Any glitches that exist on the
write-enable signal can cause the asynchronous RAM to be corrupted.
Also, the data and write address ports of the RAM should be stable before
the write pulse is asserted, and must remain stable until the write pulse is
de-asserted. Because of the limitations to using memory structures in this
asynchronous mode, synchronous memories are always preferred. In
addition, synchronous memories provide higher design performance.
As a guideline, a register should be used between the combinational logic
and the asynchronous RAM, or the asynchronous RAM should be
replaced with synchronous memory. Refer to “Hazards of Asynchronous
Design” on page 5–3 for examples of the kinds of problems asynchronous
techniques can cause.
This rule applies only to device families that support asynchronous RAM.
Design Should Not Contain Asynchronous Memory
Severity Level: Medium
Rule ID: A110
You should avoid using asynchronous memory (for example,
asynchronous RAM) in your design, because asynchronous memory can
become corrupted by glitches created in the combinational logic that
drives the write-enable signal of the memory. Asynchronous memory
requires that the data and write address ports of the memory be stable
before the write pulse is asserted, and must remain stable until the write
pulse is de-asserted. In addition, asynchronous memory has lower
performance than synchronous memory.
As a guideline, a register should be used between the combinational logic
and the asynchronous RAM, or the asynchronous RAM should be
replaced with synchronous memory. Immediately registering both input
and output of the RAM improves performance and timing closure. Refer
to “Hazards of Asynchronous Design” on page 5–3 for examples of the
kinds of problems asynchronous techniques can cause.
This rule applies only to device families that support asynchronous RAM.
5–24
Preliminary
Altera Corporation
October 2007
Checking Design Violations Using the Design Assistant
Gated Clocks Should Be Implemented According to Altera Standard
Scheme
Severity Level: Critical
Rule ID: C101
Clock gating is sometimes used to turn parts of a circuit on and off to
reduce the total power consumption of a device. Clock gating is
implemented using an enable signal that controls some sort of gating
circuitry. The gated clock signal prevents any of the logic driven by it from
switching so the logic does not consume any power. For example, when
a clock is turned off, the corresponding clock domain is shut down and
becomes functionally inactive. However, the disadvantage of using this
type of circuit is that it can lead to unexpected glitches on the resultant
gated clock signal if certain rules are not followed.
Refer to “Gated Clocks” on page 5–12 for examples of the kinds of
problems gated clocks can cause. Refer to “Recommended Clock-Gating
Methods” on page 5–14 for a recommended clock gating technique.
However, when following the recommended clock gating techniques,
your design must have a minimum number of fan-outs to meet rule C103,
“Gated Clock Is Not Feeding At Least A Pre-Defined Number Of Clock
Ports to Effectively Save Power: <n>."
Logic Cell Should Not Be Used to Generate Inverted Clock
Severity Level: High
Rule ID: C102
Your design may require both positive and negative edges of a clock to
operate. However, you should not implement an inverter to drive the
clock input of a register in your design with a logic cell. Implementing the
inverter with a logic cell can lead to clock insertion delay and skew, which
is hazardous to your design and can cause problems with the timing
closure of the design.
In addition, using a logic cell to implement an inverter is unnecessary.
You should use the programmable clock inversion featured in the register
to generate the inverted clock signal. Refer to “Clocking Schemes” on
page 5–9 for details about different types of clocking methods.
Altera Corporation
October 2007
5–25
Preliminary
Quartus II Handbook, Volume 1
Gated Clock Is Not Feeding At Least A Pre-Defined Number Of Clock Ports
to Effectively Save Power: <n>
Severity Level: Medium
Rule ID: C103
Your design can contain an input clock pin that fans out to more than one
gated clock. However, to effectively reduce power consumption, Altera
recommends that the gated clock feed at least a pre-defined number of
clock ports (n ports). The default value for n is 30. You can set the number
of clock ports (n) by clicking Settings on the Assignments menu. In the
Category list, select Design Assistant. On the Design Assistant page,
expand the Clock category, and turn on Gated clock is not feeding at
least a pre-defined number of clock port to effectively save power: <n>.
Click on the Gated Clock Settings button, and in the Gated Clock
Settings dialog box, set the number of clock ports a gated clock should
feed. Refer to “Clocking Schemes” on page 5–9, and “Recommended
Clock-Gating Methods” on page 5–14 for proper clock-gating techniques.
Clock Signal Source Should Drive Only Input Clock Ports
Severity Level: Medium
Rule ID: C104
Clock signal sources in a design should drive only input clock ports of
registers. Rule C104 triggers when a design contains a clock signal source
of a register that connects to port rather than the clock port of another
register. Note that if the clock signal source and ports are of the same
register, rule S104 “Clock Port and Any Other Signal Port of the Same
Register Should Not Be Driven by the Same Signal Source” is triggered
instead. Such a design is considered asynchronous and should be
avoided. Asynchronous design structures can be hazardous to your
design because some of them rely on the relative propagation delays of
signals to function correctly, which can result in incomplete timing
constraints and possible glitches and spikes. Refer to “Hazards of
Asynchronous Design” on page 5–3 for examples of the kinds of
problems that asynchronous design structures can cause. Also refer to
“Clocking Schemes” on page 5–9 for proper clocking techniques.
This rule does not apply in the following conditions:
5–26
Preliminary
■
When the clock signal source drives combinational logic that is used
as a clock signal, and the combinational logic is implemented
according to the Altera standard scheme
■
When the clock signal source drives only a clock multiplexer that
selects one clock source from a number of different clock sources
Altera Corporation
October 2007
Checking Design Violations Using the Design Assistant
1
■
This type of multiplexer adds complexity to the timing analysis
of a design. You should avoid using the multiplexer in the
design.
Using a clock multiplexer causes the “Gated Clocks Should Be
Implemented According to Altera Standard Scheme” rule (C101) to
be applied; refer to “Multiplexed Clocks” on page 5–11 for
recommended clock multiplexing techniques
Clock Signal Should Be a Global Signal
Severity Level: High
Rule ID: C105
You should ensure that all clock signals in your design use the global
clock networks that exist in the target FPGA. Mapping clock signals to use
non-dedicated clock networks can negatively affect the performance of
your design. A non-global signal can be slower and have larger skew than
a global signal because the clock must be distributed using regular FPGA
routing resources.
To specify the number of minimum fan-outs that you want the Design
Assistant to report, on the Design Assistant page, in the Clock category,
select Clock signal should be a global signal. Click Global Clock
Threshold Settings, and enter the number in the dialog box.
If a design contains more clock signals than are available in the target
device, you should consider reducing the number of clock signals in the
design, such that only dedicated clock resources are used for clock
distribution. However, if the design must use more clock signals than you
can specify as global signals, implement the clock signals with the lowest
fan-out using regular routing resources. Also, implement the fastest clock
signals as global signals. Refer to “Clock Network Resources” on
page 5–44 for detailed information about clock resources.
Clock Signal Source Should Not Drive Registers that Are Triggered by
Different Clock Edges
Severity Level: Medium
Rule ID: C106
This rule triggers an error message if your design contains a clock signal
source that drives the clock inputs of both positive and negative
edge-sensitive registers. This error also triggers if your design contains an
inverted clock signal that drives the clock inputs of either positive or
negative edge-sensitive registers.
Altera Corporation
October 2007
5–27
Preliminary
Quartus II Handbook, Volume 1
These two scenarios can cause an increase in timing requirement
complexity and difficulties in design optimization. Also, because those
registers are clocked on the different edges, synchronous resetting is
impossible. Refer to “Clocking Schemes” on page 5–9 for some specific
examples and recommended clocking methods.
Combinational Logic Used as a Reset Signal Should Be Synchronized
Severity Level: High
Rule ID: R101
All combinational logic used to drive reset signals in your design should
be synchronized. This means that a register should be placed between the
combinational logic that drives reset signal and the input reset pin.
Unsynchronized combinational logic can cause glitches and spikes that
lead to unintentional reset signals. Synchronizing the combinational logic
that drives the reset signal delays the resulting reset signal by an extra
clock cycle and avoids unintentional reset. You should consider the extra
clock cycle delay when using this method in your design.
Rule R101 does not trigger if the combinational logic used is either a
2-input AND or NOR that feeds active low reset port, or either a 2-input OR
or NAND that feeds active high reset port.
External Reset Should Be Synchronized Using Two Cascaded Registers
Severity Level: Medium
Rule ID: R102
The only way to put your design into a reset state in the absence of a clock
signal is to use an asynchronous reset or external reset. However, the
asynchronous reset can affect the recovery time of a register, cause design
stability problems, and unintentionally reset the state machines in your
design to incorrect states.
As a guideline, you can synchronize an external reset signal by using a
double-buffer circuit, which consists of two cascaded registers triggered
on the same clock edge, and on the same clock domain as the targeted
registers.
This rule does not apply in the following two conditions:
■
5–28
Preliminary
When the targeted registers use active-high reset ports, and the
external reset signal drives the PRE ports on the cascaded registers
with the input port of the first cascaded registers is fed to GND. Refer
to Figure 5–11.
Altera Corporation
October 2007
Checking Design Violations Using the Design Assistant
Figure 5–10. Active-Low Reset Ports
inst4
PRE
D
Q
Clock
ENA
CLR
Reset
PRE
0
D
Targeted
Registers
PRE
Q
ENA
D
Q
CLR
inst6
inst9
PRE
ENA
CLR
inst5
D
Q
ENA
CLR
Cascaded Registers
■
When the targeted registers use active-low reset ports, and the
external reset signal drives the CLR ports on the cascaded registers
with the input port of the first cascaded registers is fed to VCC. Refer
to Figure 5–10.
Figure 5–11. Active-High Reset Ports
inst1
PRE
D
Q
Clock
ENA
CLR
1
inst3
inst2
PRE
PRE
D
Q
ENA
CLR
D
Targeted
Registers
Q
ENA
CLR
inst
PRE
D
Q
ENA
Reset
CLR
Cascaded Registers
Altera Corporation
October 2007
5–29
Preliminary
Quartus II Handbook, Volume 1
External Reset Should Be Synchronized Correctly
Severity Level: High
Rule ID: R103
The only way to put your design into a reset state in the absence of a clock
signal is to use an asynchronous reset or external reset. However, the
asynchronous reset can affect the recovery time of a register, cause design
stability problems, and unintentionally reset the state machines in your
design to incorrect states.
As a guideline, you can synchronize an external reset signal by using two
cascaded registers. The registers should be triggered on the same clock
edge, and on the same clock domain as the targeted registers.
This rule applies when an asynchronous reset or external reset signal is
synchronized but fails to follow the recommended guidelines as
described in rule R102 (“External Reset Should Be Synchronized Using
Two Cascaded Registers”). This violation happens when the external
reset is synchronized with only one register, or the cascaded
synchronization registers are triggered on different clock edges.
1
R102 triggers when you don’t use two cascaded registers to
synchronize the external reset. R103 triggers when the external
reset is synchronized but fails to follow the recommended
guidelines.
Reset Signal Generated in One Clock Domain and Used in Other
Asynchronous Clock Domains Should Be Synchronized Correctly
Severity Level: High
Rule ID: R104
If your design uses an internally generated reset signal generated in one
clock domain and used in one or more other asynchronous clock domain,
the reset signal should be synchronized. An unsynchronized reset signal
can cause metastability issues. To synchronize reset signals across clock
domains, use the following guidelines:
■
■
5–30
Preliminary
The reset signal should be synchronized with two or more cascading
registers in the receiving asynchronous clock domain.
The cascading registers should be triggered on the same clock edge.
Altera Corporation
October 2007
Checking Design Violations Using the Design Assistant
■
There should be no logic between the output of the transmitting
clock domain and the cascaded registers in the receiving
asynchronous clock domain. The synchronization registers may
sample unintended data due to the glitches caused by the logic.
This rule applies when the internal reset signal is synchronized but fails
to follow the recommended guidelines. This happens when the external
reset is only synchronized with one register, or the cascaded
synchronization registers are triggered on different clock edges, or there
is logic between the output of the transmitting clock domain and the
cascaded registers in the receiving asynchronous clock domain.
Synchronizing the reset signal delays the signal by an extra clock cycle.
You should consider this delay when using the reset signal in a design.
Reset Signal Generated in One Clock Domain and Used in Other
Asynchronous Clock Domains Should Be Synchronized
Severity Level: Medium
Rule ID: R105
If your design uses an internally generated reset signal that is generated
in one clock domain and used in one or more other asynchronous clock
domain, the reset signal should be synchronized. An unsynchronized
reset signal can cause metastability issues. To synchronize reset signals
across clock domains, you should follow guidelines described in Rule
R104 (“Reset Signal Generated in One Clock Domain and Used in Other
Asynchronous Clock Domains Should Be Synchronized Correctly”).
This rule applies when the internally generated reset signal is not being
synchronized.
Output Enable and Input of the Same Tri-state Nodes Should Not Be
Driven by the Same Signal Source
Severity Level: High
Rule ID: S101
This rule applies when your design contains a tri-state node in which the
input and output enable are driven by the same signal source. Signal race
occurs between the input and output enable signals of the tri-state when
they are propagated simultaneously. Race conditions lead to incorrect
design function and unpredictable results. To avoid violation of this rule,
the input and output enable of the tri-state should be driven by separate
signal sources.
Altera Corporation
October 2007
5–31
Preliminary
Quartus II Handbook, Volume 1
Synchronous Port and Asynchronous Port of the Same Register Should
Not Be Driven by the Same Signal Source
Severity Level: High
Rule ID: S102
A purely synchronous design is free of signal race conditions as long as
the clock signal is properly distributed and the timing requirements of the
registers are met. However, race conditions can occur typically when the
synchronous and asynchronous input pins of the register are driven by
the same signal source. Race conditions can cause incorrect design
function and unpredictable results. Rule S102 triggers when the
synchronous and asynchronous pins of a register are driven by the same
signal source. Rule S102 does not trigger if the signal source is from a
negative-edge sensitive register of the same clock, and if the source
register is directly feeding the reset port, provided there is no
combinational logic in-between the signal and the register.
More Than One Asynchronous Signal Source of the Same Register
Should Not Be Driven by the Same Source
Severity Level: High
Rule ID: S103
To avoid race conditions in your design, Altera recommends that you
avoid using the same signal source to drive more than one port on a
register. The following ports are affected: ALOAD, ADATA, Preset, and
Clear.
Clock Port and Any Other Signal Port of the Same Register Should Not Be
Driven by the Same Signal Source
Severity Level: High
Rule ID: S104
Any clock signal source in your design should drive only input clock
ports of registers. Rule S104 triggers only when your design contains
clock signal sources that connect to ports other than the clock ports of the
same register. Rule S104 is a sub rule of C104 “Clock Signal Source Should
Drive Only Input Clock Ports.” Such a design is considered asynchronous
and should be avoided. Refer to “Hazards of Asynchronous Design” for
examples of the kinds of problems that asynchronous design structures
can cause. Refer to “Clocking Schemes” for proper clocking techniques.
5–32
Preliminary
Altera Corporation
October 2007
Checking Design Violations Using the Design Assistant
Nodes with More Than Specified Number of Fan-outs: <n>
Severity Level: Information Only
Rule ID: T101
This rule reports nodes that have more than a specified number of
fan-outs, which can create timing challenges for your design.
To specify the number of fan-outs, on the Assignments menu, click
Settings. In the Category list, select Design Assistant. On the Design
Assistant page, expand the Timing closure category by clicking the
icon next to Timing closure. Turn on Nodes with more than specified
number of fan-outs. Click High Fan-Out Net Settings. In the High
Fan-Out Net Settings dialog box, enter the number of fan-outs a node
must have to be reported by the Design Assistant.
Top Nodes with Highest Fan-out: <n>
Severity Level: Information Only
Rule ID: T102
This rule reports the specified number of nodes with the highest fan-out,
which can create timing challenges for your design.
To specify the number of fan-outs, on the Assignments menu, click
Settings. In the Category list, select Design Assistant. On the Design
Assistant page, click the icon next to Timing closure to expand the
folder. Select Nodes with more than specified number of fan-outs. Click
High Fan-out Net Settings. In the High Fan-Out Net Settings dialog box,
enter the number of nodes with the highest fan-out to be reported by the
Design Assistant.
Data Bits Are Not Synchronized When Transferred between
Asynchronous Clock Domains
Severity Level: High
Rule ID: D101
The data bits transferred between asynchronous clock domains in a
design should be synchronized to avoid metastability problems.
If the data bits belong to single-bit data, each data bit should be
synchronized with two cascading registers in the receiving asynchronous
clock domain, in which the cascaded registers are triggered on the same
clock edge. There should be no logic between the output of the
transmitting clock domain and the cascaded registers in the receiving
asynchronous clock domain.
Altera Corporation
October 2007
5–33
Preliminary
Quartus II Handbook, Volume 1
If the data bits belong to multiple-bit data, a handshake protocol should
be used to guarantee that all bits of the data bus are stable when the
receiving clock domain samples the data. If a handshake protocol is used,
only the data bits that act as REQ (request) and ACK (acknowledge) signals
should be synchronized. The data bits that belong to multiple-bit data do
not need to be synchronized. You can ignore the violation on the data bits
that use a handshake protocol.
Multiple Data Bits Transferred Across Asynchronous Clock Domains Are
Synchronized, But Not All Bits May Be Aligned in the Receiving Clock
Domain
Severity Level: Medium
Rule ID: D102
This rule applies when data bits from a multiple-bit data that are
transferred between asynchronous clock domains are synchronized.
However, not all data bits may be aligned in the receiving clock domain.
Propagation delays may cause skew when the data reaches the receiving
clock domain.
If the data bits belong to multiple-bit data and a handshake protocol is
used, only the data bits that act as REQ, ACK, or both signals for the
transfer should be synchronized with two or more cascading registers in
the receiving asynchronous clock domain.
If all of the data bits belong to single-bit data, the synchronization of the
data bits does not cause problems in the design.
Data Bits Are Not Correctly Synchronized When Transferred Between
Asynchronous Clock Domains
Severity Level: High
Rule ID: D103
The data bits that are transferred between asynchronous clock domains in
a design should be synchronized to avoid metastability problems.
If the data bits belong to single-bit data, each data bit should be
synchronized with two cascading registers in the receiving asynchronous
clock domain. In this case, the cascaded registers are triggered on the
same clock edge, and there should be no logic between the output of the
transmitting clock domain. The cascaded registers in the receiving
asynchronous clock domain.
This rule only applies when the data bits across asynchronous clock
domains are synchronized but fail to follow the guidelines.
5–34
Preliminary
Altera Corporation
October 2007
Checking Design Violations Using the Design Assistant
Only One VREF Pin Should Be Assigned to HardCopy Test Pin in an
I/O Bank
Severity Level: Medium
Rule ID: H101
If your design targets a HardCopy APEX™ 20K device, you should not
assign more than one VREF pin to a HardCopy test pin in an I/O bank in
that targeted device. The assignment of more than one VREF pin to a
HardCopy test pin can cause contention of the VREF bus.
You can find the list of the HardCopy test pins that are in each of a
HardCopy APEX 20K device’s I/O banks in the Messages window, the
Design Assistant Messages report, and the Design Assistant HardCopy
Test Pins report. You should use this information to ensure that only one
VREF pin is assigned to a HardCopy test pin.
However, the Fitter may have assigned the VREF pins to the HardCopy
test pins during compilation. To prevent the Fitter from making these
assignments during the next compilation, create and assign the VREF
pins manually instead of allowing the Fitter to do so automatically.
This rule applies only to designs that target HardCopy APEX 20K
devices.
A PLL Drives Multiple Clock Network Types
Severity Level: Medium
Rule ID: H102
A PLL can compensate only one of the clock network types; therefore, the
other non-compensated clock network types have a non-zero delay.
However, the non-zero delay for the non-compensated clock network
types can change between a Stratix device and its corresponding
HardCopy Stratix device, or a Stratix II device and its corresponding
HardCopy II device.
Therefore, if a Stratix FPGA design relies on the relative offset between
the compensated clock network type and the non-compensated clock
network types driven by a PLL, an error can occur in the corresponding
HardCopy Stratix design because the relative offset in the HardCopy
Stratix design may differ from the relative offset in the original Stratix
FPGA design.
This rule reports only nodes in a design where a PLL drives multiple
clock network types.
Altera Corporation
October 2007
5–35
Preliminary
Quartus II Handbook, Volume 1
Data Bits Are Not Synchronized When Transferred to the State Machine of
Asynchronous Clock Domains
Severity Level: High
Rule ID: M101
The data bits that are transferred between asynchronous clock domains in
your design should be synchronized to avoid metastability problems.
Rule M101 is a state machine specific rule that triggers when input signals
of a state machine across asynchronous clock domains are not
synchronized or improperly synchronized. Rule M101 applies to state
machines only, while the “Data Bits Are Not Synchronized When
Transferred between Asynchronous Clock Domains” rule (D101) and the
“Data Bits Are Not Correctly Synchronized When Transferred Between
Asynchronous Clock Domains” rule (D103) apply only for data
synchronization between registers.
No Reset Signal Defined to Initialize the State Machine
Severity Level: Medium
Rule ID: M102
A finite state machine (FSM) should have a reset signal that initializes to
its initial state. A finite state machine without a proper initialization state
is susceptible to functional problems and can introduce extra difficulty in
analysis, verification, and maintenance.
State Machine Should Not Contain Unreachable State
Severity Level: Medium
Rule ID: M103
An unreachable state is a state that can never be reached from the initial
state. Having an unreachable state in your design causes logic
redundancy and affects your design functionality. Rule M103 triggers
when the initial state cannot traverse to a state through any of the
reachable states and transitions.
State Machine Should Not Contain a Deadlock State
Severity Level: Medium
Rule ID: M104
A deadlock state is a state that does not have any transitions to another
state except to loop to itself. When the state machine enters a deadlock
state, it stays in that state until the state machine is reset. Your design may
5–36
Preliminary
Altera Corporation
October 2007
Checking Design Violations Using the Design Assistant
have a single state, or a few states forming a deadlock structure. Having
a deadlock state in your design leads to design functionality problems,
and theoretically may consume more power.
You can change the maximum number of states to be detected as a
deadlock structure by clicking Settings on the Assignments menu, and in
the Settings dialog box, in the Category list, select Design Assistant. In
the Design Assistant page, click Finite State Machine Deadlock
Settings. In the Finite State Machine Deadlock Settings dialog box,
specify the maximum number of states to be reported as a deadlock
structure. The default setting is 2.
State Machine Should Not Contain a Dead Transition
Severity Level: Medium
Rule ID: M105
A dead transition is a redundant transition that never occurs regardless
of the event sequence input to the state machine. A dead transition
indicates logic redundancy in your design, although it may not affect
your design functionality. Rule M105 triggers when the condition
required to trigger a transition is not possible.
Enabling and Disabling Design Assistant Rules
You can selectively enable or disable Design Assistant rules on individual
nodes by making an assignment in the Assignment Editor, or using the
altera_attribute synthesis attribute in Verilog HDL or VHDL, or
using a Tcl command.
f
For a list of the types of nodes that allow Design Assistant rule
suppression, refer to Node Types Eligible for Rule Suppression in the
Quartus II Help.
1
Assignments made with Assignment Editor, the Quartus
Settings File (.qsf), and Tcl scripts and commands take
precedence over assignments made with the
altera_attribute synthesis attribute. Assignments made to
nodes, entities, or instances take precedence over global
assignments.
Using the Assignment Editor
You can enable or disable a Design Assistant rule on selected nodes in
your design by using the Assignments Editor. You must first compile
your design if you have not already done so. On the Assignments menu,
click Assignment Editor. In the spreadsheet, for the desired node, entity,
Altera Corporation
October 2007
5–37
Preliminary
Quartus II Handbook, Volume 1
or instance, double-click the cell in the Assignment Name column and
select Enable Design Assistant Rule or Disable Design Assistant Rule
in the pull-down menu. Then double-click the Value cell and type in the
Rule ID, or click Browse to open the Design Assistant Rules dialog box.
In the Design Assistant Rules dialog box, select the rule you want to
enable or disable for that particular node.
1
You can enable or disable multiple rules by typing more than
one Rule ID in the cell, and separating each Rule ID with a
comma.
Using Verilog HDL
You can use the altera_attributes synthesis attribute in your
Verilog HDL code to enable or disable a Design Assistant rule on the
selected nodes in your design.
To enable the rule on the selected node, the syntax is as shown in the
following example:
<entity class> <object> /* synthesis
altera_attribute="enable_da_rule=<ruleID>" */
You can enable more than one rule on a selected node as shown in the
following example:
<entity class> <object> /* synthesis
altera_attribute="enable_da_rule=\"<ruleID>,<ruleID>,
<ruleID>\""*/
To disable the rule on the selected node, the syntax is as shown in the
following example:
<entity class> <object> /* synthesis
altera_attribute="disable_da_rule=<ruleID>" */
You can disable more than one rule on a selected node as shown in the
following example:
<entity class> <object> /* synthesis
altera_attribute="disable_da_rule=\"<ruleID>,
<ruleID>,<ruleID>\""*/
1
5–38
Preliminary
When enabling or disabling multiple rules in Verilog HDL, you
must separate the Rule ID strings with commas and spaces only,
and they must be enclosed with the \" and \" characters.
Altera Corporation
October 2007
Checking Design Violations Using the Design Assistant
Using VHDL
You can use the altera_attributes synthesis attribute in your VHDL
code to enable or disable a Design Assistant rule on the selected nodes in
your design.
To enable the rule on the selected node, use the following syntax:
attribute altera_attribute : string;attribute
altera_attribute of <object>: <entity class> is
"enable_da_rule=<ruleID>"
You can enable more than one rule on a selected node as shown in the
following example:
attribute altera_attribute : string;attribute
altera_attribute of <object>: <entity class> is
"enable_da_rule=""<ruleID>, <ruleID>, <ruleID>"""
To disable the rule on the selected node, use the following syntax:
attribute altera_attribute : string;attribute
altera_attribute of <object>: <entity class> is
"disable_da_rule=<ruleID>"
You can disable more than one rule on a selected node as shown in the
following example:
attribute altera_attribute : string;attribute
altera_attribute of <object>: <entity class> is
"disable_da_rule=""<ruleID>, <ruleID>, <ruleID>"""
1
Altera Corporation
October 2007
When enabling or disabling multiple rules in VHDL, you must
separate the Rule ID strings with commas and spaces only, and
they must be enclosed with double quotation mark ("")
characters.
5–39
Preliminary
Quartus II Handbook, Volume 1
Using TCL Commands
To enable a Design Assistant rule on the selected node in your design
using Tcl in a script or at a command or Tcl prompt, use the following Tcl
command:
set_instance_assignment -name enable_da_rule "<rule ID>" -to <design element> r
To enable more than one rule on a selected node, use the following Tcl
command:
set_instance_assignment -name enable_da_rule "<rule ID>, <rule ID>" -to <design element> r
To disable a Design Assistant rule on a selected node in your design using
Tcl in a script, or at a command or Tcl prompt, use the following Tcl
command:
set_instance_assignment -name disable_da_rule "<rule ID>" -to <design element> r
To disable more than one rule on a selected node, use the following Tcl
command:
set_instance_assignment -name disable_da_rule "<rule ID>,<rule ID>" -to <design element> r
Viewing Design Assistant Results
If your design violates a design rule, the Design Assistant generates
warning messages and information messages about the violated design
rule. The Design Assistant displays these messages in the Messages
window, in the Design Assistant Messages report, and in the Design
Assistant report files. You can find the Design Assistant report files called
<project_name>.drc.rpt in the <project_name> subdirectory of the project
directory.
The Design Assistant generates the following reports based on the
settings specified in the Design Assistant page:
■
■
■
■
■
■
■
5–40
Preliminary
Summary Report
Settings Report
Detailed Results Report
Messages Report
HardCopy Test Pins Report
Rule Suppression Assignments Report
Ignored Design Assistant Assignments Report
Altera Corporation
October 2007
Checking Design Violations Using the Design Assistant
Summary Report
The Design Assistant Summary report contains summary of the Design
Assistant process on a particular project. This includes Design Assistant
Status, Revision Name, Top-level Entity, Targeted Family Device, and
total number of design violations of the project. The Design Assistant
Summary report provides the following information:
■
■
■
■
■
1
Design Assistant Status—the status, end date, and end time of the
Design Assistant operation
Revision Name—the revision name specified in the Revisions
dialog box
Top-level Entity Name—the top-level entity of your design
Family—the device family name specified in the Device page of the
Settings dialog box
Total Critical Violations, Total High Violations, Total Medium
Violations, and Total Information Only Violations—the total
violations of the rules organized by level, some of which might affect
the reliability of the design
You must first review the violations closely before converting
your design for HardCopy devices to achieve a successful
conversion.
Settings Report
The Design Assistant Settings report contains a list of enabled Design
Assistant rules and options that you specified in the Design Assistant
Settings page, as shown in Figure 5–12.
Altera Corporation
October 2007
5–41
Preliminary
Quartus II Handbook, Volume 1
Figure 5–12. The Design Assistant Settings Report
Detailed Results Report
The Detailed Results report contains detailed information of every rule
violation including the rule name, the node name, and the fan-out. This
report only appears if you specify settings in the Design Assistant
Settings page. Refer to “The Design Assistant Settings Page” on
page 5–17 for more information about how to specify the settings.
Separate Detailed Results reports are generated for critical, high,
medium, and information only results. Figure 5–13 shows the
Information Only Violations report.
5–42
Preliminary
Altera Corporation
October 2007
Checking Design Violations Using the Design Assistant
Figure 5–13. The Design Detailed Results Report, Information Only
Messages Report
The Messages report contains current information, warning, and error
messages generated during the Design Assistant process. You can
right-click a message in the Messages report and click Help to display the
Quartus II software Help with details about the selected message, or click
Locate to trace or cross-probe the selected node and locate the source of
the violation.
HardCopy Test Pins Report
The HardCopy Test Pins report appears only if you turn on Run Design
Assistant during compilation in the Design Assistant page, and if your
design violates the “Only One VREF Pin Should Be Assigned to
HardCopy Test Pin in an I/O Bank” rule (H101). The report lists all the
HardCopy design rule violations, and also list all of the test pins in the
HardCopy device.
Altera Corporation
October 2007
5–43
Preliminary
Quartus II Handbook, Volume 1
Rule Suppression Assignments Report
The Rule Suppression Assignments report contains detailed information
about which Design Assistant rules are enabled or disabled, as explained
in the “Enabling and Disabling Design Assistant Rules” on page 5–37.
The report shows you the following information:
■
■
■
Assignment—shows the name of the assignment
Value—identifies the rule
To—shows the name of the node where the rule is being applied
Ignored Design Assistant Assignments Report
The Ignored Design Assistant Assignments report lists detailed
information about the invalid and conflicting rule assignments reported
by the Design Assistant. Note that this report is generated only if you
specify an invalid rule ID in the rule suppression, or a conflicting rule
assignment. The following information appears in the report:
■
■
■
■
Targeting
Clock and
Register-Control
Architectural
Features
Assignment—shows the name of the assignment
Value—identifies the rule
To—shows the name of the node where the rule is being applied
Comment—shows why the assignment is being ignored
In addition to following general design guidelines, it is important to code
your design with the device architecture in mind. FPGAs provide
device-wide clocks and register control signals that can improve
performance.
Clock Network Resources
Altera FPGAs provide device-wide global clock routing resources and
dedicated inputs. You should use the FPGA’s low-skew, high fan-out,
dedicated routing where available. By assigning a clock input to one of
these dedicated clock pins or using a Quartus II logic option to assign
global routing, you can take advantage of the dedicated routing available
for clock signals.
In ASIC design, balancing the clock delay as it is distributed across the
device can be important. Because Altera FPGAs provides device-wide
global clock routing resources and dedicated inputs, there is no need to
manually balance delays on the clock network.
Altera recommends limiting the number of clocks in your design to the
number of dedicated global clock resources available in your FPGA.
Clocks feeding multiple locations that do not use global routing may
exhibit clock skew across the device that could lead to timing problems.
5–44
Preliminary
Altera Corporation
October 2007
Targeting Clock and Register-Control Architectural Features
In addition, when you use combinational logic to generate an internal
clock, it adds delays on the clock line. In some cases, delay on a clock line
can result in a clock skew greater than the data path length between two
registers. If the clock skew is greater than the data delay, the timing
parameters of the register (such as hold time requirements) are violated
and the design will not function correctly.
Current FPGAs offer increasing numbers of global clocks to address large
designs with many clock domains. Many large FPGA devices provide
dedicated global clock networks, regional clock networks, and dedicated
fast regional clock networks. These clocks are typically organized into a
hierarchical clock structure that allows many clocks in each device region
with low skew and delay. There are typically a number of dedicated clock
pins to drive either the global or regional clock networks and both PLL
outputs and internal clocks can drive various clock networks.
To reduce the clock skew within a given clock domain and ensure that
hold times are met within that clock domain, assign each clock signal to
one of the global high fan-out, low-skew clock networks in the FPGA
device. Quartus II automatically uses global routing for high fan-out
control signals, PLL outputs, and signals feeding the global clock pins on
the device. You can make explicit Global Signal logic option settings by
turning on the signal logic option settings. On the Assignment menu,
click Assignment Editor. Use this option when it is necessary to force the
software to use the global routing for particular signals.
To take full advantage of these routing resources, the sources of clock
signals in a design (input clock pins or internally-generated clocks)
should drive only the clock input ports of registers. In older Altera device
families (such as FLEX® 10K and ACEX® 1K), if a clock signal feeds the
data ports of a register, the signal may not be able to use the dedicated
routing, which can lead to decreased performance and clock skew
problems. In general, allowing clock signals to drive the data ports of
registers is not considered synchronous design, and it can complicate
timing analysis. It is not a recommended practice.
Reset Resources
ASIC designs may use local resets to avoid long routing delays on the
signal. You should take advantage of the device-wide asynchronous reset
pin available on most FPGAs to eliminate these problems. This reset
signal provides low-skew routing across the device.
Altera Corporation
October 2007
5–45
Preliminary
Quartus II Handbook, Volume 1
Register Control Signals
Avoid using an asynchronous load signal if the design target device
architecture does not include registers with dedicated circuitry for
asynchronous loads. Also, avoid using both asynchronous clear and
preset if the architecture provides only one of those control signals. APEX
devices, for example, directly support an asynchronous clear function,
but not a preset or load function. When the target device does not directly
support the signals, the place-and-route software must use combinational
logic to implement the same functionality. In addition, if you use signals
in a priority other than the inherent priority in the device architecture,
combinational logic may be required to implement the desired control
signals. The combinational logic is less efficient and can cause glitches
and other problems; it is best to avoid these implementations.
f
For Verilog HDL and VHDL examples of registers with various control
signals, and information about the inherent priority order of register
control signals in Altera device architecture, refer to the Recommended
HDL Coding Styles chapter in volume 1 of the Quartus II Handbook.
Conclusion
Following the design practices outlined in this chapter can help you meet
your design goals consistently. Asynchronous design techniques may
result in incomplete timing analysis, may clause glitches on data signals,
and may rely on propagation delays in a device leading to race conditions
and unpredictable results. Taking advantage of the architectural features
in your FPGA device can also improve your quality of results.
Referenced
Documents
This chapter references the following documents:
■
■
■
■
■
■
5–46
Preliminary
Design Guidelines for HardCopy Series Devices chapter in the HardCopy
Series Handbook
Quartus II Incremental Compilation for Hierarchical and Team-Based
Design chapter in volume 1 of the Quartus II Handbook
Quartus II Classic Timing Analysis chapter in volume 3 of the
Quartus II Handbook
Quartus II TimeQuest Timing Analysis chapter in volume 3 of the
Quartus II Handbook
Quartus II Handbook
Recommended HDL Coding Styles chapter in volume 1 of the Quartus II
Handbook
Altera Corporation
October 2007
Document Revision History
Document
Revision History
Table 5–3 shows the revision history for this chapter.
Table 5–3. Document Revision History (Part 1 of 2)
Date and
Document
Version
October 2007
v7.2.0
Changes Made
●
●
●
●
May 2007
v7.1.0
●
●
●
●
●
●
●
●
●
March 2007
v7.0.0
Added restrictions to the rule “External Reset Updated for Quartus II software version
Should Be Synchronized Using Two Cascaded 7.2.
Registers” on page 5–28
Added Figure 5–11 and 5–10 on page 5–29
Some changes regarding the Delay Chain rule
description (page 5–21)
Added hyperlinks to referenced documents
Updated for Quartus II software version
Changed chapter name to Design
Recommendations for Altera Devices and the 7.1.
Quartus II Design Assistant
Removed Hierarchical Design Partitioning
section
Updated Design Assistant Rules on page 5–19
Added Finite State Machine Rules on
page 5–36
Added Enabling and Disabling Design
Assistant Rules on page 5–38
Added Rule Suppression Assignments Report
on page 5–45
Added Ignored Design Assistant Assignments
Report on page 5–45
Updated Table 5–2
Added Referenced Documents on page 5–47
Updated Quartus II software 7.0 revision and date
only. No other changes made to chapter.
November 2006 Added the following sections (with additional
v6.1.0
subsections):
● “Checking Design Violations Using the Design
Assistant”
● “Quartus II Design Flow with the Design
Assistant”
● “The Design Assistant Page”
● “Message Severity Levels”
● “Design Assistant Rules”
● “Viewing Design Assistant Results”
May 2006
v6.0.0
October 2005
v5.1.0
Minor updates for the Quartus II version 6.0.
Updated for the Quartus II software version 5.1.
Altera Corporation
October 2007
Summary of Changes
—
Quartus II software version 6.1 added the
Design Assistant; the bulk of the changes
to this chapter are related to this update.
—
—
5–47
Preliminary
Quartus II Handbook, Volume 1
Table 5–3. Document Revision History (Part 2 of 2)
Date and
Document
Version
Changes Made
Summary of Changes
Chapter 5 was formerly Chapter 4 in version 4.2.
—
December 2004 Updated for Quartus II software version 4.2:
● Chapter 5 was formerly Chapter 6 in version
v2.1
4.1.
● General formatting and editing updates.
● Updated hardware requirements for the
Quartus II Timing Analyzer.
● Added timing requirements and analysis
details.
● Updated Design Guidelines.
● Added information about performing timing
analysis on asynchronous ports.
● Added inferred latches information.
● Updated Delay Chains description.
● Updated figures, tables.
● Added Clocking Schemes information.
● Added details to Multiplexed Clocks details.
● Added clock gating details.
● Updated Hierarchical Design Partitioning to
include synthesis and incremental synthesis.
● Added global routing information.
—
Updates to tables, figures, coding examples.
New functionality for Quartus II software 4.1.
—
May 2005
v.5.0.0
June 2004
v.2.0
●
February 2004
v1.0
Initial release.
5–48
Preliminary
●
—
Altera Corporation
October 2007
6. Recommended HDL
Coding Styles
QII51007-7.2.0
Introduction
HDL coding styles can have a significant effect on the quality of results
that you achieve for programmable logic designs. Synthesis tools
optimize HDL code for both logic utilization and performance. However,
sometimes the best optimizations require human understanding of the
design, and synthesis tools have no information about the purpose or
intent of the design. You are often in the best position to improve your
quality of results.
This chapter addresses HDL coding style recommendations to ensure
optimal synthesis results when targeting Altera® devices, including the
following sections:
■
■
■
■
■
■
■
■
f
“Quartus II Language Templates” on page 6–2
“Using Altera Megafunctions” on page 6–3
“Instantiating Altera Megafunctions in HDL Code” on page 6–4
“Inferring Multiplier and DSP Functions from HDL Code” on
page 6–7
“Inferring Memory Functions from HDL Code” on page 6–13
“Coding Guidelines for Registers and Latches” on page 6–37
“General Coding Guidelines” on page 6–48
“Designing with Low-Level Primitives” on page 6–73
For additional guidelines on structuring your design, refer to the Design
Recommendations for Altera Devices chapter in volume 1 of the Quartus II
Handbook.
For style recommendations, options, or HDL attributes specific to your
synthesis tool (including Quartus® II Integrated Synthesis and other EDA
tools), refer to the tool vendor’s documentation or the appropriate
chapter in the Synthesis section in volume 1 of the Quartus II Handbook.
Altera Corporation
October 2007
6–1
Quartus II Handbook, Volume 1
Quartus II
Language
Templates
The Quartus II software provides Verilog HDL, VHDL, AHDL, Tcl script,
and megafunction language templates that can help you with your
design.
Many of the Verilog HDL and VHDL examples in this document
correspond with examples in the templates. You can easily insert
examples from this document into your HDL source code using the Insert
Template dialog box in the Quartus II user interface, shown in Figure 6–1.
Figure 6–1. Insert Template Dialog Box
To open the Insert Template dialog box when you have a file open in the
Quartus II Text Editor, on the Edit menu, click Insert Template.
Alternately, you can right-click in the Text Editor window and choose
Insert Template.
6–2
Preliminary
Altera Corporation
October 2007
Using Altera Megafunctions
Using Altera
Megafunctions
Altera provides parameterizable megafunctions that are optimized for
Altera device architectures. Using megafunctions instead of coding your
own logic saves valuable design time. Additionally, the Altera-provided
megafunctions may offer more efficient logic synthesis and device
implementation. You can scale the megafunction’s size and set various
options by setting parameters. Megafunctions include the library of
parameterized modules (LPM) and Altera device-specific megafunctions.
To use megafunctions in your HDL code, you can instantiate them as
described in “Instantiating Altera Megafunctions in HDL Code” on
page 6–4.
Sometimes it is preferable to make your code independent of device
family or vendor, and you do not want to instantiate megafunctions
directly. For some types of logic functions, such as memory and DSP
functions, you can infer a megafunction instead of instantiating it.
Synthesis tools, including Quartus II integrated synthesis, recognize
certain types of HDL code and automatically infer the appropriate
megafunction. The synthesis tool uses the Altera megafunction code
when compiling your design—even when you do not specifically
instantiate the megafunction. Synthesis tools infer megafunctions to take
advantage of logic that is optimized for Altera devices or to target
dedicated architectural blocks.
In cases where you prefer to use generic HDL code instead of
instantiating a megafunction, follow the guidelines and coding examples
in “Inferring Multiplier and DSP Functions from HDL Code” on page 6–7
and “Inferring Memory Functions from HDL Code” on page 6–13 to
ensure your HDL code infers the appropriate Altera megafunction.
1
Altera Corporation
October 2007
You must use megafunctions to access some Altera
device-specific architecture features. You can infer or instantiate
megafunctions to target some features such as memory and DSP
blocks. You must instantiate megafunctions to target certain
device and high-speed features such as LVDS drivers, PLLs,
transceivers, and double-data rate input/output (DDIO)
circuitry.
6–3
Preliminary
Quartus II Handbook, Volume 1
For some designs, generic HDL code can provide better results than
instantiating a megafunction. Refer to the following general guidelines
and examples that describe when to use standard HDL code and when to
use megafunctions:
■
■
■
Instantiating
Altera
Megafunctions
in HDL Code
For simple addition or subtraction functions, use the + or – symbol
instead of an LPM function. Instantiating an LPM function for simple
arithmetic operations can result in a less efficient result because the
function is hard coded and the synthesis algorithms cannot take
advantage of basic logic optimizations.
For simple multiplexers and decoders, use array notation (such as
out = data[sel]) instead of an LPM function. Array notation
works very well and has simple syntax. You can use the lpm_mux
function to take advantage of architectural features such as cascade
chains in APEX™ series devices, but use the LPM function only if you
understand the device architecture in detail and want to force a
specific implementation.
Avoid division operations where possible. Division is an inherently
slow operation. Many designers use multiplication creatively to
produce division results.
The following sections describe how to use megafunctions by
instantiating them in your HDL code with the following methods:
■
■
■
“Instantiating Megafunctions Using the MegaWizard Plug-In
Manager”—You can use the MegaWizard® Plug-In Manager to
parameterize the function and create a wrapper file.
“Creating a Netlist File for Other Synthesis Tools”—You can
optionally create a netlist file instead of a wrapper file.
“Instantiating Megafunctions Using the Port and Parameter
Definition”—You can instantiate the function directly in your HDL
code.
Instantiating Megafunctions Using the MegaWizard Plug-In
Manager
Use the MegaWizard Plug-In Manager as described in this section to
create megafunctions in the Quartus II GUI that you can instantiate in
your HDL code. The MegaWizard Plug-In Manager provides a graphical
user interface to customize and parameterize megafunctions, and ensures
that you set all megafunction parameters properly. When you finish
setting parameters, you can specify which files you want to be generated.
Depending on which language you choose, the MegaWizard Plug-In
6–4
Preliminary
Altera Corporation
October 2007
Instantiating Altera Megafunctions in HDL Code
Manager instantiates the megafunction with the correct parameters and
generates a megafunction variation file (wrapper file) in Verilog HDL
(.v), VHDL (.vhd), or AHDL (.tdf) along with other supporting files.
The MegaWizard Plug-In Manager provides options to create the
following files:
■
■
■
■
■
■
A sample instantiation template for the language of the variation file
(_inst.v|vhd|tdf).
Component Declaration File (.cmp) that can be used in VHDL
Design Files
ADHL Include File (.inc) that can be used in Text Design Files (.tdf)
Quartus II Block Symbol File (.bsf) for schematic designs
Verilog HDL module declaration file that can be used when
instantiating the megafunction as a black box in a third-party
synthesis tool (_bb.v).
If you enable the option to generate a synthesis area and timing
estimation netlist, the MegaWizard Plug-In Manager generates an
additional synthesis netlist file (_syn.v). Refer to “Creating a Netlist
File for Other Synthesis Tools” on page 6–6 for details.
Refer to Table 6–1 for a list and description of files generated by the
MegaWizard Plug-In Manager.
Table 6–1. MegaWizard Plug-In Manager Generated Files (Part 1 of 2)
File
Description
<output file>.v (1)
Verilog HDL Variation Wrapper File—Megafunction wrapper file for instantiation in a
Verilog HDL design.
<output file>.vhd (1)
VHDL Variation Wrapper File—Megafunction wrapper file for instantiation in a VHDL
design.
<output file>.tdf (1)
AHDL Variation Wrapper File—Megafunction wrapper file for instantiation in an
AHDL design.
<output file>.inc
ADHL Include File—Used in AHDL designs.
<output file>.cmp
Component Declaration File—Used in VHDL designs.
<output file>.bsf
Block Symbol File—Used in Quartus II Block Design Files (.bdf).
<output file>_inst.v
Verilog HDL Instantiation Template—Sample Verilog HDL instantiation of the module
in the megafunction wrapper file.
<output file>_inst.vhd
VHDL Instantiation Template—Sample VHDL instantiation of the entity in the
megafunction wrapper file.
<output file>_inst.tdf
Text Design File Instantiation Template—Sample AHDL instantiation of the
subdesign in the megafunction wrapper file.
Altera Corporation
October 2007
6–5
Preliminary
Quartus II Handbook, Volume 1
Table 6–1. MegaWizard Plug-In Manager Generated Files (Part 2 of 2)
File
Description
<output file>_bb.v
Black box Verilog HDL Module Declaration—Hollow-body module declaration that
can be used in Verilog HDL designs to specify port directions when creating black
boxes in third-party synthesis tools.
<output file>_syn.v (2)
Synthesis area and timing estimation netlist—Megafunction netlist used by certain
third-party synthesis tools to improve area and timing estimations.
Notes to Table 6–1:
(1)
(2)
The MegaWizard Plug-In Manager generates either the Verilog HDL, VHDL, or AHDL Variation Wrapper File,
depending on the language you select for the output file on the megafunction-selection page of the wizard.
The MegaWizard Plug-In Manager generates this file only if you turn on the Generate a synthesis area and timing
estimation netlist option on the EDA page of the wizard.
Creating a Netlist File for Other Synthesis Tools
When you use certain megafunctions with third-party EDA synthesis
tools (that is, tools other than Quartus II integrated synthesis), you can
optionally create a netlist for area and timing estimation instead of a
wrapper file.
The netlist file is a representation of the customized logic used in the
Quartus II software. The file provides the connectivity of architectural
elements in the megafunction but may not represent true functionality.
This information enables certain third-party synthesis tools to better
report area and timing estimates. In addition, synthesis tools can use the
timing information to focus timing-driven optimizations and improve
the quality of results.
f
For information about support for area and timing estimation netlists in
your synthesis tool, refer to the tool vendor’s documentation or the
appropriate chapter in the Synthesis section in volume 1 of the Quartus II
Handbook.
To generate the netlist, turn on Generate a synthesis area and timing
estimation netlist on the EDA page of the MegaWizard Plug-In Manager.
The netlist file is called <output file>_syn.v.
6–6
Preliminary
Altera Corporation
October 2007
Inferring Multiplier and DSP Functions from HDL Code
Instantiating Megafunctions Using the Port and Parameter
Definition
You can instantiate the megafunction directly in your Verilog HDL,
VHDL, or AHDL code by calling the megafunction and setting its
parameters as you would any other module, component, or subdesign.
f
Refer to the specific megafunction in the Quartus II Help for a list of the
megafunction ports and parameters. Quartus II Help also provides a
sample VHDL component declaration and AHDL function prototype for
each megafunction.
1
Inferring
Multiplier and
DSP Functions
from HDL Code
The following sections describe how to infer multiplier and DSP
functions from generic HDL code, and, if applicable, how to target the
dedicated DSP block architecture in Altera devices:
■
■
f
Altera strongly recommends that you use the MegaWizard
Plug-In Manager for complex megafunctions such as PLLs,
transceivers, and LVDS drivers. For details on using the
MegaWizard Plug-In Manager, refer to “Instantiating
Megafunctions Using the MegaWizard Plug-In Manager” on
page 6–4.
“Multipliers—Inferring the lpm_mult Megafunction from HDL
Code” on page 6–7
“Multiply-Accumulators and Multiply-Adders—Inferring
altmult_accum and altmult_add Megafunctions from HDL Code” on
page 6–10
For synthesis tool features and options, refer to your synthesis tool
documentation or the appropriate chapter in the Synthesis section in
volume 1 of the Quartus II Handbook.
Multipliers—Inferring the lpm_mult Megafunction from HDL
Code
To infer multiplier functions, synthesis tools look for multipliers and
convert them to lpm_mult or altmult_add megafunctions, or may
map them directly to device atoms. For devices with DSP blocks, the
software can implement the function in a DSP block instead of logic,
Altera Corporation
October 2007
6–7
Preliminary
Quartus II Handbook, Volume 1
depending on device utilization. The Quartus II Fitter can also place
input and output registers in DSP blocks (that is, perform register
packing) to improve performance and area utilization.
f
For additional information about the DSP block and the supported
functions, refer to the appropriate Altera device family handbook and
Altera’s DSP Solutions Center website at www.altera.com.
The following four code samples show Verilog HDL and VHDL
examples for unsigned and signed multipliers that synthesis tools can
infer as an lpm_mult or altmult_add megafunction. Each example fits
into one DSP block 9-bit element. In addition, when register packing
occurs, no extra logic cells for registers are required.
1
The signed declaration in Verilog HDL is a feature of the
Verilog 2001 Standard.
Example 6–1. Verilog HDL Unsigned Multiplier
module unsigned_mult (out, a, b);
output [15:0] out;
input [7:0] a;
input [7:0] b;
assign out = a * b;
endmodule
Example 6–2. Verilog HDL Signed Multiplier with Input and Output Registers (Pipelining = 2)
module signed_mult (out, clk, a, b);
output [15:0] out;
input clk;
input signed [7:0] a;
input signed [7:0] b;
reg signed [7:0] a_reg;
reg signed [7:0] b_reg;
reg signed [15:0] out;
wire signed [15:0] mult_out;
assign mult_out = a_reg * b_reg;
always @ (posedge clk)
begin
a_reg <= a;
b_reg <= b;
out <= mult_out;
end
endmodule
6–8
Preliminary
Altera Corporation
October 2007
Inferring Multiplier and DSP Functions from HDL Code
Example 6–3. VHDL Unsigned Multiplier with Input and Output Registers (Pipelining = 2)
LIBRARY ieee;
USE ieee.std_logic_1164.ALL;
USE ieee.numeric_std.all;
ENTITY unsigned_mult IS
PORT (
a: IN UNSIGNED (7 DOWNTO 0);
b: IN UNSIGNED (7 DOWNTO 0);
clk: IN STD_LOGIC;
aclr: IN STD_LOGIC;
result: OUT UNSIGNED (15 DOWNTO 0)
);
END unsigned_mult;
ARCHITECTURE rtl OF unsigned_mult IS
SIGNAL a_reg, b_reg: UNSIGNED (7 DOWNTO 0);
BEGIN
PROCESS (clk, aclr)
BEGIN
IF (aclr ='1') THEN
a_reg <= (OTHERS => '0');
b_reg <= (OTHERS => '0');
result <= (OTHERS => '0');
ELSIF (clk'event AND clk = '1') THEN
a_reg <= a;
b_reg <= b;
result <= a_reg * b_reg;
END IF;
END PROCESS;
END rtl;
Example 6–4. VHDL Signed Multiplier
LIBRARY ieee;
USE ieee.std_logic_1164.ALL;
USE ieee.numeric_std.all;
ENTITY signed_mult IS
PORT (
a: IN SIGNED (7 DOWNTO 0);
b: IN SIGNED (7 DOWNTO 0);
result: OUT SIGNED (15 DOWNTO 0)
);
END signed_mult;
BEGIN
result <= a * b;
END rtl;
Altera Corporation
October 2007
6–9
Preliminary
Quartus II Handbook, Volume 1
Multiply-Accumulators and Multiply-Adders—Inferring
altmult_accum and altmult_add Megafunctions from HDL Code
Synthesis tools detect multiply-accumulators or multiply-adders and
convert them to altmult_accum or altmult_add megafunctions,
respectively, or may map them directly to device atoms. The Quartus II
software then places these functions in DSP blocks during placement and
routing.
1
Synthesis tools infer multiply-accumulator and multiply-adder
functions only if the Altera device family has dedicated DSP
blocks that support these functions.
A multiply-accumulator consists of a multiplier feeding an addition
operator. The addition operator feeds a set of registers that then feeds the
second input to the addition operator. A multiply-adder consists of two
to four multipliers feeding one or two levels of addition, subtraction, or
addition/subtraction operators. Addition is always the second-level
operator, if it is used. In addition to the multiply-accumulator and
multiply-adder, the Quartus II Fitter also places input and output
registers into the DSP blocks to pack registers and improve performance
and area utilization.
The Verilog HDL and VHDL code samples shown in Examples 6–5
through 6–8 infer specific multiply-accumulators and multiply-adders.
6–10
Preliminary
Altera Corporation
October 2007
Inferring Multiplier and DSP Functions from HDL Code
Example 6–5. Verilog HDL Unsigned Multiply-Accumulator with Input, Output and Pipeline Registers
(Latency = 3)
module unsig_altmult_accum (dataout, dataa, datab, clk, aclr, clken);
input [7:0] dataa;
input [7:0] datab;
input clk;
input aclr;
input clken;
output [31:0] dataout;
reg [31:0] dataout;
reg [7:0] dataa_reg;
reg [7:0] datab_reg;
reg [15:0] multa_reg;
wire [15:0] multa;
wire [31:0] adder_out;
assign multa = dataa_reg * datab_reg;
assign adder_out = multa_reg + dataout;
always @ (posedge clk or posedge aclr)
begin
if (aclr)
begin
dataa_reg <= 8'b0;
datab_reg <= 8'b0;
multa_reg <= 16'b0;
dataout <= 32'b0;
end
else if (clken)
begin
dataa_reg <= dataa;
datab_reg <= datab;
multa_reg <= multa;
dataout <= adder_out;
end
end
endmodule
Example 6–6. Verilog HDL Signed Multiply-Adder (Latency = 0)
module sig_altmult_add (dataa, datab, datac, datad, result);
input signed [15:0] dataa;
input signed [15:0] datab;
input signed [15:0] datac;
input signed [15:0] datad;
output [32:0] result;
wire signed [31:0] mult0_result;
wire signed [31:0] mult1_result;
assign mult0_result = dataa * datab;
assign mult1_result = datac * datad;
assign result = (mult0_result + mult1_result);
endmodule
Altera Corporation
October 2007
6–11
Preliminary
Quartus II Handbook, Volume 1
Example 6–7. VHDL Unsigned Multiply-Adder with Input, Output and Pipeline Registers (Latency = 3)
LIBRARY ieee;
USE ieee.std_logic_1164.ALL;
USE ieee.numeric_std.all;
ENTITY unsignedmult_add IS
PORT (
a: IN UNSIGNED (7 DOWNTO
b: IN UNSIGNED (7 DOWNTO
c: IN UNSIGNED (7 DOWNTO
d: IN UNSIGNED (7 DOWNTO
clk: IN STD_LOGIC;
aclr: IN STD_LOGIC;
result: OUT UNSIGNED (15
);
END unsignedmult_add;
0);
0);
0);
0);
DOWNTO 0)
ARCHITECTURE rtl OF unsignedmult_add IS
SIGNAL a_reg, b_reg, c_reg, d_reg: UNSIGNED (7 DOWNTO 0);
SIGNAL pdt_reg, pdt2_reg: UNSIGNED (15 DOWNTO 0);
SIGNAL result_reg: UNSIGNED (15 DOWNTO 0);
BEGIN
PROCESS (clk, aclr)
BEGIN
IF (aclr = '1') THEN
a_reg <= (OTHERS => '0');
b_reg <= (OTHERS => '0');
c_reg <= (OTHERS => '0');
d_reg <= (OTHERS => '0');
pdt_reg <= (OTHERS => '0');
pdt2_reg <= (OTHERS => '0');
ELSIF (clk'event AND clk = '1') THEN
a_reg <= a;
b_reg <= b;
c_reg <= c;
d_reg <= d;
pdt_reg <= a_reg * b_reg;
pdt2_reg <= c_reg * d_reg;
result_reg <= pdt_reg + pdt2_reg;
END IF;
END PROCESS;
result <= result_reg;
END rtl;
6–12
Preliminary
Altera Corporation
October 2007
Inferring Memory Functions from HDL Code
Example 6–8. VHDL Signed Multiply-Accumulator with Input, Output and Pipeline Registers (Latency = 3)
LIBRARY ieee;
USE ieee.std_logic_1164.ALL;
USE ieee.numeric_std.all;
ENTITY sig_altmult_accum IS
PORT (
a: IN SIGNED(7 DOWNTO 0);
b: IN SIGNED (7 DOWNTO 0);
clk: IN STD_LOGIC;
accum_out: OUT SIGNED (15 DOWNTO 0)
) ;
END sig_altmult_accum;
ARCHITECTURE rtl OF sig_altmult_accum IS
SIGNAL a_reg, b_reg: SIGNED (7 DOWNTO 0);
SIGNAL pdt_reg: SIGNED (15 DOWNTO 0);
SIGNAL adder_out: SIGNED (15 DOWNTO 0);
BEGIN
PROCESS (clk)
BEGIN
IF (clk'event and clk = '1') THEN
a_reg <= (a);
b_reg <= (b);
pdt_reg <= a_reg * b_reg;
adder_out <= adder_out + pdt_reg;
END IF;
END process;
accum_out <= adder_out;
END rtl;
Inferring
Memory
Functions from
HDL Code
The following sections describe how to infer memory functions from
generic HDL code and, if applicable, to target the dedicated memory
architecture in Altera devices:
■
■
■
f
“RAM Functions—Inferring altsyncram and altdpram
Megafunctions from HDL Code” on page 6–14
“ROM Functions—Inferring altsyncram and lpm_rom
Megafunctions from HDL Code” on page 6–31
“Shift Registers—Inferring the altshift_taps Megafunction from HDL
Code” on page 6–33
For synthesis tool features and options, refer to your synthesis tool
documentation or the appropriate chapter in the Synthesis section in
volume 1 of the Quartus II Handbook.
Altera's dedicated memory architecture offers a number of advanced
features that can be easily targeted using the MegaWizard Plug-In
Manager as described in “Instantiating Altera Megafunctions in HDL
Code” on page 6–4. The coding recommendations in the following
Altera Corporation
October 2007
6–13
Preliminary
Quartus II Handbook, Volume 1
sections provide portable examples of generic HDL code that infer the
appropriate megafunction. However, if you want to use some of the
advanced memory features in Altera devices, consider using the
megafunction directly so that you can control the ports and parameters
more easily.
RAM Functions—Inferring altsyncram and altdpram
Megafunctions from HDL Code
To infer RAM functions, synthesis tools detect sets of registers and logic
that can be replaced with the altsyncram or altdpram megafunctions
for device families that have dedicated RAM blocks, or may map them
directly to device memory atoms.
Standard synthesis tools recognize single-port and simple dual-port (one
read port and one write port) RAM blocks. Some tools (such as the
Quartus II software) also recognize true dual port RAM blocks that map
to the memory blocks in certain Altera devices. Tools usually do not infer
small RAM blocks because small RAM blocks typically can be
implemented more efficiently using the registers in regular logic.
1
If you are using Quartus II integrated synthesis, you can direct
the software to infer ROM blocks for all sizes with the Allow
Any RAM Size for Recognition option under More Settings on
the Analysis & Synthesis Settings page of the Settings dialog
box.
1
If your design contains a RAM block that your synthesis tool
does not recognize and infer, the design might require a large
amount of system memory that potentially can cause
compilation problems.
Some synthesis tools provide options to control the implementation of
inferred RAM blocks for Altera devices with TriMatrix™ memory blocks.
For example, Quartus II integrated synthesis provides the ramstyle
synthesis attribute to specify the type of memory block or to specify the
use of regular logic instead of a dedicated memory block. Quartus II
integrated synthesis does not map inferred memory into Stratix III
MLABs unless the HDL code specifies the appropriate ramstyle
attribute, although the Fitter may map some memories to MLABs.
f
6–14
Preliminary
For details about using the ramstyle attribute, refer to the Quartus II
Integrated Synthesis chapter in volume 1 of the Quartus II Handbook. For
information about synthesis attributes in other synthesis tools, refer to
the appropriate chapter in the Synthesis section in volume 1 of the
Quartus II Handbook.
Altera Corporation
October 2007
Inferring Memory Functions from HDL Code
When you are using a formal verification flow, Altera recommends that
you create RAM blocks in separate entities or modules that contain only
the RAM logic. In certain formal verification flows, for example, when
using Quartus II integrated synthesis, the entity or module containing the
inferred RAM is put into a black box automatically because formal
verification tools do not support RAM blocks. The Quartus II software
issues a warning message when this occurs. If the entity or module
contains any additional logic outside the RAM block, this logic also must
be treated as a black box for formal verification and therefore cannot be
verified.
This section presents several guidelines for inferring RAM functions that
match the dedicated memory architecture in Altera devices, and then
provides recommended HDL code for different types of memory logic.
Use Synchronous Memory Blocks
Altera recommends using synchronous memory blocks for Altera
designs. The TriMatrix memory blocks in Altera’s newest devices are
synchronous, so RAM designs that are targeted towards architectures
that contain these dedicated memory blocks must be synchronous to be
mapped directly into the device architecture. Asynchronous memory
logic is not inferred as a memory block or placed in the device dedicated
memory blocks; the logic is implemented in regular logic cells.
Synchronous memories are supported in all Altera device families. A
memory block is considered synchronous if it uses one of the following
read behaviors:
■
■
1
Memory read occurs in a Verilog always block with a clock signal or
a VHDL clocked process.
Memory read occurs outside a clocked block, but there is a
synchronous read address (that is, the address used in the read
statement is registered). This type of logic is not always inferred as a
memory block, depending on the target device architecture.
The synchronous memory structures in Altera devices differ
from the structures in other vendors’ devices. Match your
design to the target device architecture to achieve the best
results.
Later subsections provide coding recommendations for various memory
types. All of these examples are synchronous to ensure that they can be
directly mapped into the dedicated memory architecture available in
Altera FPGAs.
Altera Corporation
October 2007
6–15
Preliminary
Quartus II Handbook, Volume 1
f
For additional information about the dedicated memory blocks in your
specific device, refer to the appropriate Altera device family data sheet
on the Altera website at www.altera.com.
Avoid Unsupported Reset Conditions
You cannot clear the RAM contents of Altera memory blocks. If your
HDL code describes a RAM with a reset signal for the RAM contents, the
logic is not inferred as a memory block or mapped to dedicated memory
architecture. As a general rule, avoid putting RAM read or write
operations in an always block or process block with a reset signal.
Example 6–9 shows an example of undesirable code where there is a reset
signal that clears part of the RAM contents. Avoid this coding style
because it is not supported in Altera memories.
Example 6–9. Verilog RAM with Reset Signal that Clears RAM Contents: Not Supported in Device Architecture
module clear_ram
(
input clock,
input reset,
input we,
input [7:0] data_in,
input [4:0] address,
output reg [7:0] data_out
);
reg [7:0] mem [0:31];
integer i;
always @ (posedge clock or posedge reset)
begin
if (reset == 1'b1)
mem[address] <= 0;
else if (we == 1'b1)
mem[address] <= data_in;
data_out <= mem[address];
end
endmodule
6–16
Preliminary
Altera Corporation
October 2007
Inferring Memory Functions from HDL Code
Example 6–10 shows an example of undesirable code where the reset
signal affects the RAM, although the effect may not be intended. Avoid
this coding style because it is not supported in Altera memories.
Example 6–10. Verilog RAM with Reset Signal that Affects RAM: Not Supported in Device Architecture
module bad_reset
(
input clock,
input reset,
input we,
input [7:0] data_in,
input [4:0] address,
output reg [7:0] data_out,
input d,
output reg q
);
reg [7:0] mem [0:31];
integer i;
always @ (posedge clock or posedge reset)
begin
if (reset == 1'b1)
q <= 0;
else
begin
if (we == 1'b1)
mem[address] <= data_in;
data_out <= mem[address];
q <= d;
end
end
endmodule
Check Read-During-Write Behavior
It is important to check the read-during-write behavior of the memory
block described in your HDL design as compared to the behavior in your
target device architecture. HDL source code specifies the memory
behavior when you attempt to read and write from the same memory
address in the same clock cycle. The code specifies that the read returns
either the old data at the address, or the new data being written to the
address. This is referred to as the read-during-write behavior of the
memory block. Altera memory blocks have different read-during-write
behavior depending on the target device family, memory mode and block
type.
Synthesis tools map an HDL design into the target device architecture,
with the goal of maintaining the functionality described in your source
code. In some cases, memory blocks map directly into the device
Altera Corporation
October 2007
6–17
Preliminary
Quartus II Handbook, Volume 1
architecture; however, in some cases, the device architecture cannot
implement the memory behavior described in your source code, so the
logic is not mapped to the dedicated memory blocks in the device. In still
other cases, the software can implement the memory functionality using
some extra logic in addition to the dedicated RAM block. To implement
the behavior in the target device, synthesis software may add bypass
logic around the memory block, which increases the area utilization of the
design and decreases the performance if the memory block is part of the
design's critical path.
In many synthesis tools, you can specify that the read-during-write
behavior is not important to your design; for example, if you never read
from the same address to which you write in the same clock cycle. For
Quartus II integrated synthesis, add the synthesis attribute
ramstyle="no_rw_check" to allow the software to choose the
read-during-write behavior of a RAM, rather than use the behavior
specified by your HDL code. Using this type of attribute prevents the
synthesis tool from using extra logic to implement the memory block, and
in some cases, can allow memory inference when it would otherwise be
impossible.
f
For more information about attribute syntax, the no_rw_check
attribute value, or specific options for your synthesis tool, refer to your
synthesis tool documentation or to the appropriate chapter in the
Synthesis section in volume 1 of the Quartus II Handbook.
The following subsections provide coding recommendations for various
memory types. Each example describes the read-during-write behavior
and addresses the support for the memory type in Altera devices.
Single-Clock Synchronous RAM with Old Data Read-During-Write
Behavior
The code examples in this section show Verilog HDL and VHDL code
that infers simple dual port, single-clock synchronous RAM. Single-port
RAM blocks use a similar coding style.
The read-during-write behavior in these examples is to read the old data
at the memory address. Refer to “Check Read-During-Write Behavior” on
page 6–17 for details. Altera recommends that you use this coding style
as long as your design does not require that a simultaneous read and
write to the same RAM location read the new value that is currently being
written to that RAM location.
If you require that the read-during-write results in new data, refer to
“Single-Clock Synchronous RAM with New Data Read-During-Write
Behavior” on page 6–20.
6–18
Preliminary
Altera Corporation
October 2007
Inferring Memory Functions from HDL Code
The simple dual-port RAM code samples shown in Examples 6–11 and
6–12 map directly into Altera TriMatrix memory.
Single-port versions of memory blocks (that is, using the same read
address and write address signals) can allow better RAM utilization than
dual-port memory blocks, depending on the device family.
Example 6–11. Verilog HDL Single-Clock Simple Dual-Port Synchronous RAM with Old Data Read-DuringWrite Behavior
module single_clk_ram(
output reg [7:0] q,
input [7:0] d,
input [6:0] write_address, read_address,
input we, clk
);
reg [7:0] mem [127:0];
always @ (posedge clk) begin
if (we)
mem[write_address] <= d;
q <= mem[read_address]; // q doesn't get d in this clock cycle
end
endmodule
Altera Corporation
October 2007
6–19
Preliminary
Quartus II Handbook, Volume 1
Example 6–12. VHDL Single-Clock Simple Dual-Port Synchronous RAM with Old Data Read-During-Write
Behavior
LIBRARY ieee;
USE ieee.std_logic_1164.ALL;
ENTITY single_clock_ram IS
PORT (
clock: IN STD_LOGIC;
data: IN STD_LOGIC_VECTOR (2 DOWNTO 0);
write_address: IN INTEGER RANGE 0 to 31;
read_address: IN INTEGER RANGE 0 to 31;
we: IN STD_LOGIC;
q: OUT STD_LOGIC_VECTOR (2 DOWNTO 0)
);
END single_clock_ram;
ARCHITECTURE rtl OF single_clock_ram IS
TYPE MEM IS ARRAY(0 TO 31) OF STD_LOGIC_VECTOR(2 DOWNTO 0);
SIGNAL ram_block: MEM;
BEGIN
PROCESS (clock)
BEGIN
IF (clock'event AND clock = '1') THEN
IF (we = '1') THEN
ram_block(write_address) <= data;
END IF;
q <= ram_block(read_address);
-- VHDL semantics imply that q doesn't get data
-- in this clock cycle
END IF;
END PROCESS;
END rtl;
Single-Clock Synchronous RAM with New Data Read-During-Write
Behavior
These examples describe RAM blocks in which a simultaneous read and
write to the same location reads the new value that is currently being
written to that RAM location.
To implement this behavior in the target device, synthesis software adds
bypass logic around the RAM block. This bypass logic increases the area
utilization of the design and decreases the performance if the RAM block
is part of the design’s critical path. Refer to “Check Read-During-Write
Behavior” on page 6–17 for details. If this behavior is not required for
your design, use the examples from “Single-Clock Synchronous RAM
with Old Data Read-During-Write Behavior” on page 6–18.
The simple dual-port RAM examples shown in Examples 6–13 and 6–14
require bypass the software to create this logic around the RAM block.
6–20
Preliminary
Altera Corporation
October 2007
Inferring Memory Functions from HDL Code
Single-port versions of the Verilog memory block (that is, using the same
read address and write address signals) do not require any logic cells to
create bypass logic in Arria™ GX devices, and Stratix® and Cyclone®
series of devices, because the device memory supports new data readduring-write behavior when in single-port mode (same clock, same read
and write address).
Example 6–13. Verilog HDL Single-Clock Simple Dual-Port Synchronous RAM with New Data Read-DuringWrite Behavior
module single_clock_wr_ram(
output reg [7:0] q,
input [7:0] d,
input [6:0] write_address, read_address,
input we, clk
);
reg [7:0] mem [127:0];
always @ (posedge clk) begin
if (we)
mem[write_address] = d;
q = mem[read_address]; // q does get d in this clock cycle if we is high
end
endmodule
Note that Example 6–13 is similar to Example 6–11, but Example 6–13
uses a blocking assignment for the write so that the data is assigned
immediately.
An alternative way to create a single-clock RAM is to use an assign
statement to read the address of mem to create the output q, as shown in
following the coding style. By itself, the code describes new data
read-during-write behavior. However, if the RAM output feeds a register
in another hierarchy, then a read-during-write would result in the old
data. Synthesis tools may not infer a RAM block if the tool cannot
determine which behavior is described, such as when the memory feeds
a hard hierarchical partition boundary. For this reason, avoid using this
alternate type of coding style.
reg [7:0] mem [127:0];
reg [6:0] read_address_reg;
always @ (posedge clk) begin
if (we)
mem[write_address] <= d;
read_address_reg <= read_address;
end
assign q = mem[read_address_reg];
Altera Corporation
October 2007
6–21
Preliminary
Quartus II Handbook, Volume 1
Example 6–14 uses a concurrent signal assignment to read from the RAM.
By itself, this example describes new data read-during-write behavior.
However, if the RAM output feeds a register in another hierarchy, then a
read-during-write would result in the old data. Synthesis tools may not
infer a RAM block if the tool cannot determine which behavior is
described, such as when the memory feeds a hard hierarchical partition
boundary.
Example 6–14. VHDL Single-Clock Simple Dual-Port Synchronous RAM with New Data Read-During-Write
Behavior
LIBRARY ieee;
USE ieee.std_logic_1164.ALL;
ENTITY single_clock_rw_ram IS
PORT (
clock: IN STD_LOGIC;
data: IN STD_LOGIC_VECTOR (2 DOWNTO 0);
write_address: IN INTEGER RANGE 0 to 31;
read_address: IN INTEGER RANGE 0 to 31;
we: IN STD_LOGIC;
q: OUT STD_LOGIC_VECTOR (2 DOWNTO 0)
);
END single_clock_rw_ram;
ARCHITECTURE rtl OF single_clock_rw_ram IS
TYPE MEM IS ARRAY(0 TO 31) OF STD_LOGIC_VECTOR(2 DOWNTO 0);
SIGNAL ram_block: MEM;
SIGNAL read_address_reg: INTEGER RANGE 0 to 31;
BEGIN
PROCESS (clock)
BEGIN
IF (clock'event AND clock = '1') THEN
IF (we = '1') THEN
ram_block(write_address) <= data;
END IF;
read_address_reg <= read_address;
END IF;
END PROCESS;
q <= ram_block(read_address_reg);
END rtl;
This example does not infer a RAM block for APEX, ACEX, or FLEX
devices by default because the read-during-write behavior depends on
surrounding logic. For Quartus II integrated synthesis, if you do not
require the read-through-write capability, add the synthesis attribute
ramstyle="no_rw_check" to allow the software to choose the
read-during-write behavior of a RAM, rather than use the behavior
specified by your HDL code.
6–22
Preliminary
Altera Corporation
October 2007
Inferring Memory Functions from HDL Code
Simple Dual-Port, Dual-Clock Synchronous RAM
In dual clock designs, synthesis tools cannot accurately infer the
read-during-write behavior because it depends on the timing of the two
clocks within the target device. Therefore, the read-during-write
behavior of the synthesized design is undefined and may differ from
your original HDL code. Refer to “Check Read-During-Write Behavior”
on page 6–17 for details.
When Quartus II integrated synthesis infers this type of RAM, it issues a
warning because of the undefined read-during-write behavior. If this
functionality is acceptable in your design, you can avoid the warning by
adding the synthesis attribute ramstyle="no_rw_check" to allow the
software to choose the read-during-write behavior of a RAM.
The code samples shown in Examples 6–15 and 6–16 show Verilog HDL
and VHDL code that infers dual-clock synchronous RAM. The exact
behavior depends on the relationship between the clocks.
Example 6–15. Verilog HDL Simple Dual-Port, Dual-Clock Synchronous RAM
module dual_clock_ram(
output reg [7:0] q,
input [7:0] d,
input [6:0] write_address, read_address,
input we, clk1, clk2
);
reg [6:0] read_address_reg;
reg [7:0] mem [127:0];
always @ (posedge clk1)
begin
if (we)
mem[write_address] <= d;
end
always @ (posedge clk2) begin
q <= mem[read_address_reg];
read_address_reg <= read_address;
end
endmodule
Example 6–16. VHDL Simple Dual-Port, Dual-Clock Synchronous RAM
LIBRARY ieee;
USE ieee.std_logic_1164.ALL;
ENTITY dual_clock_ram IS
PORT (
clock1, clock2: IN STD_LOGIC;
data: IN STD_LOGIC_VECTOR (3 DOWNTO 0);
write_address: IN INTEGER RANGE 0 to 31;
read_address: IN INTEGER RANGE 0 to 31;
we: IN STD_LOGIC;
q: OUT STD_LOGIC_VECTOR (3 DOWNTO 0)
Altera Corporation
October 2007
6–23
Preliminary
Quartus II Handbook, Volume 1
);
END dual_clock_ram;
ARCHITECTURE rtl OF dual_clock_ram IS
TYPE MEM IS ARRAY(0 TO 31) OF STD_LOGIC_VECTOR(3 DOWNTO 0);
SIGNAL ram_block: MEM;
SIGNAL read_address_reg : INTEGER RANGE 0 to 31;
BEGIN
PROCESS (clock1)
BEGIN
IF (clock1'event AND clock1 = '1') THEN
IF (we = '1') THEN
ram_block(write_address) <= data;
END IF;
END IF;
END PROCESS;
PROCESS (clock2)
BEGIN
IF (clock2'event AND clock2 = '1') THEN
q <= ram_block(read_address_reg);
read_address_reg <= read_address;
END IF;
END PROCESS;
END rtl;
True Dual-Port Synchronous RAM
The code examples in this section show Verilog HDL and VHDL code
that infers true dual-port synchronous RAM. Different synthesis tools
may differ in their support for these types of memories. This section
describes the inference rules for Quartus II integrated synthesis. This type
of RAM inference is supported only for Arria GX devices, and the Stratix
and Cyclone series of devices.
Altera TriMatrix memory blocks have two independent address ports,
allowing for operations on two unique addresses simultaneously. A read
operation and a write operation can share the same port if they share the
same address. The Quartus II software infers true dual-port RAMs in
Verilog HDL and VHDL with any combination of independent read or
write operations in the same clock cycle, with at most two unique port
addresses, performing two reads and one write, two writes and one read,
or two writes and two reads in one clock cycle with one or two unique
addresses.
In the TriMatrix RAM block architecture, there is no priority between the
two ports. Therefore if you write to the same location on both ports at the
same time, the result is indeterminate. You must ensure your HDL code
does not imply priority for writes to the memory block. For example, if
both ports are defined in the same process block, the code is synthesized
6–24
Preliminary
Altera Corporation
October 2007
Inferring Memory Functions from HDL Code
and simulated sequentially so there would be a priority between the two
ports. If you code does imply a priority, the logic cannot be implemented
in the device RAM blocks.
You must also consider the read-during-write behavior of the RAM
block, to ensure that it can be mapped directly to the device RAM
architecture. Refer to “Check Read-During-Write Behavior” on page 6–17
for details.
When a read and write operation occur on the same port for the same
address, the read operation may behave as follows:
■
■
Read new data. This mode matches the behavior of TriMatrix
memory blocks.
Read old data. This mode is supported only by Stratix III and
Cyclone III TriMatrix memory blocks. This behavior is not possible
in TriMatrix memory blocks of other families.
When a read and write operation occur on different ports for the same
address (also known as mixed port), the read operation may behave as
follows:
■
■
Read new data. Quartus II integrated synthesis supports this mode
by creating bypass logic around the TriMatrix memory block.
Read old data. This behavior is supported by TriMatrix memory
blocks.
The Verilog HDL single-clock code sample shown in Example 6–17 maps
directly into Altera TriMatrix memory. When a read and write operation
occur on the same port for the same address, the new data being written
to the memory is read. When a read and write operation occur on
different ports for the same address, the old data in the memory is read.
Simultaneous writes to the same location on both ports results in
indeterminate behavior.
A dual-clock version of this design describes the same behavior, but the
memory in the target device will have undefined mixed port readduring-write behavior because it depends on the relationship between
the clocks.
Example 6–17. Verilog HDL True Dual-Port RAM with Single Clock
module true_dual_port_ram_single_clock
(
input [(DATA_WIDTH-1):0] data_a, data_b,
input [(ADDR_WIDTH-1):0] addr_a, addr_b,
input we_a, we_b, clk,
output reg [(DATA_WIDTH-1):0] q_a, q_b
);
Altera Corporation
October 2007
6–25
Preliminary
Quartus II Handbook, Volume 1
parameter DATA_WIDTH = 8;
parameter ADDR_WIDTH = 6;
// Declare the RAM variable
reg [DATA_WIDTH-1:0] ram[2**ADDR_WIDTH-1:0];
always @ (posedge clk)
begin // Port A
if (we_a)
begin
ram[addr_a] <= data_a;
q_a <= data_a;
end
else
q_a <= ram[addr_a];
always @ (posedge clk)
begin // Port b
if (we_b)
begin
ram[addr_b] <= data_b;
q_b <= data_b;
end
else
q_b <= ram[addr_b];
end
endmodule
If you use Verilog read statements shown below instead of the if-else
statements in Example 6–17, the read results in old data when a read and
write operation occur at the same time for the same address on the same
port or mixed ports. This behavior is supported only in the TriMatrix
memories of Stratix III and Cyclone III devices, and is not inferred as
memory for other device families.
always @ (posedge clk)
begin // Port A
if (we_a)
ram[addr_a] <= data_a;
q_a <= ram[addr_a];
end
always @ (posedge clk)
begin // Port B
if (we_b)
ram[addr_b] <= data_b;
q_b <= ram[addr_b];
end
The VHDL single-clock code sample shown in Example 6–18 maps
directly into Altera TriMatrix memory. When a read and write operation
occur on the same port for the same address, the new data being written
to the memory is read. When a read and write operation occur on
6–26
Preliminary
Altera Corporation
October 2007
Inferring Memory Functions from HDL Code
different ports for the same address, the old data in the memory is read.
Simultaneous writes to the same location on both ports results in
indeterminate behavior.
A dual-clock version of this design describes the same behavior, but the
memory in the target device will have undefined mixed port readduring-write behavior because it depends on the relationship between
the clocks.
Example 6–18. VHDL True Dual-Port RAM with Single Clock
library ieee;
use ieee.std_logic_1164.all;
entity true_dual_port_ram_single_clock is
generic
(
DATA_WIDTH : natural := 8;
ADDR_WIDTH : natural := 6
);
port
(
clk : in std_logic;
addr_a: in natural range 0 to 2**ADDR_WIDTH - 1;
addr_b: in natural range 0 to 2**ADDR_WIDTH - 1;
data_a: in std_logic_vector((DATA_WIDTH-1) downto
data_b: in std_logic_vector((DATA_WIDTH-1) downto
we_a: in std_logic := '1';
we_b: in std_logic := '1';
q_a : out std_logic_vector((DATA_WIDTH -1) downto
q_b : out std_logic_vector((DATA_WIDTH -1) downto
0);
0);
0)
0)
);
end true_dual_port_ram_single_clock;
architecture rtl of true_dual_port_ram_single_clock is
-- Build a 2-D array type for the RAM
subtype word_t is std_logic_vector((DATA_WIDTH-1) downto 0);
type memory_t is array(raddr'high downto 0) of word_t;
-- Declare the RAM signal.
signal ram : memory_t;
begin
process(clk)
begin
if(rising_edge(clk)) then -- Port A
if(we_a = '1') then
ram(addr_a) <= data_a;
-- Read-during-write on the same port returns NEW data
q_a <= data_a;
else
-- Read-during-write on the mixed port returns OLD data
Altera Corporation
October 2007
6–27
Preliminary
Quartus II Handbook, Volume 1
q_a <= ram(addr_a);
end if;
end process;
process(clk)
begin
if(rising_edge(clk)) then -- Port B
if(we_b = '1') then
ram(addr_b) <= data_b;
-- Read-during-write on the same port returns NEW data
q_b <= data_b;
else
-- Read-during-write on the mixed port returns OLD data
q_b <= ram(addr_b);
end if;
end if;
end process;
end rtl;
Specifying Initial Memory Contents at Power-Up
Your synthesis tool may offer various ways to specify the initial contents
of an inferred memory.
6–28
Preliminary
1
Certain device memory types do not support initialized
memory, such as the M-RAM blocks in Stratix and Stratix II
devices.
1
Note that there are slight power-up and initialization
differences between dedicated RAM blocks and the Stratix III
MLAB memory due to the continuous read of the MLAB. Altera
dedicated RAM block outputs always power-up to zero and are
set to the initial value on the first read. For example, if address 0
is pre-initialized to FF, the RAM block powers up with the
output at 0. A subsequent read after power up from address 0
outputs the pre-initialized value of FF. Therefore, if a RAM is
powered up and an enable (read enable or clock enable) is held
low, then the power-up output of “0” is maintained until the
first valid read cycle. The Stratix III MLAB is implemented using
registers that power-up to 0, but are initialized to their initial
value immediately at power-up or reset. You will therefore see
the initial value regardless of the enable status. Quartus II
integrated synthesis does not map inferred memory to MLABs
unless the HDL code specifies the appropriate ramstyle
attribute.
Altera Corporation
October 2007
Inferring Memory Functions from HDL Code
Quartus II integrated synthesis supports the ram_init_file synthesis
attribute that allows you to specify a Memory Initialization File (.mif) for
an inferred RAM block.
f
For information about the ram_init_file attribute, refer to the
Quartus II Integrated Synthesis chapter in volume 1 of the Quartus II
Handbook. For information about synthesis attributes in other synthesis
tools, refer to the tool vendor’s documentation.
In Verilog HDL, you can use an initial block to initialize the contents of
an inferred memory. Quartus II integrated synthesis automatically
converts the initial block into a MIF for the inferred RAM. Example 6–19
shows Verilog HDL code that infers a simple dual-port RAM block and
corresponding MIF file.
Example 6–19. Verilog HDL RAM with Initialized Contents
module ram_with_init(
output reg [7:0] q,
input [7:0] d,
input [4:0] write_address, read_address,
input we, clk
);
reg [7:0] mem [0:31];
integer i;
initial begin
for (i = 0; i < 32; i = i + 1)
mem[i] = i[7:0];
end
always @ (posedge clk) begin
if (we)
mem[write_address] <= d;
q <= mem[read_address];
end
endmodule
Quartus II integrated synthesis and other synthesis tools also support the
$readmemb and $readmemh commands so that RAM and ROM
initialization work identically in synthesis and simulation. Example 6–20
shows an initial block that initializes an inferred RAM block using the
$readmemb command.
Example 6–20. Verilog HDL RAM Initialized with the readmemb Command
reg [7:0] ram[0:15];
initial
begin
$readmemb("ram.txt", ram);
end
Altera Corporation
October 2007
6–29
Preliminary
Quartus II Handbook, Volume 1
In VHDL, you can initialize the contents of an inferred memory by
specifying a default value for the corresponding signal. Quartus II
integrated synthesis automatically converts the default value into a MIF
for the inferred RAM. Example 6–21 shows VHDL code that infers a
simple dual-port RAM block and corresponding MIF file.
Example 6–21. VHDL RAM with Initialized Contents
LIBRARY ieee;
USE ieee.std_logic_1164.ALL;
use ieee.numeric_std.all;
ENTITY ram_with_init IS
PORT(
clock: IN STD_LOGIC;
data: IN UNSIGNED (7 DOWNTO 0);
write_address: IN integer RANGE 0 to 31;
read_address: IN integer RANGE 0 to 31;
we: IN std_logic;
q: OUT UNSIGNED (7 DOWNTO 0));
END;
ARCHITECTURE rtl OF ram_with_init IS
TYPE MEM IS ARRAY(31 DOWNTO 0) OF unsigned(7 DOWNTO 0);
FUNCTION initialize_ram
return MEM is
variable result : MEM;
BEGIN
FOR i IN 31 DOWNTO 0 LOOP
result(i) := to_unsigned(natural(i), natural'(8));
END LOOP;
RETURN result;
END initialize_ram;
SIGNAL ram_block : MEM := initialize_ram;
BEGIN
PROCESS (clock)
BEGIN
IF (clock'event AND clock = '1') THEN
IF (we = '1') THEN
ram_block(write_address) <= data;
END IF;
q <= ram_block(read_address);
END IF;
END PROCESS;
END rtl;
6–30
Preliminary
Altera Corporation
October 2007
Inferring Memory Functions from HDL Code
ROM Functions—Inferring altsyncram and lpm_rom
Megafunctions from HDL Code
To infer ROM functions, synthesis tools detect sets of registers and logic
that can be replaced with the altsyncram or lpm_rom megafunctions,
depending on the target device family, only for device families that have
dedicated memory blocks.
ROMs are inferred when a case statement exists in which a value is set
to a constant for every choice in the case statement. Because small ROMs
typically achieve the best performance when they are implemented using
the registers in regular logic, each ROM function must meet a minimum
size requirement to be inferred and placed into memory.
1
If you are using Quartus II integrated synthesis, you can direct
the software to infer ROM blocks for all sizes with the Allow
Any ROM Size for Recognition option under More Settings on
the Analysis & Synthesis Settings page of the Settings dialog
box.
Some synthesis tools provide options to control the implementation of
inferred ROM blocks for Altera devices with TriMatrix memory blocks.
For example, Quartus II integrated synthesis provides the romstyle
synthesis attribute to specify the type of memory block or to specify the
use of regular logic instead of a dedicated memory block.
f
For details about using the romstyle attribute, refer to the Quartus II
Integrated Synthesis chapter in volume 1 of the Quartus II Handbook. For
information about synthesis attributes in other synthesis tools, refer to
the appropriate chapter in the Synthesis section in volume 1 of the
Quartus II Handbook.
When you are using a formal verification flow, Altera recommends that
you create ROM blocks in separate entities or modules that contain only
the ROM logic because you may need to treat the entity and module as a
black box during formal verification.
1
Because formal verification tools do not support ROM
megafunctions, Quartus II integrated synthesis does not infer
ROM megafunctions when a formal verification tool is selected.
The Verilog HDL and VHDL code samples shown in Examples 6–22
and 6–23 infer synchronous ROM blocks. Depending on the device
family’s dedicated RAM architecture, the ROM logic may have to be
synchronous; consult the device family handbook for details.
Altera Corporation
October 2007
6–31
Preliminary
Quartus II Handbook, Volume 1
For device architectures with synchronous RAM blocks, such as the
Stratix series devices and newer device families, either the address or the
output has to be registered for ROM code to be inferred. When output
registers are used, the registers are implemented using the input registers
of the RAM block, but the functionality of the ROM is not changed. If you
register the address, the power-up state of the inferred ROM can be
different from the HDL design. In this scenario, the synthesis software
issues a warning. The Quartus II Help explains the condition under
which the functionality changes when you are using Quartus II
integrated synthesis.
These ROM code samples map directly to the Altera TriMatrix memory
architecture.
Example 6–22. Verilog HDL Synchronous ROM
module sync_rom (clock, address, data_out);
input clock;
input [7:0] address;
output [5:0] data_out;
reg [5:0] data_out;
always @ (posedge clock)
begin
case (address)
8'b00000000: data_out
8'b00000001: data_out
...
8'b11111110: data_out
8'b11111111: data_out
endcase
end
endmodule
= 6'b101111;
= 6'b110110;
= 6'b000001;
= 6'b101010;
Example 6–23. VHDL Synchronous ROM
LIBRARY ieee;
USE ieee.std_logic_1164.ALL;
ENTITY sync_rom IS
PORT (
clock: IN STD_LOGIC;
address: IN STD_LOGIC_VECTOR(7 downto 0);
data_out: OUT STD_LOGIC_VECTOR(5 downto 0)
);
END sync_rom;
ARCHITECTURE rtl OF sync_rom IS
BEGIN
PROCESS (clock)
BEGIN
IF rising_edge (clock) THEN
CASE address IS
6–32
Preliminary
Altera Corporation
October 2007
Inferring Memory Functions from HDL Code
WHEN "00000000" => data_out <= "101111";
WHEN "00000001" => data_out <= "110110";
...
WHEN "11111110" => data_out <= "000001";
WHEN "11111111" => data_out <= "101010";
WHEN OTHERS => data_out <= "101111";
END CASE;
END IF;
END PROCESS;
END rtl;
Shift Registers—Inferring the altshift_taps Megafunction from
HDL Code
To infer shift registers, synthesis tools detect a group of shift registers of
the same length and convert them to an altshift_taps megafunction.
To be detected, all the shift registers must have the following
characteristics:
■
■
■
Use the same clock and clock enable
Do not have any other secondary signals
Have equally spaced taps that are at least three registers apart
When you are using a formal verification flow, Altera recommends that
you create shift register blocks in separate entities or modules containing
only the shift register logic, because you may need to treat the entity or
module as a black box during formal verification.
1
Because formal verification tools do not support shift register
megafunctions, the Quartus II integrated synthesis does not
infer the altshift_taps megafunction when a formal
verification tool is selected. You can select EDA tools for use
with your Quartus II project on the EDA Tool Settings page of
the Settings dialog box.
Synthesis software recognizes shift registers only for device families that
have dedicated RAM blocks and the software uses certain guidelines to
determine the best implementation. The following guidelines are
followed in Quartus II integrated synthesis and also are generally
followed by other EDA tools:
■
■
Altera Corporation
October 2007
For FLEX® 10K and ACEX® 1K devices, the software does not infer
altshift_taps megafunctions because FLEX 10K and ACEX 1K
devices have a relatively small amount of dedicated memory.
For APEX™ 20K and APEX II devices, the software infers the
altshift_taps megafunction only if the shift register has more
than a total of 128 bits. Smaller shift registers typically do not benefit
from implementation in dedicated memory.
6–33
Preliminary
Quartus II Handbook, Volume 1
■
For Arria GX devices, and the Stratix and Cyclone series devices, the
software determines whether to infer the altshift_taps
megafunction based on the width of the registered bus (W), the
length between each tap (L), and the number of taps (N).
●
If the registered bus width is one (W = 1), the software infers
altshift_taps if the number of taps times the length
between each tap is greater than or equal to 64 (N × L ≥ 64).
●
If the registered bus width is greater than one (W > 1), the
software infers altshift_taps if the registered bus width
times the number of taps times the length between each tap is
greater than or equal to 32 (W × N × L ≥ 12).
If the length between each tap (L) is not a power of two, the software uses
more logic to decode the read and write counters. This situation occurs
because for different sizes of shift registers, external decode logic that
uses logic elements (LEs) or Adaptive Logic Modules (ALMs) is required
to implement the function. This decode logic eliminates the performance
and utilization advantages of implementing shift registers in memory.
The registers that the software maps to the altshift_taps
megafunction and places in RAM are not available in a Verilog HDL or
VHDL output file for simulation tools because their node names do not
exist after synthesis.
Simple Shift Register
The code sample shown in Example 6–24 and Example 6–25 show a
simple, single-bit wide, 64-bit long shift register. The synthesis software
implements the register (W = 1 and M = 64) in an altshift_taps
megafunction for supported devices. If the length of the register is less
than 64 bits, the software implements the shift register in logic.
Example 6–24. Verilog HDL Single-Bit Wide, 64-Bit Long Shift Register
module shift_1x64 (clk, shift, sr_in, sr_out);
input clk, shift;
input sr_in;
output sr_out;
reg [63:0] sr;
always @ (posedge clk)
begin
if (shift == 1'b1)
begin
sr[63:1] <= sr[62:0];
sr[0] <= sr_in;
end
end
assign sr_out = sr[63];
endmodule
6–34
Preliminary
Altera Corporation
October 2007
Inferring Memory Functions from HDL Code
Example 6–25. VHDL Single-Bit Wide, 64-Bit Long Shift Register
LIBRARY IEEE;
USE IEEE.STD_LOGIC_1164.ALL;
ENTITY shift_1x64 IS
PORT (
clk: IN STD_LOGIC;
shift: IN STD_LOGIC;
sr_in: IN STD_LOGIC;
sr_out: OUT STD_LOGIC
);
END shift_1x64;
ARCHITECTURE arch OF shift_1x64 IS
TYPE sr_length IS ARRAY (63 DOWNTO 0) OF STD_LOGIC;
SIGNAL sr: sr_length;
BEGIN
PROCESS (clk)
BEGIN
IF (clk'EVENT and clk = '1') THEN
IF (shift = '1') THEN
sr(63 DOWNTO 1) <= sr(62 DOWNTO 0);
sr(0) <= sr_in;
END IF;
END IF;
END PROCESS;
sr_out <= sr(63);
END arch;
Shift Register with Evenly Spaced Taps
The code samples shown in Examples 6–26 and 6–27 show a Verilog HDL
and VHDL 8-bit wide, 64-bit long shift register (W > 1 and M = 64) with
evenly spaced taps at 15, 31, and 47. The synthesis software implements
this function in a single altshift_taps megafunction and maps it to
RAM in supported devices.
Example 6–26. Verilog HDL 8-Bit Wide, 64-Bit Long Shift Register with Evenly Spaced Taps
module shift_8x64_taps (clk, shift, sr_in, sr_out, sr_tap_one, sr_tap_two, sr_tap_three );
input clk, shift;
input [7:0] sr_in;
output [7:0] sr_tap_one, sr_tap_two, sr_tap_three, sr_out;
reg [7:0] sr [63:0];
integer n;
always @ (posedge clk)
begin
if (shift == 1'b1)
begin
for (n = 63; n>0; n = n-1)
begin
sr[n] <= sr[n-1];
end
Altera Corporation
October 2007
6–35
Preliminary
Quartus II Handbook, Volume 1
sr[0] <= sr_in;
end
end
assign
assign
assign
assign
endmodule
sr_tap_one = sr[15];
sr_tap_two = sr[31];
sr_tap_three = sr[47];
sr_out = sr[63];
Example 6–27. VHDL 8-Bit Wide, 64-Bit Long Shift Register with Evenly Spaced Taps
LIBRARY IEEE;
USE IEEE.STD_LOGIC_1164.ALL;
ENTITY shift_8x64_taps IS
PORT (
clk: IN STD_LOGIC;
shift: IN STD_LOGIC;
sr_in: IN STD_LOGIC_VECTOR(7 DOWNTO 0);
sr_tap_one: OUT STD_LOGIC_VECTOR(7 DOWNTO 0);
sr_tap_two : OUT STD_LOGIC_VECTOR(7 DOWNTO 0);
sr_tap_three: OUT STD_LOGIC_VECTOR(7 DOWNTO 0);
sr_out: OUT STD_LOGIC_VECTOR(7 DOWNTO 0)
);
END shift_8x64_taps;
ARCHITECTURE arch OF shift_8x64_taps IS
SUBTYPE sr_width IS STD_LOGIC_VECTOR(7 DOWNTO 0);
TYPE sr_length IS ARRAY (63 DOWNTO 0) OF sr_width;
SIGNAL sr: sr_length;
BEGIN
PROCESS (clk)
BEGIN
IF (clk'EVENT and clk = '1') THEN
IF (shift = '1') THEN
sr(63 DOWNTO 1) <= sr(62 DOWNTO 0);
sr(0) <= sr_in;
END IF;
END IF;
END PROCESS;
sr_tap_one <= sr(15);
sr_tap_two <= sr(31);
sr_tap_three <= sr(47);
sr_out <= sr(63);
END arch;
6–36
Preliminary
Altera Corporation
October 2007
Coding Guidelines for Registers and Latches
Coding
Guidelines for
Registers and
Latches
This section provides device-specific coding recommendations for Altera
registers and latches. Understanding the architecture of the target Altera
device helps ensure that your code provides the expected results and
achieves the optimal quality of results.
This section provides guidelines in the following areas:
■
■
■
“Register Power-Up Values in Altera Devices”
“Secondary Register Control Signals Such as Clear and Clock
Enable” on page 6–39
“Latches” on page 6–43
Register Power-Up Values in Altera Devices
Registers in the device core always power up to a low (0) logic level on all
Altera devices. However, there are ways to implement logic such that
registers behave as if they were powering up to a high (1) logic level.
If you use a preset signal on a device that does not support presets in the
register architecture, then your synthesis tool may convert the preset
signal to a clear signal, which requires synthesis to perform an
optimization referred to as NOT gate push-back. NOT gate push-back adds
an inverter to the input and the output of the register so that the reset and
power-up conditions will appear to be high but the device operates as
expected. In this case, your synthesis tool may issue a message informing
you about the power-up condition. The register itself powers up low, but
the register output is inverted so the signal that arrives at all destinations
is high.
Due to these effects, if you specify a non-zero reset value, you may cause
your synthesis tool to use the asynchronous clear (aclr) signals available
on the registers to implement the high bits with NOT gate push-back. In
that case, the registers look as though they power up to the specified reset
value. You see this behavior, for example, if your design targets
FLEX 10KE or ACEX devices.
When a load signal is available in the device, your synthesis tools can
implement a reset of 1 or 0 value by using an asynchronous load of 1 or
0. When the synthesis tool uses an asynchronous load signal, it is not
performing NOT gate push-back, so the registers power up to a 0 logic
level.
f
Altera Corporation
October 2007
For additional details, refer to the appropriate device family handbook
or the appropriate handbook of the Altera website at www.altera.com.
6–37
Preliminary
Quartus II Handbook, Volume 1
Designers typically use an explicit reset signal for the design, which
forces all registers into their appropriate values after reset but not
necessarily at power-up. You can create your design such that the
asynchronous reset allows the board to operate in a safe condition and
then you can bring up the design with the reset active. This is a good
practice so you do not depend on the power-up conditions of the device.
You can make the your design more stable and avoid potential glitches by
synchronizing external or combinational logic of the device architecture
before you drive the asynchronous control ports of registers.
f
For additional information about good synchronous design practices,
refer to the Design Recommendations for Altera Devices chapter in volume 1
of the Quartus II Handbook.
If you want to force a particular power-up condition for your design, use
the synthesis options available in your synthesis tool. With Quartus II
integrated synthesis, you can apply the Power-Up Level logic option.
You can also apply the option with an altera_attribute assignment
in your source code. Using this option forces synthesis to perform NOT
gate push-back because synthesis tools cannot actually change the
power-up states of core registers.
You can apply the Quartus II integrated synthesis Power-Up Level
assignment to a specific register or to a design entity, module or
subdesign. If you do so, every register in that block receives the value.
Registers power up to 0 by default; therefore you can use this assignment
to force all registers to power up to 1 using NOT gate push-back.
1
f
6–38
Preliminary
Be aware that using NOT gate push-back as a global assignment
could slightly degrade the quality of results due to the number
of inverters that are needed. In some situations, issues are
caused by enable or secondary control logic inference. It may
also be more difficult to migrate such a design to an ASIC or a
HardCopy® device. You can simulate the power-up behavior in
a functional simulation if you use initialization.
The Power-Up Level option and the altera_attribute assignment
are described in the Quartus II Integrated Synthesis chapter in volume 1 of
the Quartus II Handbook.
Altera Corporation
October 2007
Coding Guidelines for Registers and Latches
Some synthesis tools can also read the default or initial values for
registered signals and implement this behavior in the device. For
example, Quartus II integrated synthesis converts default values for
registered signals into Power-Up Level settings. That way, the
synthesized behavior matches the power-up state of the HDL code
during a functional simulation.
For example, the code samples in Example 6–28 and Example 6–29 both
infer a register for q and set its power-up level to high (while the reset
value is 0).
Example 6–28. Verilog Register with Reset and High Power-Up Value
reg q = 1’b1;
always @ (posedge clk or posedge aclr)
begin
if (aclr)
q <= 1'b0;
else
q <= d;
end
Example 6–29. VHDL Register with Reset and High Power-Up Level
SIGNAL q : STD_LOGIC := '1'; -- q has a default value of '1'
PROCESS (clk, reset)
BEGIN
IF (reset = '1') THEN
q <= '0';
ELSIF (rising_edge(clk)) THEN
q <= d;
END IF;
END PROCESS;
Secondary Register Control Signals Such as Clear and Clock
Enable
FPGA device architectures contain registers, also known as “flipflops”.
The registers in Altera FPGAs provide a number of secondary control
signals (such as clear and enable signals) that you can use to implement
control logic for each register without using extra logic cells. Device
families vary in their support for secondary signals, so consult the device
family data sheet to verify which signals are available in your target
device.
Altera Corporation
October 2007
6–39
Preliminary
Quartus II Handbook, Volume 1
To make the most efficient use of the signals in the device, your HDL code
should match the device architecture as closely as possible. The control
signals have a certain priority due to the nature of the architecture, so
your HDL code should follow that priority where possible.
Your synthesis tool can emulate any control signals using regular logic,
so getting functionally correct results is always possible. However, if
your design requirements are flexible in terms of which control signals
are used and in what priority, match your design to the target device
architecture to achieve the most efficient results. If the priority of the
signals in your design is not the same as that of the target architecture,
then extra logic may be required to implement the control signals. This
extra logic uses additional device resources, and can cause additional
delays for the control signals.
In addition, there are certain cases where using logic other than the
dedicated control logic in the device architecture can have a larger
impact. For example, the clock enable signal has priority over the
synchronous reset or clear signal in the device architecture. The clock
enable turns off the clock line in the logic array block (LAB), and the clear
signal is synchronous. So in the device architecture, the synchronous
clear takes effect only when a clock edge occurs.
If you code a register with a synchronous clear signal that has priority
over the clock enable signal, the software must emulate the clock enable
functionality using data inputs to the registers. Because the signal does
not use the clock enable port of a register, you cannot apply a Clock
Enable Multicycle constraint. In this case, following the priority of signals
available in the device is clearly the best choice for the priority of these
control signals, and using a different priority causes unexpected results
with an assignment to the clock enable signal.
1
6–40
Preliminary
The priority order for secondary control signals in Altera
devices differs from the order for other vendors’ devices. If your
design requirements are flexible regarding priority, verify that
the secondary control signals meet design performance
requirements when migrating designs between FPGA vendors
and try to match your target device architecture to achieve the
best results.
Altera Corporation
October 2007
Coding Guidelines for Registers and Latches
The signal order is the same for all Altera device families, although as
noted previously, not all device families provide every signal. The
following priority order is observed:
1.
2.
3.
4.
5.
6.
7.
Asynchronous Clear, aclr—highest priority
Preset, pre
Asynchronous Load, aload
Enable, ena
Synchronous Clear, sclr
Synchronous Load, sload
Data In, data—lowest priority
The following examples provide Verilog HDL and VHDL code that
creates a register with the aclr, aload, and ena control signals.
1
The Verilog HDL example (Example 6–30) does not have adata
on the sensitivity list, but the VHDL example (Example 6–31)
does. This is a limitation of the Verilog HDL language—there is
no way to describe an asynchronous load signal (in which q
toggles if adata toggles while aload is high). All synthesis
tools should infer an aload signal from this construct despite
this limitation. When they perform such inference, you may see
information or warning messages from the synthesis tool.
Example 6–30. Verilog HDL D-Type Flipflop (Register) with ena, aclr and aload Control Signals
module dff_control(clk, aclr, aload, ena, data, adata, q);
input clk, aclr, aload, ena, data, adata;
output q;
reg q;
always @ (posedge clk or posedge aclr or posedge aload)
begin
if (aclr)
q <= 1'b0;
else if (aload)
q <= adata;
else if (ena)
q <= data;
end
endmodule
Altera Corporation
October 2007
6–41
Preliminary
Quartus II Handbook, Volume 1
Example 6–31. VHDL D-Type Flipflop (Register) with ena, aclr and aload Control Signals
LIBRARY ieee;
USE ieee.std_logic_1164.all;
ENTITY dff_control IS
PORT (
clk: IN STD_LOGIC;
aclr: IN STD_LOGIC;
aload: IN STD_LOGIC;
adata: IN STD_LOGIC;
ena: IN STD_LOGIC;
data: IN STD_LOGIC;
q: OUT STD_LOGIC
);
END dff_control;
ARCHITECTURE rtl OF dff_control IS
BEGIN
PROCESS (clk, aclr, aload, adata)
BEGIN
IF (aclr = '1') THEN
q <= '0';
ELSIF (aload = '1') THEN
q <= adata;
ELSE
IF (clk = '1' AND clk'event) THEN
IF (ena ='1') THEN
q <= data;
END IF;
END IF;
END IF;
END PROCESS;
END rtl;
The preset signal is not available in many device families, so the preset
signal is not included in the examples.
Creating many registers with different sload and sclr signals can make
packing the registers into LABs difficult for the Quartus II Fitter because
the sclr and sload signals are LAB-wide signals. In addition, using the
LAB-wide sload signal prevents the Fitter from packing registers using
the quick feedback path in the device architecture, which means that
some registers cannot be packed with other logic.
Synthesis tools typically restrict use of sload and sclr signals to cases
in which there are enough registers with common signals to allow good
LAB packing. Using the LUT to implement the signals is always more
flexible if it is available. Because different device families offer different
numbers of control signals, inference of these signals is also devicespecific. For example, Stratix II devices have more flexibility than
Stratix devices with respect to secondary control signals, so synthesis
tools might infer more sload and sclr signals for Stratix II devices.
6–42
Preliminary
Altera Corporation
October 2007
Coding Guidelines for Registers and Latches
If you use these additional control signals, use them in the priority order
that matches the device architecture. To achieve the most efficient results,
ensure the sclr signal has a higher priority than the sload signal in the
same way that aclr has higher priority than aload in the previous
examples. Remember that the register signals are not inferred unless the
design meets the conditions described previously. However, if your HDL
described the desired behavior, the software always implements logic
with the correct functionality.
In Verilog HDL, the following code for sload and sclr could replace
the if (ena) q <= data; statements in the Verilog HDL example
shown in Example 6–30 on page 6–41 (after adding the control signals to
the module declaration).
Example 6–32. Verilog HDL sload and sclr Control Signals
if
(ena) begin
if (sclr)
q <= 1'b0;
else if (sload)
q <= sdata;
else
q <= data;
end
In VHDL, the following code for sload and sclr could replace the IF
(ena ='1') THEN q <= data; END IF; statements in the VHDL
example shown in Example 6–31 on page 6–42 (after adding the control
signals to the entity declaration).
Example 6–33. VHDL sload and sclr Control Signals
IF (ena ='1') THEN
IF (sclr = '1') THEN
q <= '0';
ELSIF (sload = '1') THEN
q <= sdata;
ELSE
q <= data;
END IF;
END IF;
Latches
A latch is a small combinational loop that holds the value of a signal until
a new value is assigned.
1
Altera Corporation
October 2007
Altera recommends that you design without the use of latches
whenever possible.
6–43
Preliminary
Quartus II Handbook, Volume 1
f
For additional information about the issues involved in designing with
latches and all combinational loops, refer to the Design Recommendations
for Altera Devices chapter in volume 1 of the Quartus II Handbook.
Latches can be inferred from HDL code when you did not intend to use a
latch as detailed in “Unintentional Latch Generation”. If you do intend to
infer a latch, it is important to infer it correctly to guarantee correct device
operation as detailed in “Inferring Latches Correctly” on page 6–45.
Unintentional Latch Generation
When you are designing combinational logic, certain coding styles can
create an unintentional latch. For example, when CASE or IF statements
do not cover all possible input conditions, latches may be required to hold
the output if a new output value is not assigned. Check your synthesis
tool messages for references to inferred latches. If your code
unintentionally creates a latch, make code changes to remove the latch.
1
Latches have limited support in formal verification tools.
Therefore, ensure that you do not infer latches unintentionally.
For example, an incomplete CASE statement may create a latch
when you are using formal verification in your design flow.
The full_case attribute can be used in Verilog HDL designs to treat
unspecified cases as don’t care values (X). However, using the
full_case attribute can cause simulation mismatches because this
attribute is a synthesis-only attribute, so simulation tools still treat the
unspecified cases as latches.
f
Refer to the appropriate chapter in the Synthesis section in volume 1 of
the Quartus II Handbook for more information about using attributes in
your synthesis tool. The Quartus II Integrated Synthesis chapter provides
an example explaining possible simulation mismatches.
Omitting the final ELSE or WHEN OTHERS clause in an IF or CASE
statement can also generate a latch. Don’t care (X) assignments on the
default conditions are useful in preventing latch generation. For the best
logic optimization, assign the default CASE or final ELSE value to don’t
care (X) instead of a logic value.
The VHDL sample code shown in Example 6–34 prevents unintentional
latches. Without the final ELSE clause, this code creates unintentional
latches to cover the remaining combinations of the sel inputs. When you
are targeting a Stratix device with this code, omitting the final ELSE
condition can cause the synthesis software to use up to six LEs, instead of
the three it uses with the ELSE statement. Additionally, assigning the
final ELSE clause to 1 instead of X can result in slightly more LEs because
the synthesis software cannot perform as much optimization when you
specify a constant value compared to a don’t care value.
6–44
Preliminary
Altera Corporation
October 2007
Coding Guidelines for Registers and Latches
Example 6–34. VHDL Code Preventing Unintentional Latch Creation
LIBRARY ieee;
USE IEEE.std_logic_1164.all;
ENTITY nolatch IS
PORT (a,b,c: IN STD_LOGIC;
sel: IN STD_LOGIC_VECTOR (4 DOWNTO 0);
oput: OUT STD_LOGIC);
END nolatch;
ARCHITECTURE rtl OF nolatch IS
BEGIN
PROCESS (a,b,c,sel) BEGIN
IF sel = "00000" THEN
oput <= a;
ELSIF sel = "00001" THEN
oput <= b;
ELSIF sel = "00010" THEN
oput <= c;
ELSE
--- Prevents latch inference
oput <= ''X'; --/
END IF;
END PROCESS;
END rtl;
Inferring Latches Correctly
Synthesis tools can infer a latch that does not exhibit the glitch and timing
hazard problems typically associated with combinational loops.
1
Any use of latches generates warnings and is flagged if the
design is migrated to a HardCopy structured ASIC. In addition,
timing analysis does not completely model latch timing in some
cases. Do not use latches unless you are very certain that your
design requires it, and you fully understand the impact of using
the latches.
When using Quartus II integrated synthesis, latches that are inferred by
the software are reported in the User-Specified and Inferred Latches
section of the Compilation Report. This report indicates whether the latch
is considered safe and free of timing hazards.
If a latch or combinational loop in your design is not listed in the
User-Specified and Inferred Latches report, it means that it was not
inferred as a safe latch by the software and is not considered glitch-free.
All combinational loops listed in the Analysis & Synthesis Logic Cells
Representing Combinational Loops table in the Compilation Report are
at risk of timing hazards. These entries indicate possible problems with
your design that you should investigate. However, it is possible to have
Altera Corporation
October 2007
6–45
Preliminary
Quartus II Handbook, Volume 1
a correct design that includes combinational loops. For example, it is
possible that the combinational loop cannot be sensitized. This can occur
in cases where there is an electrical path in the hardware, but either the
designer knows that the circuit will never encounter data that causes that
path to be activated, or the surrounding logic is set up in a mutually
exclusive manner that prevents that path from ever being sensitized,
independent of the data input.
For macrocell-based devices such as MAX® 7000AE and MAX 3000A, all
data (D-type) latches and set-reset (S-R) latches listed in the Analysis &
Synthesis User-Specified and Inferred Latches table have an
implementation free of timing hazards such as glitches. The
implementation includes a cover term to ensure there is no glitching, and
includes a single macrocell in the feedback loop.
For 4-input LUT-based devices such as Stratix devices, the Cyclone series,
and MAX II devices, all latches in the User-Specified and Inferred
Latches table with a single LUT in the feedback loop are free of timing
hazards when a single input changes. Because of the hardware behavior
of the LUT, the output does not glitch when a single input toggles
between two values that are supposed to produce the same output value.
For example, a D-type input toggling when the enable input is inactive,
or a set input toggling when a reset input with higher priority is active.
This hardware behavior of the LUT means that no cover term is needed
for a loop around a single LUT. The Quartus II software uses a single LUT
in the feedback loop whenever possible. A latch that has data, enable, set,
and reset inputs in addition to the output fed back to the input cannot be
implemented in a single 4-input LUT. If the Quartus II software cannot
implement the latch with a single-LUT loop because there are too many
inputs, then the User-Specified and Inferred Latches table indicates that
the latch is not free of timing hazards.
For 6-input LUT-based devices, the software can implement all latch
inputs with a single adaptive look-up table (ALUT) in the combinational
loop. Therefore, all latches in the User-Specified and Inferred Latches
table are free of timing hazards when a single input changes.
If a latch is listed as a safe latch, other Quartus II optimizations, such as
physical synthesis netlist optimizations in the Fitter, maintain the
hazard-free performance.
To ensure hazard-free behavior, only one control input may change at a
time. Changing two inputs simultaneously, such as deasserting set and
reset at the same time, or changing data and enable at the same time, can
produce incorrect behavior in any latch.
6–46
Preliminary
Altera Corporation
October 2007
Coding Guidelines for Registers and Latches
Quartus II integrated synthesis infers latches from always blocks in
Verilog HDL and process statements in VHDL, but not from
continuous assignments in Verilog HDL or concurrent signal
assignments in VHDL. These rules are the same as for register inference.
The software infers registers or flipflops only from always blocks and
process statements.
The Verilog HDL code sample shown in Example 6–35 infers a S-R latch
correctly in the Quartus II software.
Example 6–35. Verilog HDL Set-Reset Latch
module simple_latch (
input SetTerm,
input ResetTerm,
output reg LatchOut
);
always @ (SetTerm or ResetTerm) begin
if (SetTerm)
LatchOut = 1'b1
else if (ResetTerm)
LatchOut = 1'b0
end
endmodule
The VHDL code sample shown in Example 6–36 infers a D-type latch
correctly in the Quartus II software.
Example 6–36. VHDL Data Type Latch
LIBRARY IEEE;
USE IEEE.std_logic_1164.all;
ENTITY simple_latch IS
PORT (
enable, data
: IN STD_LOGIC;
q
: OUT STD_LOGIC
);
END simple_latch;
ARCHITECTURE rtl OF simple_latch IS
BEGIN
latch : PROCESS (enable, data)
BEGIN
IF (enable = '1') THEN
q <= data;
END IF;
END PROCESS latch;
END rtl;
Altera Corporation
October 2007
6–47
Preliminary
Quartus II Handbook, Volume 1
The following example shows a Verilog HDL continuous assignment that
does not infer a latch in the Quartus II software. The behavior is similar
to a latch, but it may not function correctly as a latch and its timing is not
analyzed as a latch.
assign latch_out = (~en & latch_out) | (en & data);
Quartus II integrated synthesis also creates safe latches when possible for
instantiations of the lpm_latch megafunction. You can use this
megafunction to create a latch with any combination of data, enable, set,
and reset inputs. The same limitations apply for creating safe latches as
for inferring latches from HDL code.
Inferring the Altera lpm_latch function in another synthesis tool
ensures that the implementation is also recognized as a latch in the
Quartus II software. If a third-party synthesis tool implements a latch
using the lpm_latch megafunction, then the Quartus II integrated
synthesis lists the latch in the User-Specified and Inferred Latches table
in the same way as it lists latches created in HDL source code. The coding
style necessary to produce an lpm_latch implementation may depend
on your synthesis tool. Some third-party synthesis tools list the number
of lpm_latch functions that are inferred.
For LUT-based families, the Fitter uses global routing for control signals
including signals that Analysis and Synthesis identifies as latch enables.
In some cases the global insertion delay may decrease the timing
performance. If necessary, you can turn off the Quartus II Global Signal
logic option to manually prevent the use of global signals. Global latch
enables are listed in the Global & Other Fast Signals table in the
Compilation Report.
General Coding
Guidelines
This section helps you understand how synthesis tools map various types
of HDL code into the target Altera device. Following Altera
recommended coding styles, and in some cases designing logic structures
to match the appropriate device architecture, can provide significant
improvements in the design’s quality of results.
This section provides coding guidelines for the following logic structures:
■
■
■
6–48
Preliminary
“Tri-State Signals”. This section explains how to create tri-state
signals for bidirectional I/O pins.
“Adder Trees” on page 6–50. This section explains the different
coding styles that lead to optimal results for devices with 4-input
look-up tables and 6-input adaptive look-up tables.
“State Machines” on page 6–52. This section helps ensure the best
results when you use state machines.
Altera Corporation
October 2007
General Coding Guidelines
■
■
■
■
“Multiplexers” on page 6–60. This section explains how multiplexers
can be synthesized for 4-input LUT devices, addresses common
problems, and provides guidelines to achieve optimal resource
utilization.
“Cyclic Redundancy Check Functions” on page 6–69. This section
provides guidelines for getting good results when designing CRC
functions.
“Comparators” on page 6–71. This section explains different
comparator implementations and provides suggestions for
controlling the implementation.
“Counters” on page 6–73. This section provides guidelines to ensure
your counter design targets the device architecture optimally.
Tri-State Signals
When you are targeting Altera devices, you should use tri-state signals
only when they are attached to top-level bidirectional or output pins.
Avoid lower level bidirectional pins, and avoid using the Z logic value
unless it is driving an output or bidirectional pin.
Synthesis tools implement designs with internal tri-state signals correctly
in Altera devices using multiplexer logic, but Altera does not recommend
this coding practice.
1
In hierarchical block-based or incremental design flows, a
hierarchical boundary cannot contain any bidirectional ports,
unless the lower level bidirectional port is connected directly
through the hierarchy to a top-level output pin without
connecting to any other design logic. If you use boundary
tri-states in a lower level block, synthesis software must push
the tri-states through the hierarchy to the top-level to make use
of the tri-state drivers on output pins of Altera devices. Because
pushing tri-states requires optimizing through hierarchies,
lower level tri-states are restricted with block-based design
methodologies.
The code examples shown in Examples 6–37 and 6–38 show Verilog HDL
and VHDL code that creates tri-state bidirectional signals.
Example 6–37. Verilog HDL Tri-State Signal
module tristate (myinput, myenable, mybidir);
input myinput, myenable;
inout mybidir;
assign mybidir = (myenable ? myinput : 1'bZ);
endmodule
Altera Corporation
October 2007
6–49
Preliminary
Quartus II Handbook, Volume 1
Example 6–38. VHDL Tri-State Signal
LIBRARY ieee;
USE ieee.std_logic_1164.ALL;
USE ieee.std_logic_arith.ALL;
ENTITY tristate IS
PORT (
mybidir : INOUT STD_LOGIC;
myinput : IN STD_LOGIC;
myenable : IN STD_LOGIC
);
END tristate;
ARCHITECTURE rtl OF tristate IS
BEGIN
mybidir <= 'Z' WHEN (myenable = '0') ELSE myinput;
END rtl;
Adder Trees
Structuring adder trees appropriately to match your targeted Altera
device architecture can result in significant performance and density
improvements. A good example of an application using a large adder tree
is a finite impulse response (FIR) correlator. Using a pipelined binary or
ternary adder tree appropriately can greatly improve the quality of your
results.
This section explains why coding recommendations are different for
Altera 4-input LUT devices and 6-input LUT devices.
Architectures with 4-Input LUTs in Logic Elements
Architectures such as Stratix devices and the Cyclone series, APEX series,
and FLEX series devices contain 4-input LUTs as the standard
combinational structure in the LE.
If your design can tolerate pipelining, the fastest way to add three
numbers A, B, and C in devices that use 4-input lookup tables is to add
A + B, register the output, and then add the registered output to C.
Adding A + B takes one level of logic (one bit is added in one LE), so this
runs at full clock speed. This can be extended to as many numbers as
desired.
6–50
Preliminary
Altera Corporation
October 2007
General Coding Guidelines
In the code sample shown in Example 6–39, five numbers A, B, C, D, and E
are added. Adding five numbers in devices that use 4-input lookup tables
requires four adders and three levels of registers for a total of 64 LEs
(for 16-bit numbers).
Example 6–39. Verilog HDL Pipelined Binary Tree
module binary_adder_tree (A, B, C, D, E, CLK, OUT);
parameter WIDTH = 16;
input [WIDTH-1:0] A, B, C, D, E;
input CLK;
output [WIDTH-1:0] OUT;
wire [WIDTH-1:0] sum1, sum2, sum3, sum4;
reg [WIDTH-1:0] sumreg1, sumreg2, sumreg3, sumreg4;
// Registers
always @ (posedge CLK)
begin
sumreg1 <= sum1;
sumreg2 <= sum2;
sumreg3 <= sum3;
sumreg4 <= sum4;
end
// 2-bit additions
assign sum1 = A + B;
assign sum2 = C + D;
assign sum3 = sumreg1 + sumreg2;
assign sum4 = sumreg3 + E;
assign OUT = sumreg4;
endmodule
Architectures with 6-Input LUTs in Adaptive Logic Modules
Newer high-performance Altera device families use a 6-input LUT in
their basic logic structure, so these devices benefit from a different coding
style from the previous example presented for 4-input LUTs. Specifically,
in these devices, ALMs can simultaneously add three bits. Therefore, the
tree in the previous example must be two levels deep and contain just two
add-by-three inputs instead of four add-by-two inputs.
Although the code in the previous example compiles successfully for
6-input LUT devices, the code is inefficient and does not take advantage
of the 6-input adaptive look-up table (ALUT). By restructuring the tree as
a ternary tree, the design becomes much more efficient, significantly
improving density utilization. Therefore, when you are targeting with
ALUTs and ALMs, large pipelined binary adder trees designed for
4-input LUT architectures should be rewritten to take advantage of the
advanced device architecture.
Altera Corporation
October 2007
6–51
Preliminary
Quartus II Handbook, Volume 1
Example 6–40 uses just 32 ALUTs in a Stratix II device—more than a 4:1
advantage over the number of LUTs in the prior example implemented in
a Stratix device.
1
You cannot pack a LAB full when using this type of coding style
because of the number of LAB inputs. However, in a typical
design, the Quartus II Fitter can pack other logic into each LAB
to take advantage of the unused ALMs.
Example 6–40. Verilog HDL Pipelined Ternary Tree
module ternary_adder_tree (A, B, C, D, E, CLK, OUT);
parameter WIDTH = 16;
input [WIDTH-1:0] A, B, C, D, E;
input CLK;
output [WIDTH-1:0] OUT;
wire [WIDTH-1:0] sum1, sum2;
reg [WIDTH-1:0] sumreg1, sumreg2;
// Registers
always @ (posedge CLK)
begin
sumreg1 <= sum1;
sumreg2 <= sum2;
end
// 3-bit additions
assign sum1 = A + B + C;
assign sum2 = sumreg1 + D + E;
assign OUT = sumreg2;
endmodule
These examples show pipelined adders, but partitioning your addition
operations can help you achieve better results in nonpipelined adders as
well. If your design is not pipelined, a ternary tree provides much better
performance than a binary tree. For example, depending on your
synthesis tool, the HDL code sum = (A + B + C) + (D + E) is
more likely to create the optimal implementation of a 3-input adder for
A + B + C followed by a 3-input adder for sum1 + D + E than the
code without the parentheses. If you do not add the parentheses, the
synthesis tool may partition the addition in a way that is not optimal for
the architecture.
State Machines
Synthesis tools can recognize and encode Verilog HDL and VHDL state
machines during synthesis. This section presents guidelines to ensure the
best results when you use state machines. Ensuring that your synthesis
tool recognizes a piece of code as a state machine allows the tool to recode
the state variables to improve the quality of results, and allows the tool to
6–52
Preliminary
Altera Corporation
October 2007
General Coding Guidelines
use the known properties of state machines to optimize other parts of the
design. When synthesis recognizes a state machine it is often able to
improve the design area and performance.
To achieve the best results on average, synthesis tools often use one-hot
encoding for FPGA devices and minimal-bit encoding for CPLD devices,
although the choice of implementation can vary for different state
machines and different devices. Refer to your synthesis tool
documentation for specific ways to control the manner in which state
machines are encoded.
f
For information about state machine encoding in Quartus II integrated
synthesis, refer to the State Machine Processing section in the Quartus II
Integrated Synthesis chapter in volume 1 of the Quartus II Handbook.
To ensure proper recognition and inference of state machines and to
improve the quality of results, Altera recommends that you observe the
following guidelines, which apply to both Verilog HDL and VHDL:
■
■
■
■
Assign default values to outputs derived from the state machine so
that synthesis does not generate unwanted latches.
Separate the state machine logic from all arithmetic functions and
data paths, including assigning output values.
If your design contains an operation that is used by more than one
state, define the operation outside the state machine and cause the
output logic of the state machine to use this value.
Use a simple asynchronous or synchronous reset to ensure a defined
power-up state. If your state machine design contains more elaborate
reset logic, such as both an asynchronous reset and an asynchronous
load, the Quartus II software generates regular logic rather than
inferring a state machine.
If a state machine enters an illegal state due to a problem with the device,
the design likely ceases to function correctly until the next reset of the
state machine. Synthesis tools do not provide for this situation by default.
The same issue applies to any other registers if there is some kind of fault
in the system. A default or when others clause does not affect this
operation, assuming that your design never deliberately enters this state.
Synthesis tools remove any logic generated by a default state if it is not
reachable by normal state machine operation.
Many synthesis tools (including Quartus II integrated synthesis) have an
option to implement a safe state machine. The software inserts extra logic
to detect an illegal state and force the state machine’s transition to the
reset state. It is commonly used when the state machine can enter an
Altera Corporation
October 2007
6–53
Preliminary
Quartus II Handbook, Volume 1
illegal state. The most common cause of this situation is a state machine
that has control inputs that come from another clock domain, such as the
control logic for a dual-clock FIFO.
Of course this option protects only state machines, and all other registers
in the design are not protected this way.
f
For additional information about tool-specific options for implementing
state machines, refer to the tool vendor’s documentation or the
appropriate chapter in the Synthesis section in volume 1 of the Quartus II
Handbook.
The following two sections, “Verilog HDL State Machines” and “VHDL
State Machines” on page 6–58, describe additional language-specific
guidelines and coding examples.
Verilog HDL State Machines
To ensure proper recognition and inference of Verilog HDL state
machines, observe the following additional Verilog HDL guidelines.
Some of these guidelines may be specific to Quartus II integrated
synthesis. Refer to your synthesis tool documentation for specific coding
recommendations.
If the state machine is not recognized by the synthesis software (such as
Quartus II integrated synthesis), the state machine is implemented as
regular logic gates and registers and the state machine is not listed as a
state machine in the Analysis & Synthesis section of the Quartus II
Compilation Report. In this case, the software does not perform any of the
optimizations that are specific to state machines.
■
■
If you are using the SystemVerilog standard, use enumerated types
to describe state machines (as shown in the “SystemVerilog State
Machine Coding Example” on page 6–57).
Represent the states in a state machine with the parameter data
types in Verilog-1995 and -2001 and use the parameters to make state
assignments (as shown below in the “Verilog HDL State Machine
Coding Example”). This implementation makes the state machine
easier to read and reduces the risk of errors during coding.
1
6–54
Preliminary
Altera recommends against the direct use of integer values
for state variables such as next_state <= 0. However,
using an integer does not prevent inference in the
Quartus II software.
Altera Corporation
October 2007
General Coding Guidelines
■
No state machine is inferred in the Quartus II software if the state
transition logic uses arithmetic similar to that shown in the following
example:
case (state)
0: begin
if (ena) next_state <= state + 2;
else next_state <= state + 1;
end
1: begin
...
endcase
■
No state machine is inferred in the Quartus II software if the state
variable is an output.
No state machine is inferred in the Quartus II software for signed
variables
■
Verilog HDL State Machine Coding Example
The following module verilog_fsm is an example of a typical Verilog
HDL state machine implementation (Example 6–41).
This state machine has five states. The asynchronous reset sets the
variable state to state_0. The sum of in_1 and in_2 is an output of the
state machine in state_1 and state_2. The difference (in_1 – in_2)
is also used in state_1 and state_2. The temporary variables
tmp_out_0 and tmp_out_1 store the sum and the difference of in_1
and in_2. Using these temporary variables in the various states of the
state machine ensures proper resource sharing between the mutually
exclusive states.
Example 6–41. Verilog-2001 State Machine
module verilog_fsm (clk, reset, in_1, in_2, out);
input clk;
input reset;
input [3:0] in_1;
input [3:0] in_2;output [4:0] out;
parameter state_0 = 3'b000;
parameter state_1 = 3'b001;
parameter state_2 = 3'b010;
parameter state_3 = 3'b011;
parameter state_4 = 3'b100;
reg [4:0] tmp_out_0, tmp_out_1, tmp_out_2;
reg [2:0] state, next_state;
always @ (posedge clk or posedge reset)
begin
if (reset)
state <= state_0;
else
Altera Corporation
October 2007
6–55
Preliminary
Quartus II Handbook, Volume 1
state <= next_state;
end
always @ (state or in_1 or in_2)
begin
tmp_out_0 = in_1 + in_2;
tmp_out_1 = in_1 - in_2;
case (state)
state_0: begin
tmp_out_2 <= in_1 + 5'b00001;
next_state <= state_1;
end
state_1: begin
if (in_1 < in_2) begin
next_state <= state_2;
tmp_out_2 <= tmp_out_0;
end
else begin
next_state <= state_3;
tmp_out_2 <= tmp_out_1;
end
end
state_2: begin
tmp_out_2 <= tmp_out_0 - 5'b00001;
next_state <= state_3;
end
state_3: begin
tmp_out_2 <= tmp_out_1 + 5'b00001;
next_state <= state_0;
end
state_4:begin
tmp_out_2 <= in_2 + 5'b00001;
next_state <= state_0;
end
default:begin
tmp_out_2 <= 5'b00000;
next_state <= state_0;
end
endcase
end
assign out = tmp_out_2;
endmodule
An equivalent implementation of this state machine can be achieved by
using ‘define instead of the parameter data type, as follows:
‘define
‘define
‘define
‘define
‘define
state_0
state_1
state_2
state_3
state_4
3'b000
3'b001
3'b010
3'b011
3'b100
In this case, the state and next_state assignments are assigned a
‘state_x instead of a state_x, as shown in the following example:
next_state <= ‘state_3;
6–56
Preliminary
Altera Corporation
October 2007
General Coding Guidelines
1
Although the ‘define construct is supported, Altera strongly
recommends the use of the parameter data type because doing
so preserves the state names throughout synthesis.
SystemVerilog State Machine Coding Example
The module enum_fsm shown in Example 6–42 is an example of a
SystemVerilog state machine implementation that uses enumerated
types. Altera recommends using this coding style to describe state
machines in SystemVerilog.
1
In Quartus II integrated synthesis, the enumerated type that
defines the states for the state machine must be of an unsigned
integer type as shown in Example 6–42. If you do not specify the
enumerated type as int unsigned, a signed int type is used
by default. In this case, the Quartus II integrated synthesis
synthesizes the design, but does not infer or optimize the logic
as a state machine.
Example 6–42. SystemVerilog State Machine Using Enumerated Types
module enum_fsm (input clk, reset, input int data[3:0], output int o);
enum int unsigned { S0 = 0, S1 = 2, S2 = 4, S3 = 8 } state, next_state;
always_comb begin :
next_state = S0;
case(state)
S0: next_state
S1: next_state
S2: next_state
S3: next_state
endcase
end
next_state_logic
=
=
=
=
S1;
S2;
S3;
S3;
always_comb begin
case(state)
S0: o = data[3];
S1: o = data[2];
S2: o = data[1];
S3: o = data[0];
endcase
end
[email protected](posedge clk or negedge reset) begin
if(~reset)
state <= S0;
else
state <= next_state;
end
endmodule
Altera Corporation
October 2007
6–57
Preliminary
Quartus II Handbook, Volume 1
VHDL State Machines
To ensure proper recognition and inference of VHDL state machines,
represent the states in a state machine with enumerated types and use the
corresponding types to make state assignments. This implementation
makes the state machine easier to read and reduces the risk of errors
during coding. If the state is not represented by an enumerated type,
synthesis software (such as Quartus II integrated synthesis) does not
recognize the state machine. Instead, the state machine is implemented as
regular logic gates and registers and the state machine is not listed as a
state machine in the Analysis & Synthesis section of the Quartus II
Compilation Report. In this case, the software does not perform any of the
optimizations that are specific to state machines.
VHDL State Machine Coding Example
The following entity, vhd1_fsm, is an example of a typical VHDL state
machine implementation (Example 6–43).
This state machine has five states. The asynchronous reset sets the
variable state to state_0. The sum of in1 and in2 is an output of the
state machine in state_1 and state_2. The difference (in1 - in2) is
also used in state_1 and state_2. The temporary variables
tmp_out_0 and tmp_out_1 store the sum and the difference of in1 and
in2. Using these temporary variables in the various states of the state
machine ensures proper resource sharing between the mutually exclusive
states.
Example 6–43. VHDL State Machine
LIBRARY ieee;
USE ieee.std_logic_1164.all;
USE ieee.numeric_std.all;
ENTITY vhdl_fsm IS
PORT(
clk: IN STD_LOGIC;
reset: IN STD_LOGIC;
in1: IN UNSIGNED(4 downto 0);
in2: IN UNSIGNED(4 downto 0);
out_1: OUT UNSIGNED(4 downto 0)
);
END vhdl_fsm;
ARCHITECTURE rtl OF vhdl_fsm IS
TYPE Tstate IS (state_0, state_1, state_2, state_3, state_4);
SIGNAL state: Tstate;
SIGNAL next_state: Tstate;
BEGIN
PROCESS(clk, reset)
BEGIN
IF reset = '1' THEN
state <=state_0;
6–58
Preliminary
Altera Corporation
October 2007
General Coding Guidelines
ELSIF rising_edge(clk) THEN
state <= next_state;
END IF;
END PROCESS;
PROCESS (state, in1, in2)
VARIABLE tmp_out_0: UNSIGNED (4 downto 0);
VARIABLE tmp_out_1: UNSIGNED (4 downto 0);
BEGIN
tmp_out_0 := in1 + in2;
tmp_out_1 := in1 - in2;
CASE state IS
WHEN state_0 =>
out_1 <= in1;
next_state <= state_1;
WHEN state_1 =>
IF (in1 < in2) then
next_state <= state_2;
out_1 <= tmp_out_0;
ELSE
next_state <= state_3;
out_1 <= tmp_out_1;
END IF;
WHEN state_2 =>
IF (in1 < "0100") then
out_1 <= tmp_out_0;
ELSE
out_1 <= tmp_out_1;
END IF;
next_state <= state_3;
WHEN state_3 =>
out_1 <= "11111";
next_state <= state_4;
WHEN state_4 =>
out_1 <= in2;
next_state <= state_0;
WHEN OTHERS =>
out_1 <= "00000";
next_state <= state_0;
END CASE;
END PROCESS;
END rtl;
Altera Corporation
October 2007
6–59
Preliminary
Quartus II Handbook, Volume 1
Multiplexers
Multiplexers form a large portion of the logic utilization in many FPGA
designs. By optimizing your multiplexer logic, you ensure the most
efficient implementation in your Altera device. This section addresses
common problems and provides design guidelines to achieve optimal
resource utilization for multiplexer designs. The section also describes
various types of multiplexers, and how they are implemented in the
4-input LUT found in many FPGA architectures, such as Altera’s Stratix
devices.
1
Stratix II and newer high-performance devices have 6-input
ALUTs and are not specifically addressed here. Although many
of the principles and techniques for optimization are similar,
device utilization differs in the 6-input LUT devices. For
example, these devices can implement wider multiplexers in
one ALM than can be implemented in the 4-input LUT of an LE.
Quartus II Software Option for Multiplexer Restructuring
Quartus II integrated synthesis provides the Restructure Multiplexers
logic option that extracts and optimizes buses of multiplexers during
synthesis. In certain situations, this option automatically performs some
of the recoding functions described in this section without changing the
HDL code in your design. This option is on by default, when the
Optimization technique is set to Balanced (the default for most device
families) or set to Area.
f
For details, refer to the Restructure Multiplexers subsection in the
Quartus II Integrated Synthesis chapter in volume 1 of the Quartus II
Handbook.
Even with this Quartus II-specific option turned on, it is beneficial to
understand how your coding style can be interpreted by your synthesis
tool, and avoid the situations that can cause problems in your design.
Multiplexer Types
This first subsection addresses how multiplexers are created from various
types of HDL code. CASE statements, IF statements, and state machines
are all common sources of multiplexer logic in designs. These HDL
structures create different types of multiplexers including binary
multiplexers, selector multiplexers, and priority multiplexers.
Understanding how multiplexers are created from HDL code and how
they might be implemented during synthesis is the first step towards
optimizing multiplexer structures for best results.
6–60
Preliminary
Altera Corporation
October 2007
General Coding Guidelines
Binary Multiplexers
Binary multiplexers select inputs based on binary-encoded selection bits.
Example 6–44 shows Verilog HDL code for two ways to describe a simple
4:1 binary multiplexer.
Example 6–44. Verilog HDL Binary-Encoded Multiplexers
case (sel)
2'b00: z
2'b01: z
2'b10: z
2'b11: z
endcase
=
=
=
=
a;
b;
c;
d;
A 4:1 binary multiplexer is efficiently implemented by using two 4-input
LUTs. Larger binary multiplexers can be constructed that use the 4:1
multiplexer; constructing an N-input multiplexer (N:1 multiplexer) from
a tree of 4:1 multiplexers can result in a structure using as few as
0.66*(N - 1) LUTs.
Selector Multiplexers
Selector multiplexers have a separate select line for each data input. The
select lines for the multiplexer are one-hot encoded. Example 6–45 shows
a simple Verilog HDL code example describing a one-hot selector
multiplexer.
Example 6–45. Verilog HDL One-Hot-Encoded Case Statement
case (sel)
4'b0001:
4'b0010:
4'b0100:
4'b1000:
default:
endcase
z
z
z
z
z
=
=
=
=
=
a;
b;
c;
d;
1'bx;
Selector multiplexers are commonly built as a tree of AND and OR gates.
Using this scheme, two inputs can be selected using two select lines in a
single 4-input LUT that uses two AND gates and an OR gate. The outputs
of these LUTs can be combined with a wide OR gate. An N-input selector
multiplexer of this structure requires at least 0.66*(N-0.5) LUTs, which is
just slightly worse than the best binary multiplexer.
Priority Multiplexers
In priority multiplexers, the select logic implies a priority. The options to
select the correct item must be checked in a specific order based on signal
priority. These structures commonly are created from IF, ELSE, WHEN,
Altera Corporation
October 2007
6–61
Preliminary
Quartus II Handbook, Volume 1
SELECT, and ?: statements in VHDL or Verilog HDL. The example
VHDL code in Example 6–46 will probably result in the schematic
implementation illustrated in Figure 6–2.
Example 6–46. VHDL IF Statement Implying Priority
IF cond1 THEN z <= a;
ELSIF cond2 THEN z <= b;
ELSIF cond3 THEN z <= c;
ELSE z <= d;
END IF;
The multiplexers shown in Figure 6–2 form a chain, evaluating each
condition or select bit, one at a time.
Figure 6–2. Priority Multiplexer Implementation of an IF Statement
c
cond3
1
d
0
b
cond2
1
0
a
cond1
1
0
z
An N-input priority multiplexer uses a LUT for every 2:1 multiplexer in
the chain, requiring N-1 LUTs. This chain of multiplexers generally
increases delay because the critical path through the logic traverses every
multiplexer in the chain.
To improve the timing delay through the multiplexer, avoid priority
multiplexers if priority is not required. If the order of the choices is not
important to the design, use a CASE statement to implement a binary or
selector multiplexer instead of a priority multiplexer. If delay through the
structure is important in a multiplexed design requiring priority,
consider recoding the design to reduce the number of logic levels to
minimize delay, especially along your critical paths.
6–62
Preliminary
Altera Corporation
October 2007
General Coding Guidelines
Default or Others Case Assignment
To fully specify the cases in a CASE statement, include a DEFAULT
(Verilog HDL) or OTHERS (VHDL) assignment. This assignment is
especially important in one-hot encoding schemes where many
combinations of the select lines are unused. Specifying a case for the
unused select line combinations gives the synthesis tool information
about how to synthesize these cases, and is required by the Verilog HDL
and VHDL language specifications.
Some designs do not require that the outcome in the unused cases be
considered, often because designers assume these cases will not occur.
For these types of designs, you can choose any value for the DEFAULT or
OTHERS assignment. However, be aware that the assignment value you
choose can have a large effect on the logic utilization required to
implement the design due to the different ways synthesis tools treat
different values for the assignment, and how the synthesis tools use
different speed and area optimizations.
In general, to obtain best results, explicitly define invalid CASE selections
with a separate DEFAULT or OTHERS statement instead of combining the
invalid cases with one of the defined cases.
If the value in the invalid cases is not important, specify those cases
explicitly by assigning the X (don’t care) logic value instead of choosing
another value. This assignment allows your synthesis tool to perform the
best area optimizations.
You can experiment with different DEFAULT or OTHERS assignments for
your HDL design and your synthesis tool to test the effect they have on
logic utilization in your design.
Implicit Defaults
The IF statements in Verilog HDL and VHDL can be a convenient way to
specify conditions that do not easily lend themselves to a CASE-type
approach. However, using IF statements can result in complicated
multiplexer trees that are not easy for synthesis tools to optimize.
In particular, every IF statement has an implicit ELSE condition, even
when it is not specified. These implicit defaults can cause additional
complexity in a multiplexed design.
Altera Corporation
October 2007
6–63
Preliminary
Quartus II Handbook, Volume 1
The code in Example 6–47 represents a multiplexer with four inputs (a, b,
c, d) and one output (z).
Example 6–47. VHDL IF Statement with Implicit Defaults
IF cond1 THEN
IF cond2 THEN
z <= a;
END IF;
ELSIF cond3 THEN
IF cond4 THEN
z <= b;
ELSIF cond5 THEN
z <= c;
END IF;
ELSIF cond6 THEN
z <= d;
END IF;
This is not a recommended coding style. Although the code appears to
implement a 4:1 multiplexer, each of the three separate IF statements in
the code has an implicit ELSE condition that is not specified. Because the
output values for the ELSE cases are not specified, the synthesis tool
assumes the intent is to maintain the same output value for these cases
and infers a combinational loop, such as a latch. Latches add to the
design’s logic utilization and can also make timing analysis difficult and
lead to other problems.
The code sample shown in Example 6–48 shows code with the same
functionality as the code shown in Example 6–47, but specifies the ELSE
cases explicitly. (This is not a recommended coding style improvement,
but it explicitly shows the default conditions from the previous example.)
Example 6–48. VHDL IF Statement with Default Conditions Explicitly Specified
IF cond1 THEN
IF cond2 THEN
z <= a;
ELSE
z <= z;
END IF;
ELSIF cond3 THEN
IF cond4 THEN
z <= b;
ELSIF cond5 THEN
z <= c;
ELSE
z <= z;
END IF;
ELSIF cond6 THEN
z <= d;
ELSE
z <= z;
END IF;
6–64
Preliminary
Altera Corporation
October 2007
General Coding Guidelines
Figure 6–3 is a schematic representing the code in Example 6–48, which
illustrates that the multiplexer logic is significantly more complicated
than a basic 4:1 multiplexer, although there are only four inputs.
Figure 6–3. Multiplexer Implementation of an IF Statement with Implicit
Defaults
z
c
0
cond5
1
d
b
cond6
0
cond4
z
cond2
0
1
a
cond3
0
1
z
1
0
1
cond1
1
0
z
There are several ways you can simplify the multiplexed logic and
remove the unneeded defaults. The optimal method may be to recode the
design so the logic takes the structure of a 4:1 CASE statement.
Alternatively, if priority is important, you can restructure the code to
deduce default cases and flatten the multiplexer. In this example, instead
of IF cond1 THEN IF cond2, use IF (cond1 AND cond2), which
performs the same function. In addition, examine whether the defaults
are don’t care cases. In this example, you can promote the last ELSIF
cond6 statement to an ELSE statement if no other valid cases can occur.
Avoid unnecessary default conditions in your multiplexer logic to reduce
the complexity and logic utilization required to implement your design.
Degenerate Multiplexers
A degenerate multiplexer is a multiplexer in which not all of the possible
cases are used for unique data inputs. The unneeded cases tend to
contribute to inefficiency in the logic utilization for these multiplexers.
You can recode degenerate multiplexers so they take advantage of the
efficient logic utilization possible with full binary multiplexers.
Altera Corporation
October 2007
6–65
Preliminary
Quartus II Handbook, Volume 1
Example 6–49 shows a VHDL CASE statement describing a degenerate
multiplexer.
Example 6–49. VHDL CASE Statement Describing a Degenerate Multiplexer
CASE sel[3:0] IS
WHEN "0101" =>
WHEN "0111" =>
WHEN "1010" =>
WHEN OTHERS =>
END CASE;
z
z
z
z
<=
<=
<=
<=
a;
b;
c;
d;
The number of select lines in a binary multiplexer normally dictates the
size of a multiplexer needed to implement the desired function. For
example, the multiplexer structure represented in Figure 6–4 has four
select lines capable of implementing a binary multiplexer with 16 inputs.
However, the design does not use all 16 inputs, which makes this
multiplexer a degenerate 16:1 multiplexer.
Figure 6–4. Binary Degenerate Multiplexer
a
b
c
d
sel[1:0]
"01xx"
"10xx"
"00xx"
"11xx"
sel[3:2]
Binary mux
z
In the example in Figure 6–4, the first and fourth multiplexers in the top
level can easily be eliminated because all four inputs to each multiplexer
are the same value, and the number of inputs to the other multiplexers
can be reduced, as shown in Figure 6–5.
6–66
Preliminary
Altera Corporation
October 2007
General Coding Guidelines
Figure 6–5. Optimized Version of the Degenerate Binary Multiplexer
a
b
c
3:1
sel[1:0]
2:1
"01xx"
"10xx"
"11xx"
"00xx"
sel[3:2]
d
3:1
z
Implementing this version of the multiplexer still requires at least five
4-input LUTs, two for each of the remaining 3:1 multiplexers and one for
the 2:1 multiplexer. This design selects an output from only four inputs,
a 4:1 binary multiplexer can be implemented optimally in two LUTs, so
this degenerate multiplexer tree reduces the efficiency of the logic.
You can improve logic utilization of this structure by recoding the select
lines to implement a full 4:1 binary multiplexer. The code sample shown
in Example 6–50 shows a recoder design that translates the original select
lines into the z_sel signal with binary encoding.
Example 6–50. VHDL Recoder Design for Degenerate Binary Multiplexer
CASE sel[3:0] IS
WHEN "0101" =>
WHEN "0111" =>
WHEN "1010" =>
WHEN OTHERS =>
END CASE;
z_sel
z_sel
z_sel
z_sel
<=
<=
<=
<=
"00";
"01";
"10";
"11";
The code sample shown in Example 6–51 shows you how to implement
the full binary multiplexer.
Example 6–51. VHDL 4:1 Binary Multiplexer Design
CASE z_sel[1:0]
WHEN "00" =>
WHEN "01" =>
WHEN "10" =>
WHEN "11" =>
END CASE;
Altera Corporation
October 2007
IS
z <=
z <=
z <=
z <=
a;
b;
c;
d;
6–67
Preliminary
Quartus II Handbook, Volume 1
Use the new z_sel control signal from the recoder design to control the
4:1 binary multiplexer that chooses between the four inputs a, b, c, and d,
as illustrated in Figure 6–6. The complexity of the select lines is handled
in the recoder design, and the data multiplexing is performed with simple
binary select lines enabling the most efficient implementation.
Figure 6–6. Binary Multiplexer with Recorder
sel[3:0]
a
b
c
d
Recoder
4:1
z_sel[1:0]
z
The design for the recoder can be implemented in two LUTs and the
efficient 4:1 binary multiplexer uses two LUTs, for a total of four LUTs.
The original degenerate multiplexer required five LUTs, so the recoded
version uses 20% less logic than the original.
You can often improve the logic utilization of multiplexers by recoding
the select lines into full binary cases. Although logic is required to
perform the encoding, the overall logic utilization is often improved.
Buses of Multiplexers
The inputs to multiplexers are often data input buses in which the same
multiplexer function is performed on a set of data input buses. In these
cases, any inefficiency in the multiplexer is multiplied by the number of
bits in the bus. The issues described in the previous sections become even
more important for wide multiplexer buses.
For example, the recoding of select lines into full binary cases detailed in
the previous section can often be used in multiplexed buses. Recoding the
select lines may need to be completed only once for all the multiplexers
in the bus. By sharing the recoder logic among all the bits in the bus, you
can greatly improve the logic efficiency of a bus of multiplexers.
The degenerate multiplexer in the previous section requires five LUTs to
implement. If the inputs and output are 32 bits wide, the function could
require 32 × 5 or 160 LUTs for the whole bus. The recoder design uses only
two LUTs, and the select lines only need to be recoded once for the entire
bus. The binary 4:1 multiplexer requires two LEs per bit of the bus. The
6–68
Preliminary
Altera Corporation
October 2007
General Coding Guidelines
total logic utilization for the recoded version could be 2 + (2 x 32) or 66
LUTs for the whole bus, compared to 160 LUTs for the original version.
The logic savings become more important with wide multiplexer buses.
Using techniques to optimize degenerate multiplexers, removing
unneeded implicit defaults, and choosing the optimal DEFAULT or
OTHERS case can play an important role when optimizing buses of
multiplexers.
Cyclic Redundancy Check Functions
Cyclic redundancy check (CRC) computations are used heavily by
communications protocols and storage devices to detect any corruption
of the data. These functions are highly effective; there is a very low
probability that corrupted data can pass a 32-bit CRC check.
CRC functions typically use wide XOR gates to compare the data. The
way that synthesis tools flatten and factor these XOR gates to implement
the logic in FPGA LUTs can greatly impact the area and performance
results for the design. XOR gates have a cancellation property which
creates an exceptionally large number of reasonable factoring
combinations, so synthesis tools cannot always choose the best result by
default.
The 6-input ALUT has a significant advantage over 4-input LUTs for
these designs. When properly synthesized, CRC processing designs can
run at high speeds in devices with 6-input ALUTs.
The following guidelines help you improve the quality of results for CRC
designs in Altera devices.
If Performance is Important, Optimize for Speed
Synthesis tools flatten XOR gates to minimize area and depth of levels of
logic. Synthesis tools such as Quartus II integrated synthesis target area
optimization by default for these logic structures. Therefore, for more
focus on depth reduction, set the synthesis optimization technique to
speed.
1
Note that flattening for depth sometimes causes a significant
increase in area.
Use Separate CRC Blocks Instead of Cascaded Stages
Some designers optimize their CRC designs to use cascaded stages, for
example, four stages of 8 bits. In such designs, intermediate calculations
are used as needed (such as the calculations after 8, 24, or 32 bits)
Altera Corporation
October 2007
6–69
Preliminary
Quartus II Handbook, Volume 1
depending on the data width. This design is not optimal in FPGA devices.
The XOR cancellations that can be performed in CRC designs mean that
the function does not require all the intermediate calculations to
determine the final result. Therefore, forcing the use of intermediate
calculations increases the area required to implement the function, as
well as increasing the logic depth because of the cascading. It is typically
better to create full separate CRC blocks for each data width that you
need in the design, then multiplex them together to choose the
appropriate mode at a given time.
Use Separate CRC Blocks Instead of Allowing Blocks to Merge
Synthesis tools often attempt to optimize CRC designs by sharing
resources and extracting duplicates in two different CRC blocks because
of the factoring options in the XOR logic. As addressed previously, the
CRC logic allows significant reductions but this works best when each
CRC function is optimized separately. Check for duplicate extraction
behavior if you have different CRC functions that are driven by common
data signals or that feed the same destination signals.
If you are having problems with the quality of results and you see that
two CRC functions are sharing logic, ensure that the blocks are
synthesized independently using one of the following methods:
■
Define each CRC block as a separate design partition in an
incremental compilation design flow.
f
■
For details, refer to the Quartus II Incremental Compilation
for Hierarchical and Team-Based Design chapter in volume 1
of the Quartus II Handbook.
Synthesize each CRC block as a separate project and then write a
separate VQM or EDIF netlist file for each.
Take Advantage of Latency if Available
If your design can use more than one cycle to implement the CRC
functionality, adding registers and retiming the design can help reduce
area, improve performance, and reduce power utilization. If your
synthesis tool offers a retiming feature (such as the Quartus II software
Perform gate-level register retiming option), you can insert an extra
bank of registers at the input and allow the retiming feature to move the
registers for better results. You can also build the CRC unit half as wide
and alternate between halves of the data in each clock cycle.
6–70
Preliminary
Altera Corporation
October 2007
General Coding Guidelines
Save Power by Disabling CRC Blocks When Not in Use
CRC designs are heavy consumers of dynamic power because the logic
toggles whenever there is a change in the design. To save power, use
clock enables to disable the CRC function for every clock cycle that the
logic is not needed. Some designs don't check the CRC results for a few
clock cycles while other logic is performed. It is valuable to disable the
CRC function even for this short amount of time.
Use the Device Synchronous Load (sload) Signal to Initialize
The data in many CRC designs must be initialized to 1’s before operation.
If your target device supports the use of the sload signal, you should use
it to set all the registers in your design to 1’s before operation. To enable
use of the sload signal, follow the coding guidelines presented in
“Secondary Register Control Signals Such as Clear and Clock Enable” on
page 6–39. You can check the register equations in the Timing Closure
Floorplan or the Chip Planner to ensure that the signal was used as
expected.
f
If you must force a register implementation using an sload signal, you
can use low-level device primitives as described in the Introduction to
Low-Level Primitives Design User Guide.
Comparators
Synthesis software, including Quartus II integrated synthesis, uses
device and context-specific implementation rules for comparators (<, >,
or ==) and selects the best one for your design. This section provides
some information about the different types of implementations available
and provides suggestions on how you can code your design to encourage
a specific implementation.
The == comparator is implemented in general logic cells. The <
comparison can be implemented using the carry chain or general logic
cells. In devices with 6-input ALUTs, the carry chain is capable of
comparing up to three bits per cell. In devices with 4-input LUTs, the
capacity is one bit of comparison per cell, similar to an add/subtract
chain. The carry chain implementation tends to be faster than the general
logic on standalone benchmark test cases, but can result in lower
performance when it is part of a larger design due to the increased
restriction on the Fitter. The area requirement is similar for most input
patterns. The synthesis software selects an appropriate implementation
based on the input pattern.
Altera Corporation
October 2007
6–71
Preliminary
Quartus II Handbook, Volume 1
If you are using Quartus II integrated synthesis, you can guide the
synthesis by using specific coding styles. To select a carry chain
implementation explicitly, rephrase your comparison in terms of
addition. As a simple example, the following coding style allows the
synthesis tool to select the implementation, which is most likely using
general logic cells in modern device families:
wire [6:0] a,b;
wire alb = a<b;
In the following coding style, the synthesis tool uses a carry chain (except
for a few cases, such as when the chain is very short or the signals a and
b minimize to the same signal):
wire [6:0] a,b;
wire [7:0] tmp = a - b;
wire alb = tmp[7]
This second coding style uses the top bit of the tmp signal, which is 1 in
twos complement logic if a is less than b, because the subtraction a – b
results in a negative number.
If you have any information about the range of the input, you have “don't
care” values that you can use to optimize the design. Because this
information is not available to the synthesis tool, you can often reduce the
device area required to implement the comparator with specific hand
implementation of the logic.
You can also check whether a bus value is within a constant range with a
small amount of logic area by using the logic structure shown in
Figure 6–7. This type of logic occurs frequently in address decoders.
Figure 6–7. Example Logic Structure for Using Comparators to Check a Bus
Value Range
Address[ ]
6–72
Preliminary
< 2f00
< 200
< 1a0
< 100
Select[3]
Select[2]
Select[1]
Select[0]
Altera Corporation
October 2007
Designing with Low-Level Primitives
Counters
Implementing counters in HDL code is easy; they are implemented with
an adder followed by registers. Remember that the register control
signals, such as enable (ena), synchronous clear (sclr) and synchronous
load (sload), are available. For the best area utilization, ensure that the
up/down control or controls are expressed in terms of one addition
instead of two separate addition operators.
If you use the following coding style, your synthesis tool may implement
two separate carry chains for addition (if it doesn't detect the issue and
optimize the logic):
out <= count_up ? out + 1 : out - 1;
The following coding style requires only one adder along with some
other logic:
out <= out + (count_up ? 1 : -1);
In this case, the coding style better matches the device hardware because
there is only one carry chain adder, and the –1 constant logic is
implemented in the look-up table in front of the adder without adding
extra area utilization.
Designing with
Low-Level
Primitives
Low-level HDL design is the practice of using low-level primitives and
assignments to dictate a particular hardware implementation for a piece
of logic. Low-level primitives are small architectural building blocks that
assist you in creating your design. With the Quartus II software, you can
use low-level HDL design techniques to force a specific hardware
implementation that can help you achieve better resource utilization or
faster timing results.
1
Using low-level primitives is an advanced technique to help
with specific design challenges, and is optional in the Altera
design flow. For many designs, synthesizing generic HDL
source code and Altera megafunctions gives you the best
results.
Low-level primitives allow you to use the following types of coding
techniques:
■
■
Altera Corporation
October 2007
Instantiate the logic cell or LCELL primitive to prevent Quartus II
integrated synthesis from performing optimizations across a logic
cell
Create carry and cascade chains using CARRY, CARRY_SUM, and
CASCADE primitives
6–73
Preliminary
Quartus II Handbook, Volume 1
■
■
■
■
Instantiate registers with specific control signals using DFF
primitives
Specify the creation of LUT functions by identifying the LUT
boundaries
Use I/O buffers to specify I/O standards, current strengths, and
other I/O assignments
Use I/O buffers to specify differential pin names in your HDL code,
instead of using the automatically-generated negative pin name for
each pair
Refer to the Designing With Low-Level Primitives User Guide for details
about and examples of using these types of assignments.
Conclusion
Because coding style and megafunction implementation can have such a
large effect on your design performance, it is important to match the
coding style to the device architecture from the very beginning of the
design process. To improve design performance and area utilization, take
advantage of advanced device features, such as memory and DSP blocks,
as well as the logic architecture of the targeted Altera device by following
the coding recommendations presented in this chapter.
f
Referenced
Documents
For additional optimization recommendations, refer to the
Area and Timing Optimization chapter in volume 2 of the Quartus II
Handbook.
This chapter references the following documents:
■
■
■
■
6–74
Preliminary
Area and Timing Optimization in volume 2 of the Quartus II Handbook
Design Recommendations for Altera Devices in volume 1 of the
Quartus II Handbook
Quartus II Integrated Synthesis in volume 1 of the Quartus II Handbook
Synthesis section in volume 1 of the Quartus II Handbook
Altera Corporation
October 2007
Document Revision History
Document
Revision History
Table 6–2 shows the revision history for this chapter.
Table 6–2. Document Revision History (Part 1 of 2)
Date and
Document
Version
Changes Made
Summary of Changes
October 2007
v7.2.0
Reorganized “Referenced Documents” on page 6–74.
Updates for the Quartus II
software version 7.2.
May 2007
v7.1.0
Updates for the Quartus II software version 7.1 release,
including:
● Added Quartus II Language Templates.
● Updated text in Using Altera Megafunctions.
● Updated Table 6-1.
● Added Avoide Unsupported Reset Conditions.
● Added Check Read-During-Write Behavior.
● Added True Dual-Port Synchronous RAM.
● Added Specifying Initial Memory Contents at Power-Up.
● Added Referenced Documents.
Updates for the Quartus II
software version 7.1,
including the addition of
Arria GX devices, new HDL
design templates, new
support for inferring true
dual-port RAM blocks.
Clarified RAM inference
guidelines with respect to
synchronous memory and
read-during-write behavior.
March 2007
v7.0.0
Updated Quartus II software 7.0 revision and date only. No other
changes made to chapter.
—
November 2006
v6.1.0
Updates for the Quartus II software version 6.1 release,
including:
● Moved the “Simple Dual-Port, Dual-Clock Synchronous
RAM” on page 7–19 section within the chapter
● Added information about read-through-write conditions
● Added example code, including Examples 7–13 and 7–14;
Examples 7–17 and 7–19; and Example 7–23
● Added a section about “Designing with Low-Level Primitives”
on page 7–71
● Added information about implementing a safe state machine
● Reorganized the chapter, shuffling the “Coding Guidelines
for Registers and Latches” and “General Coding Guidelines”
and the subsections therein
● Added “Comparators” on page 7–69 and “Counters” on
page 7–71 to the General Coding Guidelines section
Updates for the Quartus II
software version 6.1,
including the addition of
Stratix III devices.
Changes to the
recommendations for RAM
block inference to ensure
better quality of results,
and new suggestions for
different general logic
structures.
May 2006
v6.0.0
Minor updates for the Quartus II software version 6.0.
—
October 2005
v5.1.0
Updated for the Quartus II software version 5.1.
—
Altera Corporation
October 2007
6–75
Preliminary
Quartus II Handbook, Volume 1
Table 6–2. Document Revision History (Part 2 of 2)
Date and
Document
Version
May 2005
v5.0.0
December 2004
v2.1
6–76
Preliminary
Changes Made
Summary of Changes
Chapter 4 was formerly Chapter 1 in version 4.2.
—
Updated for Quartus II software version 4.2:
Chapter 4 was formerly Chapter 1.
● General formatting and editing updates.
● Device family support descriptions updated.
● Updated HardCopy structured support for performance
improvements.
● Quartus II Archive File automatically receives buffer
insertion.
● Power Calculator now Power Estimator for affected devices.
● Updates to tables, figures.
● The description of How to Design HardCopy Stratix Devices
was updated.
● The description of HardCopy Timing Optimization Wizard
was updated.
● HardCopy Floorplans and Timing Modules was renamed to
Design Optimization.
● The description of Performance Estimation was updated.
● Added new section on Buffer Insertion.
● Location Constraints was updated.
● Targeting Designs to HardCopy APEX 20KC and HardCopy
APEX 20KE Devices was removed.
● A new section Altera Recommended HDL was added.
● Table 2–5 was added. It lists the HardCopy Stratix design
files collected by the hardCopy Files Wizard.
● The description of the HardCopy APEX Power Estimator was
updated.
● A new section about Targeting Designs to HardCopy APEX
Devices was added.
—
●
Altera Corporation
October 2007
Section III. Synthesis
As programmable logic devices (PLDs) become more complex and
require increased performance, advanced design synthesis has become
an important part of the design flow. In the Quartus® II software you can
use the Analysis and Synthesis module of the Compiler to analyze your
design files and create the project database. You can also use other EDA
synthesis tools to synthesize your designs, and then generate EDIF netlist
files or VQM files that can be used with the Quartus II software. This
section explains the options that are available for each of these flows, and
how they are supported in the Quartus II, version 7.2 software.
This section includes the following chapters:
■
■
■
■
■
■
1
Altera Corporation
Chapter 7, Synplicity Synplify and Synplify Pro Support
Chapter 8, Quartus II Integrated Synthesis
Chapter 9, Mentor Graphics LeonardoSpectrum Support
Chapter 10, Mentor Graphics Precision RTL Synthesis Support
Chapter 11, Synopsys Design Compiler FPGA Support
Chapter 12, Analyzing Designs with Quartus II Netlist Viewers
For information about the revision history for chapters in this
section, refer to each individual chapter for that chapter’s
revision history.
Section III–i
Preliminary
Synthesis
Section III–ii
Preliminary
Quartus II Handbook, Volume 1
Altera Corporation
7. Synplicity Synplify and
Synplify Pro Support
QII51009-7.2.0
Introduction
As programmable logic device (PLD) designs become more complex and
require increased performance, advanced synthesis has become an
important part of the design flow. This chapter documents support for
the Synplicity Synplify and Synplify Pro software in the Quartus® II
software, as well as key design flows, methodologies, and techniques for
achieving good results in Altera® devices. This chapter includes the
following topics:
■
■
■
■
■
General design flow with the Synplify and Quartus II software
Synplify software optimization strategies, including timing-driven
compilation settings, optimization options, and Altera-specific
attributes
Exporting designs and constraints to the Quartus II software using
NativeLink® integration
Guidelines for Altera megafunctions and library of parameterized
module (LPM) functions, instantiating them with the MegaWizard®
Plug-In Manager, and tips for inferring them from hardware
description language (HDL) code
Incremental compilation and block-based design, including the
Synplify Pro software MultiPoint flow
The content in this chapter applies to both the Synplify and Synplify Pro
software unless otherwise specified.This chapter includes the following
sections:
■
■
■
■
■
■
“Altera Device Family Support” on page 7–2
“Design Flow” on page 7–3
“Synplify Optimization Strategies” on page 7–8
“Exporting Designs to the Quartus II Software Using NativeLink
Integration” on page 7–17
“Guidelines for Altera Megafunctions and Architecture-Specific
Features” on page 7–32
“Incremental Compilation and Block-Based Design” on page 7–44
This chapter assumes that you have set up, licensed, and are familiar with
the Synplify or Synplify Pro software.
Altera Corporation
October 2007
7–1
Quartus II Handbook, Volume 1
Altera Device
Family Support
The Synplify software maps synthesis results to Altera device families.
The following list shows the Altera device families supported by the
Synplify software version 9.0, with the Quartus II software version 7.2:
■
■
■
■
■
■
■
■
■
■
■
■
Cyclone® III
Stratix® III
Stratix II, Stratix II GX, Hardcopy® II
Stratix, Stratix GX, HardCopy Stratix
Cyclone II
Cyclone
MAX® II
MAX® 7000, MAX 3000
APEX™ II
APEX 20K, APEX 20KC, APEX 20KE
FLEX® 10K, FLEX 6000
ACEX® 1K
The Synplify software also supports the following legacy devices that are
supported in the Quartus II software only with a specific license
requested at www.altera.com/mysupport:
■
■
Excalibur™ ARM®
Mercury™
The Synplify software also supports the following legacy devices that are
supported only in the Altera MAX+PLUS II software:
■
■
1
7–2
FLEX 8000
MAX 9000
To learn about new device support for a specific Synplify
version, refer to the release notes on Synplicity's web site at
www.synplicity.com.
Altera Corporation
October 2007
Design Flow
Design Flow
Altera Corporation
October 2007
A Quartus II software design flow using the Synplify software consists of
the following steps:
1.
Create Verilog HDL or VHDL design files in the Quartus II
software, Synplify software, or a text editor.
2.
Set up a project in the Synplify software and add the HDL design
files for synthesis.
3.
Select a target device and add timing constraints and compiler
directives to optimize the design during synthesis.
4.
Create a Quartus II project and import the technology-specific EDIF
(.edf) or VQM (.vqm) netlist, the Synopsys Constraints Format (.scf)
file (for TimeQuest constraints if a Stratix III or Cyclone III device is
selected), and the tool command language (.tcl) constraint file
generated by the Synplify software into the Quartus II software for
placement and routing, and for performance evaluation.
5.
After obtaining place-and-route results that meet your needs,
configure or program the Altera device.
7–3
Quartus II Handbook, Volume 1
Figure 7–1 shows the recommended design flow when using the Synplify
and the Quartus II software.
Figure 7–1. Recommended Design Flow
Verilog
HDL
(.v)
VHDL
(.vhd)
Functional/RTL
Simulation
Constraints
& Settings
Synplify Software
Forward Annotated
Project & Timing Constraints
(.tcl/.acf)
TechnologySpecific Netlist
(.vqm/.edf)
(1)Synopsys Constraints
Format (.scf) File
Constraints
& Settings
Gate-Level
Functional
Simulation
Post-Synthesis
Simulation Files
(.vho/.vo)
Quartus II Software
Gate-Level Timing
Simulation
No
Timing & Area
Requirements
Satisfied?
Post Place-and-Route
Simulation File
(.vho/.vo)
Yes
Configuration/
Programming
Files (.sof/.pof)
Program/Configure Device
The Synplify and Synplify Pro software support both VHDL and Verilog
HDL source files. The Synplify Pro software also supports mixed
synthesis, allowing a combination of VHDL and Verilog HDL source
files.
7–4
Altera Corporation
October 2007
Design Flow
Specify timing constraints and attributes for the design in a Synplify
Constraints File (.sdc) with the SCOPE window in the Synplify software
or directly in the HDL source file. Compiler directives can also be defined
in the HDL source file. Many of these constraints are forward-annotated
for use by the Quartus II software.
The HDL Analyst that is included in the Synplify software is a graphical
tool for generating schematic views of the technology-independent
register transfer level (RTL) view netlist (.srs) and technology-view netlist
(.srm) files. You can use the Synplify HDL Analyst to analyze and debug
your design visually. The HDL Analyst supports cross probing between
the RTL and Technology views, the HDL source code, and the Finite State
Machine (FSM) viewer. Refer to “FSM Compiler” on page 7–11.
1
A separate license file is required to enable the HDL Analyst in
the Synplify software. The Synplify Pro software includes the
HDL Analyst.
Once synthesis is complete, import the electronic design interchange
format (EDIF) or Verilog Quartus Mapping (VQM) netlist to the
Quartus II software for place-and-route. You can use the Tcl file
generated by the Synplify software to forward-annotate your constraints
(including device selection), and optionally to set up your project in the
Quartus II software.
If a Stratix III or Cyclone III device is selected, the Quartus II software
uses the SDC-format timing constraints from the .scf file with the
TimeQuest Timing Analyzer by default. For other devices, the Quartus II
software uses the Tcl Classic Timing Analyzer timing constraints written
to the Quartus Setting File (.qsf). Refer to “Passing TimeQuest SDC
Timing Constraints to the Quartus II Software in the .scf File” on
page 7–20 for information about to manually changing from the
TimeQuest Timing Analyzer to the Classic Timing Analyzer manually for
Stratix III and Cyclone III devices.
If the area and timing requirements are satisfied, use the files generated
by the Quartus II software to program or configure the Altera device. As
shown in Figure 7–1, if your area or timing requirements are not met, you
can change the constraints in the Synplify software or the Quartus II
software and repeat the synthesis. Repeat the process until the area and
timing requirements are met.
While you can perform simulation at various points in the process, final
timing analysis should be performed after placement and routing is
complete. Formal verification may also be performed at various stages of
the design process.
Altera Corporation
October 2007
7–5
Quartus II Handbook, Volume 1
f
For more information about how the Synplify software supports formal
verification, refer to the Formal Verification section in volume 3 of the
Quartus II Handbook.
You can also use other options and techniques in the Quartus II software
to meet area and timing requirements. One such option is called
WYSIWYG Primitive Resynthesis, which can perform optimizations on
your VQM netlist within the Quartus II software.
f
For information about netlist optimizations, refer to the Netlist
Optimizations and Physical Synthesis chapter in volume 2 of the Quartus II
Handbook.
In some cases, you may be required to modify the source code if area and
timing requirements cannot be met using options in the Synplify and
Quartus II software.
After synthesis, the Synplify software produces several intermediate and
output files. Table 7–1 lists these file types.
Table 7–1. Synplify Intermediate and Output Files (Part 1 of 2)
File Extensions
File Description
.srs
Technology-independent RTL netlist that can be read only by the Synplify software
.srm
Technology view netlist
.srr (1)
Synthesis Report file
.edf/.vqm (2)
Technology-specific netlist in electronic design interchange format (EDIF) or VQM file
format
7–6
Altera Corporation
October 2007
Design Flow
Table 7–1. Synplify Intermediate and Output Files (Part 2 of 2)
File Extensions
File Description
.acf/.tcl (3)
Forward-annotated constraints file containing constraints and assignments
.scf
Synopsys Constraint Format file containing timing constraints for the TimeQuest Timing
Analyzer
Notes to Table 7–1:
(1)
(2)
(3)
This report file includes performance estimates that are often based on pre-place-and-route information. Use the
fMAX reported by the Quartus II software after place-and-route—it is the only reliable source of timing information.
This report file includes post-synthesis device resource utilization statistics that may inaccurately predict resource
usage after place-and-route. The Synplify software does not account for black box functions nor for logic usage
reduction achieved through register packing performed by the Quartus II software. Register packing combines a
single register and look-up table (LUT) into a single logic cell, reducing the logic cell utilization below the Synplify
software estimate. Use the device utilization reported by the Quartus II software after place-and-route.
An EDIF output file (.edf) is created for ACEX 1K, FLEX 10K, FLEX 10KA, FLEX 10KE, FLEX 6000, FLEX 8000,
MAX 7000, MAX 9000, and MAX 3000 devices. A VQM file is created for all other Altera device families.
An Assignment and Configuration File (.acf) file is created only for ACEX 1K, FLEX 10K, FLEX 10KA, FLEX 10KE,
FLEX 6000, FLEX 8000, MAX 7000, MAX 9000, and MAX 3000 devices. The ACF is generated for backward
compatibility with the MAX+PLUSII software. A Tcl file for the Quartus II software is created for all devices. The
Tcl file contains the appropriate Tcl commands to create and set up a Quartus II project and, if applicable, the
MAX+PLUS II assignments are imported from the ACF file.
Output Netlist File Name and Result Format
Specify the output netlist directory location and name by performing the
following steps:
1.
On the Project menu, click Implementation Options.
2.
Click the Implementation Results tab.
3.
In the Results Directory box, type your output netlist file directory
location.
4.
In the Result File Name box, type your output netlist file name.
By default, directory and file name are set to the project implementation
directory and the top-level design module or entity name.
The Result Format and Quartus version options are also available on the
Implementation Results tab. The Result Format list specifies an EDIF or
VQM netlist depending on your device family. The software creates an
EDIF output netlist file only for ACEX 1K, FLEX 10K, FLEX 6000,
FLEX 8000, MAX 7000, MAX 9000, and MAX 3000 devices. For other
Altera devices, the software generates a VQM-formatted netlist.
Altera Corporation
October 2007
7–7
Quartus II Handbook, Volume 1
Beginning with the Synplify software version 8.4, select the version of the
Quartus II software that you are using in the Quartus version list. This
option ensures that the netlist is compatible with the software version and
supports the newest features. Altera recommends using the latest version
of the Quartus II software whenever possible. If your Quartus II software
is newer than the versions available in the Quartus version list, check if
there is a newer version of the Synplify software available that supports
the current Quartus II software version. Otherwise, choose the latest
version in the list for the best compatibility.
1
Synplify
Optimization
Strategies
f
The Quartus version list is available only after selecting an
Altera device.
As designs become more complex and require increased performance,
using different optimization strategies has become important.
Combining Synplify software constraints with VHDL and Verilog HDL
coding techniques and Quartus II software options can help you obtain
the required results.
For additional design and optimization techniques, refer to the Design
Recommendations for Altera Devices chapter in volume 1 and the Area and
Timing Optimization chapter in volume 2 of the Quartus II Handbook.
The Synplify software offers many constraints and optimization
techniques to improve your design’s performance. The Synplify Pro
software adds some additional techniques that are not supported in the
basic Synplify software. Wherever this document describes Synplify
support, this includes both the basic Synplify and the Synplify Pro
software; Synplify Pro-only features are labeled as such. This section
provides an overview of some of the techniques you can use to help
improve the quality of your results.
f
For more information about applying the attributes discussed in this
section, refer to the Tasks and Tips chapter of the Synplify Software User
Guide.
Implementations in Synplify Pro
To create different synthesis results without overwriting the others, In the
Synplify Pro software, on the Project menu, click New Implementation.
For each implementation, specify the target device, synthesis options,
and constraint files. Each implementation generates its own subdirectory
that contains all the resulting files, including VQM/EDIF, .scf and Tcl
files, from a compilation of the particular implementation. You can then
compare the results of the different implementations to find the optimal
set of synthesis options and constraints for a design.
7–8
Altera Corporation
October 2007
Synplify Optimization Strategies
Timing-Driven Synthesis Settings
The Synplify software supports timing-driven synthesis with
user-assigned timing constraints to optimize the performance of the
design. The Synplify software optimizes the design to attempt to meet
these constraints.
The Quartus II NativeLink feature allows timing constraints that are
applied in the Synplify software to be forward-annotated for the
Quartus II software using either a Tcl script file or a .scf file for
timing-driven place and route. Refer to “Passing TimeQuest SDC Timing
Constraints to the Quartus II Software in the .scf File” on page 7–20 or
“Passing Constraints to the Quartus II Software using Tcl Commands” on
page 7–22 for more details about how constraints such as clock
frequencies, false paths, and multicycle paths are forward-annotated.
This section explains some of the important timing constraints in the
Synplify software.
1
The Synplify Synthesis Report File (.srr) contains timing reports
of estimated place-and-route delays. The Quartus II software
can perform further optimizations on a post-synthesis netlist
from third-party synthesis tools. In addition, designs may
contain black boxes or intellectual property (IP) functions that
have not been optimized by the third-party synthesis software.
Actual timing results are obtained only after the design has gone
through full placement and routing in the Quartus II software.
For these reasons, the Quartus II post place-and-route timing
reports provide a more accurate representation of the design.
The statistics in these reports should be used to evaluate design
performance.
Clock Frequencies
For single-clock designs, specify a global frequency when using the
push-button flow. While this flow is simple and provides good results,
often it does not meet the performance requirements for more advanced
designs. You can use timing constraints, compiler directives, and other
attributes to help optimize the performance of a design. You can enter
these attributes and directives directly in the HDL code. Alternatively,
you can enter attributes (not directives) into an .sdc file with the SCOPE
window in the Synplify software.
Use the SCOPE window to set global frequency requirements for the
entire design and individual clock settings. Use the Clocks tab in the
SCOPE window to specify frequency (or period), rise times, fall times,
duty cycle, and other settings. Assigning individual clock settings, rather
than over-constraining the global frequency, helps the Quartus II
Altera Corporation
October 2007
7–9
Quartus II Handbook, Volume 1
software and the Synplify software achieve the fastest clock frequency for
the overall design. The define_clock attribute assigns clock
constraints.
Multiple Clock Domains
The Synplify software can perform timing analysis on unrelated clock
domains. Each clock group is a different clock domain and is treated as
unrelated to the clocks in all other clock groups. All the clocks in a single
clock group are assumed to be related and the Synplify software
automatically calculates the relationship between the clocks. You can
assign clocks to a new clock group, or put related clocks in the same clock
group by using the Clocks tab in the SCOPE window or with the
define_clock attribute.
Input/Output Delays
Specify the input and output delays for the ports of a design in the
Input/Output tab of the SCOPE window or with the
define_input_delay and define_output_delay attributes. The
Synplify software does not allow you to assign the tCO and tSU values
directly to inputs and outputs. However, a tCO value can be inferred by
setting an external output delay, and a tSU value can be inferred by setting
an external input delay. Equation 1 and 2 below illustrate the relationship
between tCO /tSU and the input/output delays:
(1)
tCO = clock period – external output delay
(2)
tSU = clock period – external input delay
When the syn_forward_io_constraints attribute is set to 1, the
Synplify software passes the external input and output delays to the
Quartus II software using NativeLink integration. The Quartus II
software then uses the external delays to calculate the maximum system
frequency.
Multicycle Paths
Specify any multicycle paths in the design in the Multi-Cycle Paths tab
of the SCOPE window or with the define_multicycle_path
attribute. A multicycle path is a path that requires more than one clock
cycle to propagate. It is important to specify which paths are multicycle
to avoid having the Quartus II and the Synplify compilers work
excessively on a non-critical path. Not specifying these paths can also
result in an inaccurate critical path being reported during timing analysis.
7–10
Altera Corporation
October 2007
Synplify Optimization Strategies
False Paths
False paths are paths that should not be considered during timing
analysis or which should be assigned low (or no) priority during
optimization. Some examples of false paths are slow asynchronous resets
and test logic added to the design. Set these paths in the False Paths tab
of the SCOPE window. Use the define_false_path attribute.
FSM Compiler
If the FSM Compiler is turned on, the compiler automatically detects state
machines in a design. The compiler can then extract and optimize the
state machine. The FSM Compiler analyzes the state machine and decides
to implement sequential, gray, or one-hot encoding based on the number
of states. It also performs unused-state analysis, optimization of
unreachable states, and minimization of transition logic.
If the FSM Compiler is turned off, the compiler does not infer state
machines. The state machines are implemented as coded in the HDL
code. Thus, if the coding style for the state machine was sequential, then
the implementation is also sequential. If the FSM Compiler is turned on,
the compiler infers the state machines. The implementation is based on
the number of states regardless of the coding style in the HDL code.
You can use the syn_state_machine complier directive to specify or
prevent a state machine from being extracted and optimized. To override
the default encoding of the FSM Compiler, use the syn_encoding
directive.
The values for the syn_encoding directive are shown in Table 7–2.
Table 7–2. syn_encoding Directive Values
Value
Description
Sequential
Generates state machines with the fewest possible flip-flops. Sequential, also called binary,
state machines are useful for area-critical designs when timing is not the primary concern.
Gray
Generates state machines where only one flip-flop changes during each transition.
Gray-encoded state machines tend to be free of glitches.
One-hot
Generates state machines containing one flip-flop for each state. One-hot state machines
typically provide the best performance and shortest clock-to-output delays. However, one-hot
implementations are usually larger than binary implementations.
Safe
Generates extra control logic to force the state machine to the reset state if an invalid state is
reached. The safe value can be used in conjunction with the other three values, which results
in the state machine being implemented with the requested encoding scheme and the
generation of the reset logic.
Altera Corporation
October 2007
7–11
Quartus II Handbook, Volume 1
Example 7–1 shows sample VHDL code for applying the syn_encoding
directive.
Example 7–1. VHDL Code for syn_encoding
SIGNAL current_state : STD_LOGIC_VECTOR(7 DOWNTO 0);
ATTRIBUTE syn_encoding : STRING;
ATTRIBUTE syn_encoding OF current_state : SIGNAL IS "sequential";
The default is to optimize state machine logic for speed and area, but this
is potentially undesirable for critical systems. The safe value generates
extra control logic to force the state machine to the reset state if an invalid
state is reached.
FSM Explorer in Synplify Pro
The Synplify Pro software can use the FSM Explorer to explore different
encoding styles for a state machine automatically, and then implement
the best encoding based on the overall design constraints. The FSM
Explorer uses the FSM Compiler to identify and extract state machines
from a design. However, unlike the FSM Compiler which chooses the
encoding style based on the number of states, the FSM Explorer tries
several different encoding styles before choosing a specific one. The
trade-off is that the compilation requires more time to perform the
analysis of the state machine, but finds an optimal encoding scheme for
the state machine.
Optimization Attributes and Options
The following sections describe other attributes and options that you can
modify in the Synplify software to improve your design performance.
Retiming in Synplify Pro
The Synplify Pro software can retime a design, which can improve the
timing performance of sequential circuits by moving registers (register
balancing) across combinational elements. Be aware that retimed
registers incur name changes. To retime your design, turn on the
Retiming option in the Device tab in the Implementation Options
section, or use the syn_allow_retiming attribute.
Maximum Fan-Out
When your design has critical path nets with high fan-out, you can use
the syn_maxfan attribute to control the fan-out of the net. Setting this
attribute for a specific net results in the replication of the driver of the net
to reduce the overall fan-out. The syn_maxfan attribute takes an integer
7–12
Altera Corporation
October 2007
Synplify Optimization Strategies
value and applies it to inputs or registers. (The syn_maxfan attribute
cannot be used to duplicate control signals, and the minimum allowed
value of the attribute is 4.) Using this attribute may result in increased
logic resource utilization, thus putting a strain on routing resources and
leading to long compile times and difficult fitting.
If you need to duplicate an output register or output enable register, you
can create a register for each output pin by using the syn_useioff
attribute (refer to “Register Packing”).
Preserving Nets
During synthesis, the compiler maintains ports, registers, and
instantiated components. However, some nets may not be maintained to
create an optimized circuit. Applying the syn_keep directive overrides
the optimization of the compiler and preserves the net during synthesis.
The syn_keep directive takes a Boolean value and can be applied to
wires (Verilog HDL) and signals (VHDL). Setting the value to true
preserves the net through synthesis.
Register Packing
Altera devices allow for the packing of registers into I/O cells. Altera
recommends allowing the Quartus II software to make the I/O register
assignments. However, it is possible to control register packing with the
syn_useioff attribute. The syn_useioff attribute takes a Boolean
value and can be applied to ports or entire modules. Setting the value to
1 instructs the compiler to pack the register into an I/O cell. Setting the
value to 0 prevents register packing in both the Synplify and Quartus II
software.
Resource Sharing
The Synplify software uses resource sharing techniques during synthesis
by default to reduce area. Turning off the Resource Sharing option on the
Options tab of the Implementation Options dialog box can improve
performance results for some designs. If you turn off this option, be sure
to check the results to determine if it helps the timing performance; if it
does not help, then you should leave Resource Sharing turned on.
Preserving Hierarchy
The Synplify software performs cross-boundary optimization by default.
This results in the flattening of the design to allow optimization. Use the
syn_hier attribute to over-ride the default compiler settings. The
Altera Corporation
October 2007
7–13
Quartus II Handbook, Volume 1
syn_hier attribute takes a string value and applies it to modules and/or
architectures. Setting the value to hard maintains the boundaries of a
module and/or architecture, and prevents cross-boundary optimization.
By default, the Synplify software generates a hierarchical VQM file. To
flatten the file, set the syn_netlist_hierarchy attribute equal to 0.
Register Input and Output Delays
The advanced options called define_reg_input_delay and
define_reg_output_delay can speed up paths feeding a register or
coming from a register by a specific number of nanoseconds. The Synplify
software attempts to meet the global clock frequency goals for a design as
well as the individual clock frequency goals (set with define_clock).
You can use these attributes to add delay to paths feeding into or out of
registers to further constrain critical paths.
These options are useful to close timing when your design does not meet
timing goals because the routing delay after placement and routing
exceeds the delay predicted by the Synplify software. Rerun synthesis
using this option, specifying the actual routing delay (from
place-and-route results) so that the tool can meet the required clock
frequency.
In the SCOPE constraint window, use the registers panel with the
following entries:
■
■
■
Register—Specifies the name of the register. If you have initialized a
compiled design, you can choose the name from the list.
Type—Specifies whether the delay is an input or output delay.
Route—Shrinks the effective period for the constrained registers by
the specified value without affecting the clock period that is
forward-annotated to the Quartus II software.
Use the following Tcl command syntax to specify an input or output
register delay in nanoseconds.
Example 7–2. Specifying an Input or Output Register Delay Using Tcl Command Syntax
define_reg_input_delay {<register>} -route <delay in ns>
define_reg_output_delay {<register>} -route <delay in ns>
7–14
Altera Corporation
October 2007
Synplify Optimization Strategies
syn_direct_enable
This attribute controls the assignment of a clock-enable net to the
dedicated enable pin of a register. Using this attribute, you can direct the
Synplify mapper to use a particular net as the only clock enable when the
design has multiple clock enable candidates.
You can also use this attribute as a compiler directive to infer registers
with clock enables. To do so, enter the syn_direct_enable directive in
your source code, not the SCOPE spreadsheet.
The syn_direct_enable data type is Boolean. A value of 1 or true
enables net assignment to the clock-enable pin. The syntax for Verilog
HDL is shown below:
object /* synthesis syn_direct_enable = 1 */ ;
Standard I/O Pad
For certain Altera devices and the equivalent device I/O standard, you
can specify the I/O standard type to use for the I/O pad in the design
using the I/O Standard panel in the Synplify SCOPE window.
Example 7–3 shows the Synplify SDC syntax for the define_io_standard
constraint, in which the delay_type must be either input_delay or
output_delay.
Example 7–3. Synplify SDC Syntax for the define_io_standard Constraint
define_io_standard [-disable|-enable] {<objectName>} -delay_type \
[input_delay|output_delay] <columnTclName>{<value>} \
[<columnTclName>{<value>}...]
f
For details about supported I/O standards, refer to Altera I/O Standards
in the Synplify Reference Manual.
Altera-Specific Attributes
The following attributes are for use with specific Altera device features.
These attributes are forward-annotated to the Quartus II project and are
used during the place-and-route process.
Altera Corporation
October 2007
7–15
Quartus II Handbook, Volume 1
altera_chip_pin_lc
Use this attribute to make pin assignments. This attribute takes a string
value and applies it to inputs and outputs. The attribute can be used only
on the ports of the top-level entity in the design, and cannot be used to
assign pin locations from entities at lower levels of the design hierarchy.
1
This attribute is not supported for any of the MAX series
devices. In the SCOPE window, select the attribute
altera_chip_pin_lc and set the value to a pin number or a list of
pin numbers.
Example 7–4 shows VHDL code for making location assignments to
ACEX 1K and FLEX 10KE devices.
1
The “@” is used to specify pin locations for ACEX 1K and
FLEX 10KE devices. For these devices, the pin location
assignments are written to the output EDIF.
Example 7–4. Making Location Assignments to ACEX 1K and FLEX 10KE Devices, VHDL
ENTITY sample (data_in : IN STD_LOGIC_VECTOR (3 DOWNTO 0);
data_out: OUT STD_LOGIC_VECTOR (3 DOWNTO 0));
ATTRIBUTE altera_chip_pin_lc : STRING;
ATTRIBUTE altera_chip_pin_lc OF data_out : SIGNAL IS "@14, @5,@16, @15";
Example 7–5 shows VHDL code for making location assignments for
other Altera devices. The pin location assignments for these devices are
written to the output Tcl script.
Example 7–5. Making Location Assignments to Other Devices, VHDL
ENTITY sample (data_in : IN STD_LOGIC_VECTOR (3 DOWNTO 0);
data_out: OUT STD_LOGIC_VECTOR (3 DOWNTO 0));
ATTRIBUTE altera_chip_pin_lc : STRING;
ATTRIBUTE altera_chip_pin_lc OF data_out : SIGNAL IS "14, 5, 16,
15";
1
The data_out signal is a 4-bit signal; data_out[3] is
assigned to pin 14 and data_out[0] is assigned to pin 15.
altera_implement_in_esb or altera_implement_in_eab
You can use these attributes to implement logic in either embedded
system blocks (ESBs) or embedded array blocks (EABs) rather than in
logic resources to improve area utilization. The modules selected for such
implementation cannot have feedback paths, and either all or none of the
7–16
Altera Corporation
October 2007
Exporting Designs to the Quartus II Software Using NativeLink Integration
I/Os must be registered. This attribute takes a boolean value and can be
applied to instances. (This option is applicable for devices with
ESBs/EABs only. For example, the Stratix family of devices is not
supported by this option. This attribute is ignored for designs targeting
devices that do not have ESBs or EABs.)
altera_io_powerup
You can use this attribute to define the power-up value of an I/O register
that has no set or reset. This attribute takes a string value (high|low) and
applies it to ports that have I/O registers.
altera_io_opendrain
Use this attribute to specify open-drain mode I/O ports. This attribute
takes a boolean value and applies it to outputs or bidirectional ports for
devices that support open-drain mode.
Exporting
Designs to the
Quartus II
Software Using
NativeLink
Integration
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 other EDA design entry or synthesis, simulation,
and timing analysis tools automatically from within the Quartus II
software. After a design is synthesized in the Synplify software, a VQM
(or EDIF) netlist file, an .scf file for TimeQuest Timing Analyzer timing
constraints, and Tcl files are used to import the design into the Quartus II
software for place-and-route. You can run the Quartus II software from
within the Synplify software or as a standalone application. Once you
have imported the design into the Quartus II software, you can specify
different options to further optimize the design.
1
When you are using NativeLink integration, the path to your
project must not contain white space. The Synplify software
uses Tcl scripts to communicate with the Quartus II software,
and the Tcl language does not accept arguments with white
space in the path.
You can use NativeLink integration to integrate the Synplify software
and Quartus II software with a single GUI for both the synthesis and
place-and-route operations. NativeLink integration allows you to run the
Quartus II software from within the Synplify software GUI or to run the
Synplify software from within the Quartus II software GUI.
Altera Corporation
October 2007
7–17
Quartus II Handbook, Volume 1
This section explains the different Nativelink flows and provides details
on how constraints are passed to the Quartus II software. This section
describes the following topics:
■
■
■
■
■
“Running the Quartus II Software from within the Synplify
Software” on page 7–18
“Using the Quartus II Software to Run the Synplify Software” on
page 7–19
“Running the Quartus II Software Manually Using the
Synplify-Generated Tcl Script” on page 7–19
“Passing TimeQuest SDC Timing Constraints to the Quartus II
Software in the .scf File” on page 7–20
“Passing Constraints to the Quartus II Software using Tcl
Commands” on page 7–22
Running the Quartus II Software from within the Synplify
Software
To use the Quartus II software from within the Synplify software, you
must first verify that the QUARTUS_ROOTDIR environment variable
contains the Quartus II software installation directory. This environment
variable is required to use the Synplify and Quartus II software together.
Under each Implementation in the Synplify Pro software, you can create
a place-and-route implementation called pr_<number> Altera Place and
Route. You can create new place and route implementations using the
New P&R button in the GUI. To run the Quartus II software in
command-line mode after each synthesis run, use the text box to turn on
the place-and-route implementation. The results of the place and route
are written to a log file in the pr_<number> directory under the current
implementation directory.
You can also use the commands in the Quartus II menu to run the
Quartus II software at any time following a successful completion of
synthesis. Use one of the following commands from the Quartus II
submenu under the Options menu in the Synplify software:
■
■
7–18
Launch Quartus—Opens the Quartus II software GUI and creates a
Quartus II project with the synthesized output file,
forward-annotated timing constraints, and pin assignments. You can
use this to configure options for the project and execute any
Quartus II commands.
Run Background Compile—Runs the Quartus II software in
command-line mode with the project settings from the synthesis run.
The results of the place-and-route are written to a log file.
Altera Corporation
October 2007
Exporting Designs to the Quartus II Software Using NativeLink Integration
The <project_name>_cons.tcl file is used to set up the Quartus II project
and calls the <project_name>.tcl file to pass constraints from the Synplify
software to the Quartus II software. By default, the <project_name>.tcl file
contains device, timing, and location assignments. If a Stratix III or a
Cyclone III device is selected, the <project_name>.tcl file contains the
command to use the Synplify-generated .scf constraints file with the
TimeQuest Timing Analyzer instead of using the Tcl constraints with the
Classic Timing Analyzer.
Using the Quartus II Software to Run the Synplify Software
You can set up the Quartus II software to run the Synplify software for
synthesis using NativeLink integration. This feature allows you to use the
Synplify software to synthesize a design as part of a normal compilation
in the Quartus II software.
To set up Synplify in Quartus II, on the Tools menu, click Options. In the
Options window, click EDA Tool Options and specify the path of
Synplify or Synplify Pro software.
f
For detailed information about using NativeLink integration with the
Synplify software, refer to the Quartus II Help.
1
If you are running the Quartus II software version 7.1 or later,
running the Synplify software with NativeLink integration is
supported on both floating network and node-locked single-PC
licenses. Both types of licenses support batch mode compilation.
Running the Quartus II Software Manually Using the
Synplify-Generated Tcl Script
You can also use the Quartus II software separately from the Synplify
software. To run the Tcl script generated by the Synplify software to set
up your project and set up assignments such as the device selection,
perform the following steps:
1.
Ensure the VQM/EDIF, .scf (if you are using the TimeQuest Timing
Analyzer timing constraints), and Tcl files are located in the same
directory (they should be located in the implementation directory
by default).
2.
In the Quartus II software, on the View menu, point to Utility
Windows and click Tcl Console. The Quartus II Tcl Console opens.
3.
At the Tcl Console command prompt, type the following:
source <path>/<project name>_cons.tcl r
Altera Corporation
October 2007
7–19
Quartus II Handbook, Volume 1
Passing TimeQuest SDC Timing Constraints to the Quartus II
Software in the .scf File
The 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 constraints format, Synopsys Design
Constraints (SDC). This section explains how timing constraints set in
Synplify are passed to the Quartus II software for use with the TimeQuest
Timing Analyzer.
The timing constraints you set in Synplify are stored in the Synplify
Design Constraints (.sdc) file. The Tcl file always contains all other
constraints for the Quartus II software, such as the device specification
and any location constraints. The timing constraints are
forward-annotated using the Tcl file for the Quartus II Classic Timing
Analyzer, as described in “Passing Constraints to the Quartus II Software
using Tcl Commands” on page 7–22. For the TimeQuest Timing Analyzer,
the timing constraints are forward-annotated in the Synopsys Constraints
Format (.scf) file.
Altera recommends that you use the TimeQuest Timing Analyzer for
Stratix III and Cyclone III devices, as specified in the Synplify Tcl file that
sets up the Quartus II project. However, you can continue to use the Tcl
commands for the Classic Timing Analyzer if required. You can manually
change from the TimeQuest Timing Analyzer to the Classic Timing
Analyzer in the Quartus II software by performing the following steps:
1.
From the Assignments menu, select Settings.
2.
Click Timing Analysis Settings.
3.
Under Timing analysis processing, click the Use Classic Timing
Analyzer during compilation radio button. Click OK.
1
For addition information about the TimeQuest Timing
Analyzer, refer to the Quartus II TimeQuest Timing Analyzer
chapter in the Quartus II Handbook.
Synplicity recommends that you modify constraints using the SCOPE
constraint editor window and not through the generated .sdc, .scf or .tcl
file.
The following list of Synplify constraints are converted to the equivalent
Quartus II SDC commands and are forward-annotated to the Quartus II
software in the .scf file:
■
7–20
define_clock
Altera Corporation
October 2007
Exporting Designs to the Quartus II Software Using NativeLink Integration
■
■
■
■
define_input_delay
define_output_delay
define_multicycle_path
define_false_path
All Synplify constraints described in the following sections use the same
Synplify commands as described in “Passing Constraints to the
Quartus II Software using Tcl Commands” on page 7–22; however, the
constraints are mapped to SDC commands for the TimeQuest Timing
Analyzer.
f
For the syntax and arguments for these commands, refer to the
applicable subsection or refer to the Synplify Help. For a list of
corresponding commands in the Quartus II software, refer to the
Quartus II Help.
Individual Clocks and Frequencies
You can specify clock frequencies for individuals clocks in Synplify
software with the command, define_clock. This command is passed
to Quartus II software with create_clock.
Input and Output Delay
You can specify input delay and output delay constraints in Synplify
software with the commands define_input_delay and
define_output_delay respectively. These commands are passed to
the Quartus II software with set_input_delay and
set_output_delay.
Multicycle Path
You can specify a multicycle path constraint in Synplify with the
command define_multicycle_path. This command is passed to the
Quartus II software with define_multicycle_path.
False Path
You can specify a false path constraint in Synplify software with the
command define_false_path. This command is passed to the
Quartus II software with set_false_path.
Altera Corporation
October 2007
7–21
Quartus II Handbook, Volume 1
Passing Constraints to the Quartus II Software using Tcl
Commands
This section describes how Synplify constraints are converted to the
equivalent Quartus II assignments and are forward-annotated to the
Quartus II software with Tcl commands.
This section discusses timing constraints for the Quartus II Classic
Timing Analyzer. If you are using the TimeQuest Timing Analyzer, the
Quartus II timing constraints described in this section do not apply. Refer
to “Passing TimeQuest SDC Timing Constraints to the Quartus II
Software in the .scf File” on page 7–20 for information about timing
constraints supported by TimeQuest.
Global Signals
The Synplify software automatically promotes clock signals to global
routing lines and passes Global Signal assignments to the Quartus II
software. The assignments ensure that the same global routing
constraints are applied during placement and routing.
1
The signals promoted to global routing can be different than the
ones that the Quartus II software promotes to global routing by
default. Synplify promotes only clock signals and not other
control signals such as reset or enable. By default, without
constraints from the Synplify software, the Quartus II software
promotes control signals to global routing if they have high fanout.
Default or Global Clock Frequency
Use the following Synplify command to set the Synplify default or global
clock frequency that applies to the entire project:
set_option -frequency <frequency>
The <frequency> is specified in MHz. If a global frequency is not specified,
the software uses the default global clock frequency of 1 MHz.
The set_option Synplify constraint is passed to the Quartus II software
with the following command:
set_global_assignment -name FMAX_REQUIREMENT
<frequency> MHz
If a frequency is not specified in the Quartus II software, the software uses
the default global clock frequency of 1 GHz.
7–22
Altera Corporation
October 2007
Exporting Designs to the Quartus II Software Using NativeLink Integration
Individual Clocks and Frequencies
You can specify clock frequencies for individual clocks with the following
Synplify commands:
Example 7–6. Specifying Clock Frequencies for Individual Clocks
define_clock -name {<clock_name>} -freq <frequency> -clockgroup <clock_group>
-rise <rise_time> -fall <fall_time>
define_clock -name {<clock_name>} -period <period> -clockgroup <clock_group>
-rise <rise_time> -fall <fall_time>
Table 7–3 shows the command arguments.
Table 7–3. Command Arguments
Argument
Description
-name
The <clock_name> specifies a design port name or a register output signal name, and, after
synthesis, corresponds to a <mapped_clock_name>.
-freq (1)
The <frequency> is specified in MHz.
-period (2)
The <period> is specified in ns.
-clockgroup
If the <clock_group> is not specified, it defaults to default_clkgroup. Synplify assumes all
clocks belonging to the same clock group are related. If you do not specify a clock group, the
clock belongs to the default clock group. Therefore, if you do not specify any clock groups, all
the clocks are considered related by default in the software.
-rise
-fall
The <rise_time> and <fall_time> specify a non-default duty cycle. By default, the Synplify
synthesis tool assumes that the clock is a 50% duty cycle clock, with the rising edge at 0 and
the falling edge at period/2. If you have another duty clock cycle, you can specify the
appropriate Rise At and Fall At values.
Notes to Table 7–3:
(1)
(2)
When the <frequency> is specified, the Synplify software uses <fall_time> and <frequency> to calculate the
duty_cycle with the following formula: duty_cycle = (<fall_time> – <rise_time>) × <frequency> ÷ 10.
When the <period> is specified, the Synplify software uses <fall_time> and <period> to calculate the duty_cycle
with the following formula: duty_cycle = 100 × (<fall_time> – <rise_time>) ÷ <period>.
The equivalent Quartus II Classic Timing Analyzer commands depend
on how the clock groups are defined. In the Quartus II software, clocks
that belong to the same or related clock settings are considered related
clocks. Clocks assigned to unrelated clock settings are unrelated clocks.
There is a one-to-one correspondence between each Quartus II clock
setting and a Synplify clock group.
1
Altera Corporation
October 2007
The following sections describe only the frequency constraints.
You can use the corresponding constraints for period.
7–23
Quartus II Handbook, Volume 1
Virtual Clocks
The Quartus II software supports virtual clocks. If you use the virtual
clock setting in Synplify, the setting is mapped to a constraint in the
Quartus II software.
Route Delay Option
The -route option in Synplify clock constraints is designed for use for
synthesis only if you do not meet timing goals because the routing delay
after placement and routing exceeds the delay predicted by the Synplify
software. This constraint does not have to be forward annotated to the
Quartus II software.
Multiple Clocks in Different Clock Groups
You can specify clock frequencies for multiple clocks with the Synplify
commands shown in Example 7–7.
Example 7–7. Specifying Clock Frequencies for Multiple Clocks
define_clock -name {<clock_name1>} -freq <frequency1> \
-clockgroup <clock_group1> -rise <rise_time1> -fall <fall_time1>
define_clock -name {<clock_name2>} -freq <frequency2> \
-clockgroup <clock_group2> -rise <rise_time2> -fall <fall_time2>
<clock_group1> and <clock_group2> are unique names defined in the
Synplify software for base clock settings in the Quartus II Classic Timing
Analyzer.
If the clock <rise_time> is zero (“0”), multiple separate clocks are passed
to the Quartus II software with the commands shown in Example 7–8:
Example 7–8. Quartus II Assignments for Multiple Clocks if the Clock Rise Time is Zero
create_base_clock -fmax <frequency1>MHz -duty_cycle <duty_cycle1> \
-target mapped_clock_name1 <base_clock_setting1>
create_base_clock -fmax <frequency2>MHz -duty_cycle <duty_cycle2> \
-target mapped_clock_name2 <base_clock_setting2>
7–24
Altera Corporation
October 2007
Exporting Designs to the Quartus II Software Using NativeLink Integration
If the clock <rise_time> is non-zero, multiple separate clocks are passed to
the Quartus II software with the following commands shown in
Example 7–9:
Example 7–9. Quartus II Assignments for Multiple Clocks if the Clock Rise Time is Not Zero
create_base_clock -fmax <frequency1>MHz -duty_cycle <duty cycle1> \
-no_target <base clock setting1>
create_base_clock -fmax <frequency2>MHz -duty_cycle <duty cycle2> \
-no_target <base clock setting2>
create_relative_clock -base_clock <base clock setting1> -offset <rise time1>ns \
-duty_cycle <duty cycle1> -multiply <multiply by> -divide <divide by> \
-target <mapped clock name1> <derived clock setting1>
create_relative_clock -base_clock <base clock setting2> -offset <rise time2>ns \
-duty_cycle <duty cycle2> -multiply <multiply by> -divide <divide by> \
-target <mapped clock name2> <derived clock_setting2>
Multiple Clocks with Different Frequencies in the Same Clock Group
You can specify multiple clocks with relative clock settings in the same
clock group in Synplify with different frequencies with the commands
shown in Example 7–10:
Example 7–10. Specifying Multiple Clocks with Different Frequencies in the Same Clock Group
define_clock -name {<clock_name1>} -freq <frequency1> -clockgroup <clock_group1> \
-rise <rise_time1> -fall <fall_time1>
define_clock -name {<clock_name2>} -freq <frequency2> -clockgroup <clock_group1> \
-rise <rise_time2> -fall <fall_time2>
1
Altera Corporation
October 2007
When you specify clocks with different frequencies in the same
clock group, the software calculates the <multiply_by> and the
<divide_by> factors for relative clock settings from <frequency1>
and <frequency2> in the clock group settings.
7–25
Quartus II Handbook, Volume 1
If the clock <rise_time> is zero, multiple clocks with relative clock settings
in the same clock group with different frequencies are passed to the
Quartus II software with the commands shown in Example 7–11:
Example 7–11. Quartus II Assignments for Multiple Clocks with Different Frequencies in the Same Clock
Group, if the Clock Rise Time is Zero
create_base_clock -fmax <frequency1>MHz -duty_cycle <duty_cycle1> \
-target <mapped_clock_name1> <base_clock_setting1>
create_relative_clock -base_clock <base_clock_setting1> \
-duty_cycle <duty_cycle2> -multiply <multiply_by> -divide <divide_by> \
-target <mapped_clock_name2> <derived_clock_setting2>
Inter-Clock Relationships—Delays and False Paths between Clocks
You can set a clock-to-clock delay constraint in Synplify with the
commands in Example 7–12.
Example 7–12. Specifying Clock-to-Clock Delay Constraints
define_clock_delay -fall <clock_name1> -rise
define_clock_delay -rise <clock_name1> -fall
define_clock_delay -rise <clock_name1> -rise
define_clock_delay -fall <clock_name1> -fall
<clock_name2>
<clock_name2>
<clock_name2>
<clock_name2>
<delay_value>
<delay_value>
<delay_value>
<delay_value>
If <delay_value> is set to false, these constraints in Synplify indicate a
false path between the two clocks. If all four rise/fall clock-edge pairs are
specified in the Synplify software, the Synplify constraints are mapped to
the following constraint in the Quartus II software:
set_timing_cut_assignment -from <clock_name1> \
-to <clock_name2>
If all four clock-edge pairs are not specified in Synplify, the constraint
cannot be mapped to a constraint for the Quartus II Classic Timing
Analyzer.
If <delay_value> is set to a value other than false, these constraints in
Synplify is not mapped to a constraint in the Quartus II software. The
Quartus II Classic Timing Analyzer does not support clock-edge to clockedge delay constraints.
7–26
Altera Corporation
October 2007
Exporting Designs to the Quartus II Software Using NativeLink Integration
False Paths
You can specify the false path constraint in Synplify with the following
command:
define_false_path -from <sig_name1> -to <sig_name2>
The signals <sig_name1> and <sig_name1> can be design port names or
register instance names.
The define_false_path constraint in Synplify is mapped to the constraint
in the Quartus II software, as shown below.
set_timing_cut_assignment -from <sig_name1> \
-to <sig_name2>
Synplify can identify pairs of signal sets such that every member of the
cross-product of these two sets is a valid false path constraint. Signal
groups can be defined in the Quartus II Classic Timing Analyzer with the
following commands:
timegroup -add_member sig_name1_i <sig_group1>
(for every signal in <sig_group1>)
timegroup -add_member sig_name2_i <sig_group2>
(for every signal in <sig_group2>)
set_timing_cut_assignment -from <sig_group1> \
-to <sig_group2>
If the signals <sig_name1> or <sig_name2> represent multiple signals such
as a wildcard, group, or bus, the constraints you can expand
appropriately for representation in the Quartus II software. The
Quartus II software supports wildcard signal names, and signal groups
for timing assignments. The Quartus II software does not support bus
notation, such as A[7:4].
Altera Corporation
October 2007
7–27
Quartus II Handbook, Volume 1
False Path from a Signal
You can specify a false path constraint from a signal in Synplify with the
following command:
define_false_path -from <sig_name>
The Quartus II Classic Timing Analyzer does not support “from-only”
path specifications. You must also include a “to-path” specification.
However, you can specify a wildcard for the -to signal. This constraint
in Synplify is mapped to the following constraint in the Quartus II
software:
set_timing_cut_assignment -from <sig_name> -to {*}
False Path to a Signal
You can specify a false path constraint to a signal in Synplify with the
following command:
define_false_path -to <sig_name>
The Quartus II Classic Timing Analyzer does not support to-only path
specifications. You must include a from-path specification.” However,
you can specify a wildcard for the -from signal. This constraint in
Synplify is mapped to the following constraint in the Quartus II software:
set_timing_cut_assignment -from {*} -to <sig_name>
False Path Through a Signal
You can specify a false path constraint through a signal in Synplify with
the following command:
define_false_path -from <sig_name1> -to <sig_name2> \
-through <sig_name3>
The Quartus II Classic Timing Analyzer does not support false paths with
a “through path” specification. Any constraint in Synplify with a
-through specification is not mapped to a constraint for the Quartus II
Classic Timing Analyzer.
Multicycle Paths
You can specify a multicycle path constraint in Synplify with the
following command:
define_multicycle_path -from <sig_name1> \
-to <sig_name2> <clock_cycles>
7–28
Altera Corporation
October 2007
Exporting Designs to the Quartus II Software Using NativeLink Integration
This constraint in Synplify is mapped to the following constraint in the
Quartus II software:
set_multicycle_assignment -from <sig_name1> \
-to <sig_name2> <clock_cycles>
If the signals <sig_name1> or <sig_name2> represent multiple signals such
as a wildcard, group, or bus, the constraints can be appropriately
expanded for representation in the Quartus II software as described in
“False Paths” on page 7–11.
1
<clock_cycles> is the number of clock cycles for the multicycle
path.
Multicycle Path from a Signal
You can specify a multicycle path constraint from a signal in Synplify
with the following command:
define_multicycle_path -from <sig_name> <clock_cycles>
This constraint is mapped using a wildcard for the -to value in the
Quartus II Classic Timing Analyzer, similar to the false path constraints:
set_multicycle_assignment -from <sig_name> \
-to {*} <clock_cycles>
Multicycle Path to a Signal
You can specify a multicycle path constraint to a signal in Synplify with
the following command:
define_multicycle_path -to <sig_name> <clock_cycles>
This constraint is mapped using a wildcard for the -from value in the
Quartus II Classic Timing Analyzer, similar to the false path constraints:
set_multicycle_assignment -from {*} <sig_name> \
<clock_cycles>
Multicycle Path Through a Signal
You can specify a multicycle path constraint through a signal in Synplify
using the following command:
define_multicycle_path -from <sig_name1> -to <sig_name2> \
-through <sig_name3> <clock_cycles>
Altera Corporation
October 2007
7–29
Quartus II Handbook, Volume 1
The Quartus II Classic Timing Analyzer does not support multicycle
paths with a “through path” specification. Any constraint in Synplify
with a -through specification is not mapped to a constraint for the
Quartus II Classic Timing Analyzer.
Maximum Path Delays
You can specify the maximum path delay relationships between signals
in Synplify with the following command:
define_path_delay -from <sig_name1> -to <sig_name2> \
-max <delay_value>
This constraint in Synplify is mapped to the following constraint in the
Quartus II software:
set_instance_assignment -from <sig_name1> \
-to <sig_name2> -name SETUP_RELATIONSHIP <delay_value>ns
The Quartus II Classic Timing Analyzer does not support signal groups
or bus notation, and supports only register names for this constraint.
Maximum Path Delay from a Signal
You can specify the maximum path delay constraint from a signal in
Synplify with the following command:
define_path_delay -from <sig_name> -max <delay_value>
This constraint is mapped using a wildcard for the -to value in the
Quartus II Classic Timing Analyzer, similar to false path constraints:
set_instance_assignment -from <sig_name> -to {*} \
-name SETUP_RELATIONSHIP <delay_value>ns
Maximum Path Delay to a Signal
You can specify the maximum path delay constraint to a signal in
Synplify with the following command:
define_path_delay -to <sig_name> -max <delay_value>
This constraint is mapped using a wildcard for the -from value in the
Quartus II Classic Timing Analyzer, similar to the false path constraints.
set_instance_assignment -from {*}<sig_name> \
-to <sig_name> -name SETUP_RELATIONSHIP <delay_value>ns
7–30
Altera Corporation
October 2007
Exporting Designs to the Quartus II Software Using NativeLink Integration
Maximum Path Delay through a Signal
You can specify the maximum path delay constraint through a signal in
Synplify with the following command:
define_path_delay -from <sig_name1> -to <sig_name2> \
-through <sig_name3> -max <delay_value>
The Quartus II Classic Timing Analyzer does not support maximum path
delay constraints with a “through path” specification. Any constraint in
Synplify with a -through specification is not mapped to a constraint for
the Quartus II Classic Timing Analyzer.
Register Input and Output Delays
These register input delay and register output delay constraints in
Synplify are for use in synthesis only, and therefore are not
forward-annotated to the Quartus II software.
Default External Input Delay
You can specify the default input delay constraint in Synplify with the
following command:
define_input_delay -default <delay_value>
This constraint is mapped to the following constraint in the Quartus II
software:
set_input_delay -clock {*} <delay_value> {*}
Port-Specific External Input Delay
You can specify a port-specific input delay constraint in Synplify with the
following command:
define_input_delay <input_port_name> <delay_value> \
-ref <clock_name>:<clock_edge>
The <clock_edge> can be set to r (rising edge) or f (falling edge).
When the clock edge is r (rising edge), this constraint is mapped to the
following constraint in the Quartus II software:
set_input_delay -clock <clock_name> <delay_value> \
<input_port_name>
When the clock_edge is f (falling edge), this constraint is not mapped to
a constraint in the Quartus II software. The Quartus II Classic Timing
Analyzer does not support the specification of input delays with respect
to the falling edge of the clock.
Altera Corporation
October 2007
7–31
Quartus II Handbook, Volume 1
Default External Output Delay
You can specify the default output delay constraint in Synplify with the
following command:
define_output_delay -default <delay_value>
This constraint is mapped to the following constraint in the Quartus II
software:
set_output_delay -clock {*} <delay_value> {*}
Port-Specific External Output Delay
You can specify a port-specific input delay constraint in Synplify with the
following command:
define_output_delay <output_port_name> <delay_value> \
-ref <clock_name>:<clock_edge>
The <clock_edge> can be set to r (rising edge) or f (falling edge). When the
clock edge is r (rising edge), this constraint is mapped to the following
constraint in the Quartus II software:
set_output_delay -clock <clock_name> <delay_value> \
<output_port_name>
When the clock_edge is f (falling edge), this constraint is not mapped to
a constraint in the Quartus II software. The Quartus II Classic Timing
Analyzer does not support the specification of output delays with respect
to the falling edge of the clock.
Guidelines for
Altera
Megafunctions
and
ArchitectureSpecific
Features
7–32
Altera provides parameterizable megafunctions including the LPMs,
device-specific Altera megafunctions, IP available as Altera MegaCore®
functions, and IP available through the Altera Megafunction Partners
Program (AMPPSM). You can use megafunctions by instantiating them in
your HDL code or inferring them from generic HDL code.
If you want to instantiate a megafunction in your HDL code, you can do
so with the MegaWizard Plug-In Manager to parameterize the function or
instantiating the function using the port and parameter definition. The
MegaWizard Plug-In Manager provides a graphical interface within the
Quartus II software for customizing and parameterizing any available
megafunction for the design. “Instantiating Altera Megafunctions Using
the MegaWizard Plug-In Manager” on page 7–33 describes the
MegaWizard Plug-In Manager flow with the Synplify software.
Altera Corporation
October 2007
Guidelines for Altera Megafunctions and Architecture-Specific Features
f
For more information about specific Altera megafunctions, refer to the
Quartus II Help. For more information about IP functions, refer to the
appropriate IP documentation.
The Synplify software also automatically recognizes certain types of HDL
code and infers the appropriate megafunction when a megafunction
provides optimal results. The Synplify software provides options to
control inference of certain types of megafunctions, as described in
“Inferring Altera Megafunctions from HDL Code” on page 7–37.
f
For a detailed discussion about instantiating versus inferring
megafunctions, refer to the Recommended HDL Coding Styles chapter in
volume 1 of the Quartus II Handbook. The Recommended HDL Coding
Styles chapter also provides details on using the MegaWizard Plug-In
Manager in the Quartus II software and explains the files generated by
the wizard, as well as providing coding style recommendations and
HDL examples for inferring megafunctions in Altera devices.
Instantiating Altera Megafunctions Using the MegaWizard
Plug-In Manager
When you use the MegaWizard Plug-In Manager to set up and
parameterize a megafunction, the MegaWizard Plug-In Manager creates
a VHDL or Verilog HDL wrapper file that instantiates the megafunction.
1
Beginning with the Quartus II software version 7.1, there is an
option in the MegaWizard Plug-In Manager to create a netlist
for area and timing estimation instead of a wrapper file. This
option is not supported with the Synplify software version 8.8,
therefore you must use the megafunction wrapper file as
described in this section.
Using the MegaWizard Plug-In Manager-generated wrapper file is
referred to as a black box methodology because the megafunction is
treated as a black box in the Synplify software. The black box
methodology does not allow the synthesis tool any visibility into the
function module and therefore does not take full advantage of the
synthesis tool’s timing-driven optimization. For better timing
optimization, especially if the black box does not have registered inputs
and outputs, add timing models to black boxes. Refer to “Other Synplify
Software Attributes for Creating Black Boxes” on page 7–36 for details.
Make sure to set the correct Quartus II version in the Synplify software
before compiling the Megawizard-generated file. The Quartus version
setting should match the version of the Quartus II software used to
generate the customized megafunction in the MegaWizard Plug-In
Manager.
Altera Corporation
October 2007
7–33
Quartus II Handbook, Volume 1
1.
On the Project menu, click Implementation Options.
2.
Click the Implementation Results tab, then click Quartus Version.
3.
Choose the correct version number in the list.
Alternately, use the following command from the command line:
set_option -quartus_version <version number> r
Using MegaWizard Plug-In Manager-Generated Verilog HDL Files for
Black Box Megafunction Instantiation
If you check the <output file>_inst.v and <output file>_bb.v options on the
last page of the wizard, the MegaWizard Plug-In Manager generates a
Verilog HDL instantiation template file and a hollow-body black box
module declaration for use in your Synplify design. The instantiation
template file helps to instantiate the megafunction variation wrapper file,
<output file>.v, in your top-level design. Do not include the megafunction
variation wrapper file in your Synplify Project, but add it, with your
Synplify-generated VQM netlist, to your Quartus II project. Add the
hollow-body black box module declaration <output file>_bb.v to your
Synplify project to describe the port connections of the black box.
1
The Synplify software reads black box instantiations for the
alt_pll megafunction and writes the phase-locked loop (PLL)
instance into the resulting VQM output netlist. Reading the PLL
function allows the Synplify software to interpret the
multiplication and division factors in the PLL instantiation to
make the correct timing assignments. Therefore, for alt_pll
instantiations, make sure to include the megafunction variation
wrapper file <output file>.v in your Synplify project and do not
declare it as a black box. Because the instance is written in the
VQM file, do not include the alt_pll megafunction variation
wrapper file <output file>.v in your Quartus II project.
You can use the syn_black_box compiler directive to declare a module
as a black box. The top-level design files must contain the megafunction
port mapping and hollow-body module declaration, as described above.
You can apply the syn_black_box directive to the module declaration
in the top-level file or a separate file included in the project (such as the
<output file>_bb.v file) to instruct the Synplify software that this is a black
box. The software compiles successfully without this directive, but
reports an additional warning message. Using this directive allows you
to add other directives as discussed in “Other Synplify Software
Attributes for Creating Black Boxes” on page 7–36.
7–34
Altera Corporation
October 2007
Guidelines for Altera Megafunctions and Architecture-Specific Features
Example 7–13 shows a sample top-level file that instantiates
verilogCount.v, which is a customized variation of the lpm_counter
generated by the MegaWizard Plug-In Manager.
Example 7–13. Top-Level Verilog HDL Code with Black Box Instantiation of lpm_counter
module topCounter (clk, count);
input clk;
output[7:0] count;
verilogCounter verilogCounter_inst (
.clock ( clk ),
.q ( count )
);
endmodule
// Module declaration found in verilogCounter_bb.v
// The following attribute is added to create a
// black box for this module.
module verilogCounter (
clock,
q) /* synthesis syn_black_box */;
input clock;
output[7:0] q;
endmodule
Using MegaWizard Plug-In Manager-Generated VHDL Files for Black Box
Megafunction Instantiation
If you check the <output file>.cmp and <output file>_inst.vhd options on
the last page of the wizard, the MegaWizard Plug-In Manager generates
a VHDL component declaration file and a VHDL instantiation template
file for use in your Synplify design. These files can help you instantiate
the megafunction variation wrapper file, <output file>.vhd, in your
top-level design. Do not include the megafunction variation wrapper file
in your Synplify project, but add it, along with your Synplify-generated
VQM netlist, to your Quartus II project.
1
Altera Corporation
October 2007
The Synplify software reads black box instantiations for the
alt_pll megafunction and writes the phase-locked loop (PLL)
instance into the resulting VQM output netlist. Reading the PLL
function allows the Synplify software to interpret the
multiplication and division factors in the PLL instantiation to
make the correct timing assignments. Therefore, for alt_pll
instantiations, make sure to include the megafunction variation
wrapper file <output file>.vhd in your Synplify project and do
not declare it as a black box. Because the instance is written in
the VQM file, do not include the alt_pll megafunction
variation wrapper file <output file>.vhd in your Quartus II
project.
7–35
Quartus II Handbook, Volume 1
You can use the syn_black_box compiler directive to declare a
component as a black box. The top-level design files must contain the
megafunction variation component declaration and port mapping, as
described above. Apply the syn_black_box directive to the component
declaration in the top-level file. The software compiles successfully
without this directive, but reports an additional warning message. Using
this directive allows you to add other directives such as the ones in the
“Other Synplify Software Attributes for Creating Black Boxes” section.
Example 7–14 shows a sample top-level file that instantiates
vhdlCount.vhd, which is a customized variation of the lpm_counter
generated by the MegaWizard Plug-In Manager.
Example 7–14. Top-Level VHDL Code with Black Box Instantiation of lpm_counter
LIBRARY ieee;
USE ieee.std_logic_1164.all;
ENTITY testCounter IS
PORT
(
clk: IN STD_LOGIC ;
count: OUT STD_LOGIC_VECTOR (7 DOWNTO 0)
);
END testCounter;
ARCHITECTURE top OF testCounter IS
component vhdlCount
PORT (
clock: IN STD_LOGIC ;
q: OUT STD_LOGIC_VECTOR (7 DOWNTO 0)
);
end component;
attribute syn_black_box : boolean;
attribute syn_black_box of vhdlCount: component is true;
BEGIN
vhdlCount_inst : vhdlCount PORT MAP (
clock => clk,
q => count
);
END top;
Other Synplify Software Attributes for Creating Black Boxes
The black box methodology does not allow the synthesis tool any
visibility into the function module. Thus, it does not take full advantage
of the synthesis tool’s timing-driven optimization. For better timing
optimization, especially if the black box does not have registered inputs
and outputs, add timing models to black boxes. This can be done by
adding the syn_tpd, syn_tsu, and syn_tco attributes. Refer to
Example 7–15 for a Verilog HDL example.
7–36
Altera Corporation
October 2007
Guidelines for Altera Megafunctions and Architecture-Specific Features
Example 7–15. Verilog HDL Example
module ram32x4(z,d,addr,we,clk);
/* synthesis syn_black_box syn_tco1="clk->z[3:0]=4.0"
syn_tpd1="addr[3:0]->z[3:0]=8.0"
syn_tsu1="addr[3:0]->clk=2.0"
syn_tsu2="we->clk=3.0" */
output[3:0]z;
input[3:0]d;
input[3:0]addr;
input we
input clk
endmodule
The following additional attributes are supported by the Synplify
software to communicate details about the characteristics of the black box
module within the HDL code:
■
■
■
f
syn_resources—Specifies the resources used in a particular black
box
black_box_pad_pin—Prevents mapping to I/O cells
black_box_tri_pin—Indicates a tri-stated signal
For more information about applying these attributes, refer to the Tasks
and Tips chapter of the Synplify User Guide.
Inferring Altera Megafunctions from HDL Code
The Synplify software uses Behavior Extraction Synthesis Technology
(BEST) algorithms to infer high-level structures such as RAMs, ROMs,
operators, FSMs, and so forth. It then keeps the structures abstract for as
long as possible in the synthesis process. This allows the use of
technology-specific resources to implement these structures by inferring
the appropriate Altera megafunction when a megafunction provides
optimal results. The following sections outline some of the
Synplify-specific details when inferring Altera megafunctions. The
Synplify software provides options to control inference of certain types of
megafunctions, which is also described in the following sections.
f
Altera Corporation
October 2007
For coding style recommendations and examples for inferring
megafunctions in Altera devices, refer to the Recommended HDL Coding
Styles chapter in volume 1 of the Quartus II Handbook.
7–37
Quartus II Handbook, Volume 1
Inferring Multipliers
Figure 7–2 shows the HDL Analyst view of an unsigned 8 × 8 multiplier
with two pipeline stages after synthesis as seen in HDL Analyst in the
Synplify software. This multiplier is converted into an lpm_mult
megafunction. For devices with DSP blocks, the software may implement
the lpm_mult function in a DSP block instead of regular logic,
depending on device utilization. For Stratix II and Stratix III devices, the
software maps directly to DSP block device atoms instead of instantiating
a megafunction in the .vqm file.
Figure 7–2. HDL Analyst View of lpm_mult Megafunction (Unsigned 8 × 8
Multiplier with Pipeline=2)
Resource Balancing
While mapping multipliers to DSP blocks, the Synplify software
performs resource balancing for optimum performance.
Altera devices have a fixed number of DSP blocks, which include a fixed
number of embedded multipliers. If the design uses more multipliers
than are available, the Synplify software automatically maps the extra
multipliers to logic elements (LEs), or adaptive logic modules (ALMs).
If a design uses more multipliers than are available in the DSP blocks, the
Synplify software maps the multipliers in the critical paths to DSP blocks.
Next, any wide multipliers, which may or may not be in the critical paths,
are mapped to DSP blocks. Smaller multipliers and multipliers that are
not in the critical paths may then be implemented in the logic (LEs or
ALMs). This ensures that the design fits successfully in the device.
Controlling the Inferring of DSP Blocks
Multipliers can be implemented in DSP blocks or in logic in Altera
devices that contain DSP blocks. You can control this implementation
through attribute settings in the Synplify software.
7–38
Altera Corporation
October 2007
Guidelines for Altera Megafunctions and Architecture-Specific Features
Signal Level Attribute
You can control the implementation of individual multipliers by using
the syn_multstyle attribute as shown below:
<signal_name> /* synthesis syn_multstyle = "logic" */
where signal_name is the name of the signal.
1
This setting applies to wires only; it cannot be applied to
registers.
Table 7–4 shows the values for the signal level attribute in the Synplify
software that controls the implementation of the multipliers in the DSP
blocks or LEs.
Table 7–4. Attribute Settings for DSP Blocks in the Synplify Software
Attribute Name
Value
Description
syn_multstyle
lpm_mult
LPM Function inferred and multipliers implemented in
DSP blocks
syn_multstyle
logic
LPM function not inferred and multipliers implemented
LEs by the Synplify software
syn_multstyle
block_mult
DSP megafunction is inferred and multipliers are
mapped directly to DSP block device atoms (for
supported devices)
Example 7–16 and Example 7–17 show simple Verilog HDL and VHDL
code using the syn_multstyle attribute.
Example 7–16. Signal Attributes for Controlling DSP Block Inference in Verilog HDL Code
module mult(a,b,c,r,en);
input [7:0] a,b;
output [15:0] r;
input [15:0] c;
input en;
wire [15:0] temp /* synthesis syn_multstyle="logic" */;
assign temp = a*b;
assign r = en ? temp : c;
endmodule
Altera Corporation
October 2007
7–39
Quartus II Handbook, Volume 1
Example 7–17. Signal Attributes for Controlling DSP Block Inference in VHDL Code
library ieee;
use ieee.std_logic_1164.all;
use ieee.std_logic_unsigned.all;
entity onereg is port (
r : out std_logic_vector(15 downto 0);
en : in std_logic;
a : in std_logic_vector(7 downto 0);
b : in std_logic_vector(7 downto 0);
c : in std_logic_vector(15 downto 0)
);
end onereg;
architecture beh of onereg is
signal temp : std_logic_vector(15 downto 0);
attribute syn_multstyle : string;
attribute syn_multstyle of temp : signal is "logic";
begin
temp <= a * b;
r <= temp when en='1' else c;
end beh;
Inferring RAM
When a RAM block is inferred from an HDL design, the software uses an
Altera megafunction to target the device memory architecture. For
Stratix II and Stratix III devices, the software maps directly to memory
block device atoms instead of instantiating a megafunction in the VQM
file.
Follow the guidelines below for the Synplify software to successfully
infer RAM in a design:
■
■
■
The address line must be at least two bits wide.
Resets on the memory are not supported. Refer to the device family
documentation for information about whether read and write ports
must be synchronous.
Some Verilog HDL statements with blocking assignments may not
be mapped to RAM blocks, so avoid blocking statements when
modeling RAMs in Verilog HDL.
For certain device families, the syn_ramstyle attribute specifies the
implementation to use for an inferred RAM. You can apply
syn_ramstyle globally, to a module, or to a RAM instance, to specify
registers or block_ram values. To turn off RAM inference, set the
attribute value to registers.
7–40
Altera Corporation
October 2007
Guidelines for Altera Megafunctions and Architecture-Specific Features
When inferring RAM for certain Altera device families, the Synplify
software generates additional bypass logic. This logic is generated to
resolve a half-cycle read/write behavior difference between the RTL and
post-synthesis simulations. The RTL simulation shows the memory being
updated on the positive edge of the clock, and the post-synthesis
simulation shows the memory being updated on the negative edge. To
eliminate the bypass logic, the output of the RAM must be registered. By
adding this register, the output of the RAM is seen after a full clock cycle,
by which time the update has occurred; thus, eliminating the need for the
bypass logic.
For devices with TriMatrix memory blocks, you can disable the creation
of glue logic by setting the syn_ramstyle value to no_rw_check. Use
syn_ramstyle with a value of no_rw_check to disable the creation of
glue logic in dual-port mode.
Example 7–18 shows sample VHDL code for inferring dual-port RAM.
Example 7–18. VHDL Code for Inferred Dual-Port RAM
LIBRARY ieee;
USE ieee.std_logic_1164.all;
USE ieee.std_logic_signed.all;
ENTITY dualport_ram IS
PORT ( data_out: OUT STD_LOGIC_VECTOR (7 DOWNTO 0);
data_in: IN STD_LOGIC_VECTOR (7 DOWNTO 0);
wr_addr, rd_addr: IN STD_LOGIC_VECTOR (6 DOWNTO 0);
we: IN STD_LOGIC;
clk: IN STD_LOGIC);
END dualport_ram;
ARCHITECTURE ram_infer OF dualport_ram IS
TYPE Mem_Type IS ARRAY (127 DOWNTO 0) OF STD_LOGIC_VECTOR (7 DOWNTO 0);
SIGNAL mem: Mem_Type;
SIGNAL addr_reg: STD_LOGIC_VECTOR (6 DOWNTO 0);
BEGIN
data_out <= mem (CONV_INTEGER(rd_addr));
PROCESS (clk, we, data_in) BEGIN
IF (clk='1' AND clk'EVENT) THEN
IF (we='1') THEN
mem(CONV_INTEGER(wr_addr)) <= data_in;
END IF;
END IF;
END PROCESS;
END ram_infer;
Altera Corporation
October 2007
7–41
Quartus II Handbook, Volume 1
Example 7–19 shows an example of the VHDL code preventing bypass
logic for inferring dual-port RAM. The extra latency behavior stems from
the inferring methodology and is not required when instantiating a
megafunction.
Example 7–19. VHDL Code for Inferred Dual-Port RAM Preventing Bypass Logic
LIBRARY ieee;
USE ieee.std_logic_1164.all;
USE ieee.std_logic_signed.all;
ENTITY dualport_ram IS
PORT ( data_out: OUT STD_LOGIC_VECTOR (7 DOWNTO 0);
data_in : IN STD_LOGIC_VECTOR (7 DOWNTO 0);
wr_addr, rd_addr : IN STD_LOGIC_VECTOR (6 DOWNTO 0);
we : IN STD_LOGIC;
clk : IN STD_LOGIC);
END dualport_ram;
ARCHITECTURE ram_infer OF dualport_ram IS
TYPE Mem_Type IS ARRAY (127 DOWNTO 0) OF STD_LOGIC_VECTOR (7 DOWNTO 0);
SIGNAL mem : Mem_Type;
SIGNAL addr_reg : STD_LOGIC_VECTOR (6 DOWNTO 0);
SIGNAL tmp_out : STD_LOGIC_VECTOR(7 DOWNTO 0); --output register
BEGIN
tmp_out <= mem (CONV_INTEGER(rd_addr));
PROCESS (clk, we, data_in) BEGIN
IF (clk='1' AND clk'EVENT) THEN
IF (we='1') THEN
mem(CONV_INTEGER(wr_addr)) <= data_in;
END IF;
data_out <= tmp_out; --registers output preventing
-- bypass logic generation.
END IF;
END PROCESS;
END ram_infer;
RAM Initialization
You can use Verilog system tasks $readmemb or $readmemh in your
HDL code to initialize RAM memories. The Synplify compiler
forward-annotates the initialization values in the .srs
(technology-independent RTL netlist) file and the mapper generates a
corresponding hexadecimal memory initialization (.hex) file. One HEX
file is created for each of the altsyncram megafunctions that are
inferred in the design. The HEX file is associated with the altsyncram
instance in the .vqm file using the init_file attribute.
7–42
Altera Corporation
October 2007
Guidelines for Altera Megafunctions and Architecture-Specific Features
Example 7–20 and Example 7–21 illustrate how RAM memories can be
initialized through HDL code, and how the corresponding HEX file is
generated using Verilog HDL.
Example 7–20. Using $readmemb System Task to Initialize an Inferred RAM in Verilog HDL Code
initial
begin
$readmemb("mem.ini", mem);
end
always @(posedge clk)
begin
raddr_reg <= raddr;
if(we)
begin
mem[waddr] <= data;
end
end
Example 7–21. Sample VQM Instance Containing Memory Initialization File from Example 7–20
altsyncram mem_hex( .wren_a(we), .wren_b(GND),...);
defparam mem_hex.lpm_type = "altsyncram";
defparam mem_hex.operation_mode = "Dual_Port";
...
defparam mem_hex.init_file = "mem_hex.hex";
Inferring ROM
When a ROM block is inferred from an HDL design, the software uses an
Altera megafunction to target the device memory architecture. For
Stratix II and Stratix III devices, the software maps directly to memory
block device atoms instead of instantiating a megafunction in the VQM
file. Follow the guidelines below for the Synplify software to successfully
infer ROM in a design:
■
■
■
The address line must be at least two bits wide.
ROM must be at least half full.
A CASE or IF statement must make 16 or more assignments using
constant values of the same width.
Inferring Shift Registers
The software infers shift registers for sequential shift components so that
they can be placed in dedicated memory blocks in supported device
architectures using the altshift_taps megafunction.
Altera Corporation
October 2007
7–43
Quartus II Handbook, Volume 1
If required, set the implementation style with the syn_srlstyle
attribute. If you do not want the components automatically mapped to
shift registers, set the value to registers. You can set the value globally
or on individual modules or registers.
For some designs, turning off shift register inference can improve the
design performance.
Incremental
Compilation and
Block-Based
Design
As designs become more complex and designers work in teams, a
block-based hierarchical or incremental design flow is often an effective
design approach. In an incremental compilation flow, you can make
changes to part of the design while maintaining the placement and
performance of unchanged parts of the design. Design iterations are
made dramatically faster by focusing new compilations on a particular
design partitions and merging results with previous compilation results
of other partitions. In a bottom-up or team-based approach, you can
perform optimization on individual subblocks and then preserve the
results before you integrate the blocks into a final design and optimize it
at the top level.
MultiPoint synthesis, which is available for certain device technologies in
the Synplify Pro software, provides an automated block-based
incremental synthesis flow. The MultiPoint feature manages a design
hierarchy to let you design incrementally and synthesize designs that
take too long for top-down synthesis of the entire project. MultiPoint
synthesis allows different netlist files to be created for different sections
of a design hierarchy, and supports Quartus II incremental compilation
and LogicLock design methodologies. It also ensures that only those
sections of a design that have been updated are resynthesized when the
design is compiled, reducing synthesis run time and preserving the
results for the unchanged blocks. You can change and resynthesize one
section of a design without affecting other sections of the design.
You can also partition your design and create different netlist files
manually with the Synplify software (basic Synplify and Synplify Pro) by
creating a separate project for the logic in each partition of the design.
Creating different netlist files for each partition of the design means that
each partition is independent of the others. When synthesizing the entire
project, only portions of a design that have been updated have to be
resynthesized when you compile the design. You can make changes and
resynthesize one partition of a design to create a new netlist file without
affecting the synthesis results and placement of other partitions.
Hierarchical design methodologies can improve the efficiency of your
design process, providing better design reuse opportunities and fewer
integration problems when working in a team environment. When you
use these incremental synthesis methodologies, you can take advantage
7–44
Altera Corporation
October 2007
Incremental Compilation and Block-Based Design
of the incremental compilation and methodologies in the Quartus II
software. You can perform placement and routing on only the changed
partitions of the design, reducing place-and-route time and preserving
your fitting results. Following the guidelines in this section can help you
achieve good results with these methodologies.
The following list shows the general top-down compilation flow when
using these features of the Quartus II software:
f
Altera Corporation
October 2007
1.
Create Verilog HDL or VHDL design files as in the regular design
flow.
2.
Determine which hierarchical blocks are to be treated as separate
partitions in your design.
3.
Set up your design using the MultiPoint feature or separate projects
so that a separate netlist file is created for each partition of the
design.
4.
If using separate projects, disable I/O pad insertion in the
implementations for lower-level partitions.
5.
Compile and technology-map each partition in the Synplify Pro or
Synplify software, making constraints as you would in the regular
design flow.
6.
Import the VQM or EDIF netlist and the Tcl file for each partition
into the Quartus II software and set up the Quartus II project(s) to
use incremental compilation.
7.
Compile your design in the Quartus II software and preserve the
compilation results using the post-fit netlist in incremental
compilation.
8.
When you make design or synthesis optimization changes to part of
your design, resynthesize only the changed partition to generate a
new netlist and Tcl file. Do not regenerate netlist files for the
unchanged partitions.
9.
Import the new netlist and Tcl file into the Quartus II software and
recompile the design in the Quartus II software using incremental
compilation.
For more information about creating partitions and using the
incremental compilation in the Quartus II software, refer to the
Quartus II Incremental Compilation for Hierarchical and Team-Based Design
chapter in volume 1 of the Quartus II Handbook.
7–45
Quartus II Handbook, Volume 1
Hierarchy and Design Considerations with Multiple VQM Files
To ensure the proper functioning of the synthesis flow, you can create
separate netlist files only for modules and entities. In addition, each
module or entity should have its own design file. If two different modules
are in the same design file but are defined as being part of different
partitions, you cannot maintain incremental compilation since both
partitions would have to be recompiled when you change one of the
modules.
Altera recommends that you register all inputs and outputs of each
partition. This makes logic synchronous and avoids any delay penalty on
signals that cross partition boundaries.
If you use boundary tri-states in a lower-level block, the Synplify
software pushes (or “bubbles”) the tri-states through the hierarchy to the
top level to make use of the tri-state drivers on output pins of Altera
devices. Because bubbling tri-states requires optimizing through
hierarchies, lower-level tri-states are not supported with a block-based
compilation methodology. You should use tri-state drivers only at the
external output pins of the device and in the top-level block in the
hierarchy.
Creating a Design with Separate Netlist Files
The first stage of a hierarchical or incremental design flow is to ensure
that different parts of your design do not affect each other. Ensure that
you have separate netlists for each partition in your design so that you
can take advantage of incremental compilation in the Quartus II software.
If the entire design is in one netlist file, changes in one partition may affect
other partitions because of possible node name changes when you
resynthesize the design.
You can generate multiple VQM files either by using the MultiPoint
synthesis flow and LogicLock attributes in the Synplify Pro software, or
by manually creating separate Synplify projects and creating a black box
for each block that you want to be considered as a separate design
partition.
In the MultiPoint synthesis flow (Synplify Pro only), you create multiple
VQMs from one easy-to-manage, top-level synthesis project. By using the
manual black box method (Synplify or Synplify Pro), you have multiple
synthesis projects, which may be required for certain team-based or
bottom-up designs where a single top-level project is not desired.
7–46
Altera Corporation
October 2007
Incremental Compilation and Block-Based Design
Once you have created multiple VQM files using one of these two
methods, you must create the appropriate Quartus II projects to
place-and-route the design.
Creating a Design with Multiple VQM Files Using Synplify Pro
MultiPoint Synthesis
This section describes how to generate multiple VQM files using the
Synplify Pro MultiPoint synthesis flow. You must first set up your
compile points, constraint files, and Synplify Pro options, then apply
Altera-specific attributes to write multiple VQM files and create
LogicLock region assignments.
Set Compile Points and Create Constraint Files
The MultiPoint flow lets you segment a design into smaller synthesis
units, called “Compile Points.” The synthesis software treats each
Compile Point as a partition for incremental mapping, which allows you
to isolate and work on individual Compile Point modules as independent
segments of the larger design without impacting other design modules.
A design can have any number of Compile Points, and Compile Points
can be nested. The top-level module is always treated as a Compile Point.
Compile Points are optimized in isolation from their parent, which can be
another Compile Point or a top-level design. Each block created with a
Compile Point is unaffected by critical paths or constraints on its parent
or other blocks. A Compile Point is independent, with its own individual
constraints. During synthesis, any Compile Points that have not yet been
synthesized are synthesized before the top level. Nested Compile Points
are synthesized before the parent Compile Points in which they are
contained. When you apply the appropriate Synplify Pro LogicLock
constraints to a Compile Point module, then a separate netlist is created
for that Compile Point, isolating that logic from any other logic in the
design.
Figure 7–3 on page 7–48 shows an example of a design hierarchy that can
be split into multiple partitions. The top-level block of each partition can
be synthesized as a separate Compile Point.
Altera Corporation
October 2007
7–47
Quartus II Handbook, Volume 1
Figure 7–3. Partitions in a Hierarchical Design
Partition Top
A
B
D
Partition B
C
E
F
Partition F
In this case, modules A, B, and F are Compile Points. The top-level
Compile Point consists of the top-level block in the design (that is, block
A in this example), including the logic that is not defined under another
Compile Point. In this example, the design for top-level Compile Point A
also includes the logic in one of its subblocks, C. Because block F is
defined as its own Compile Point, it is not treated as part of the top-level
Compile Point A. Another separate Compile Point B contains the logic in
blocks B, D, and E. One netlist is created for the top-level module A and
submodule C, another netlist is created for B and its submodules D and
E, while a third netlist is created for F.
Apply Compile Points to the module or architecture in the Synplify Pro
SCOPE spreadsheet or in the .sdc file. You cannot set a Compile Point in
the Verilog HDL or VHDL source code. You can set the constraints
manually using Tcl or by editing the .sdc file. You can also use the GUI
which provides two methods, manual or automated, as shown below.
Defining Compile Points Using Tcl or SDC
To set Compile Points using Tcl or an .sdc file, use the
define_compile_point command, as shown in Example 7–22.
Example 7–22. The define_compile_point Command
define_compile_point [-disable] [-comment <comment>] <objname> \
[-type <compile point type>]
In the syntax statement above, objname represents any module in the
design. Currently, locked is the only Compile Point type supported.
7–48
Altera Corporation
October 2007
Incremental Compilation and Block-Based Design
Each Compile Point has a set of constraint files that begin with the
define_current_design command to set up the SCOPE
environment, as shown below.
define_current_design {<my_module>}
Manually Defining Compile Points from the GUI
The manual method requires you to separately create constraint files for
the top-level and the lower-level Compile Points. To use the manual
method:
1.
From the top level, select the Compile Points tab in the SCOPE
spreadsheet.
2.
Select the modules that you want to define as Compile Points.
Currently, locked Compile Points are the only type supported. All
Compile Points must be defined from the top level because the
Compile Points tab is not available in the SCOPE spreadsheet from
lower level modules.
3.
Manually create a constraint file for each module.
To ensure that changes to a Compile Point do not affect the top-level
parent module, disable the Update Compile Point Timing Data option
on the Implementation Options dialog box. If this option is enabled,
updates to a child module can impact the top-level module.
Automatically Defining Compile Points from the GUI
When you use the automated process, the lower-level constraint file is
created automatically. This eliminates the manual step necessary to set up
each Compile Point. To use the automated method, perform the
following steps:
Altera Corporation
October 2007
1.
On the File menu, select New. Click to create a new Constraint File,
or click the SCOPE icon in the tool bar.
2.
From the Select File Type tab of the Create a New SCOPE File
dialog box, select Compile Point.
3.
Select the module you want to designate as a Compile Point. The
software automatically sets the Compile Points in the top-level
constraint file and creates a lower-level constraint file for each
Compile Point.
7–49
Quartus II Handbook, Volume 1
To ensure that changes to a Compile Point do not affect the top-level
parent module, disable the Update Compile Point Timing Data option
on the Implementation Options dialog box. If this option is enabled,
updates to a child module can impact the top-level module.
When using Compile Points with incremental compilation, keep the
following restrictions in mind:
■
■
■
f
To use Compile Points effectively, you must provide timing
constraints (timing budgeting) for each Compile Point; the more
accurate the constraints, the better your results are. Constraints are
not automatically budgeted, so manual time budgeting is essential.
Altera recommends that you register all inputs and outputs of each
partition. This avoids any logic delay penalty on signals that cross
partition boundaries.
When using the Synplify Pro attribute syn_useioff to pack
registers in the I/O Elements (IOEs) of Altera devices, these registers
must be in the top-level module, not a lower level. Otherwise, you
must allow the Quartus II software to perform I/O register packing
instead of the syn_useioff attribute. You can use the Fast Input
Register or Fast Output Register options, or set I/O timing
constraints and turn on Optimize I/O cell register placement for
timing on the Fitter Settings page of the Settings dialog box in the
Quartus II software.
There is no incremental synthesis support for top-level logic; any
logic in the top-level is resynthesized during every compilation in
the Synplify Pro software.
For more information about Compile Points, refer to the Synplify Pro
User Guide and Reference Manual on the Synplicity web site at
www.synplicity.com.
Apply the LogicLock Attributes
To instruct the Synplify Pro software to create a separate VQM netlist file
for each Compile Point, you must indicate that the Compile Point is being
used with LogicLock regions in the incremental compilation or
LogicLock design methodology. Because separate netlist files are
required for incremental compilation, you must use the LogicLock
attributes if you plan to use the incremental compilation feature in the
Quartus II software. When you apply the appropriate LogicLock
attributes, the Synplify Pro software also writes out Tcl commands for the
Quartus II software to create a LogicLock region for each netlist.
LogicLock regions in the Quartus II software have size and location
properties. The region’s size is defined by the height and width of the
rectangular area. If the region is specified as auto-size, then the Quartus II
7–50
Altera Corporation
October 2007
Incremental Compilation and Block-Based Design
software determines the appropriate size to fit the logic assigned to the
region. When you specify the size, you must include enough device
resources to accommodate the assigned logic. The location of a region is
defined by its origin, which is the position of its bottom-left corner or
top-left corner, depending on the target device family. In the Quartus II
software, this location can be specified as “locked” or “floating.” If the
location is floating, the Quartus II software determines the location
during its optimization process.
1
Floating locations are the only type currently supported in the
Synplify Pro software.
When you use incremental compilation in the Quartus II software, you
should lock down the size and location of the region in the Quartus II
software after the first compilation to achieve the best quality of results.
Table 7–5 shows the valid combinations of the LogicLock attributes.
Table 7–5. LogicLock Location and Size Properties
altera_logiclock_location altera_logiclock_size
Attribute
Attribute
Description
Floating
Auto
The most flexible type of LogicLock constraint. Allows the
Quartus II software to choose the appropriate region size
and location.
Floating
Fixed
Assumes the size of LogicLock constraint area is already
optimal in the existing Quartus II project.
You can apply these attributes to the top-level constraint file or to the
individual constraint files for each lower-level Compile Point. You can
use the Attribute tab of the SCOPE spreadsheet to set attributes.
Synplify Pro offers another attribute, syn_allowed_resources, which
restricts the number of resources for a given module. You can apply the
syn_allowed_resources attribute to any Compile Point view.
f
For specific information about these attributes, refer to the Synplify Pro
online help or reference manual.
Creating a Quartus II Project for Multiple VQM Files
During compilation, the Synplify Pro software creates a <top-level
project>.tcl file that provides the Quartus II software with the appropriate
constraints and LogicLock assignments, creating a region for each VQM
file along with the information to set up a Quartus II project.
Altera Corporation
October 2007
7–51
Quartus II Handbook, Volume 1
The Tcl file contains the following commands for each LogicLock region.
Example 7–23 is for module A (instance u1) in the project named top
where the region name cpll_1 was selected by Synplify Pro for the
Compile Point.
Example 7–23. Commands for Each LogicLock Region in a Tcl File
set_global_assignment -section_id{taps_region} -name{LL_AUTO_SIZE}{ON}
set_global_assignment -section_id{taps_region} -name{LL_STATE}{FLOATING}
set_instance_assignment -section_id{taps_region} -to{|taps:u1} \
-name{LL_MEMBER_OF} {taps_region}
These commands create a LogicLock region with auto size and floating
origin properties. This flexible LogicLock region allows the Quartus II
Compiler to select the size and location of the region.
f
For more information about Tcl commands, refer to the Tcl Scripting
chapter in volume 2 of the Quartus II Handbook.
Depending on your design methodology, you can create one Quartus II
project for all netlists (a top-down placement and routing flow) or a
separate Quartus II project for each netlist (a bottom-up placement and
routing flow). In a top-down incremental compilation design flow, you
create design partition assignments and LogicLock floorplan location
assignments for each partition in the design within a single Quartus II
project. This methodology allows for the best quality of results and
performance preservation during incremental changes to your design.
You may require a bottom-up design flow if each partition must be
optimized separately, such as in certain team-based design flows. To
perform a bottom-up compilation in the Quartus II software, create
separate Quartus II projects and import each design partition into a
top-level design using the incremental compilation export and import
features to maintain placement results.
The following sections describe how to create the Quartus II projects for
these two design flows.
Creating a Single Quartus II Project for a Top-Down Incremental
Compilation Flow
Use the <top-level project>.tcl file that contains the Synplify Pro
assignments for all partitions within the project. This method allows you
to import all the partitions into one Quartus II project and optimize all
modules within the project at once, taking advantage of the performance
preservation and compilation-time reduction incremental compilation
offers. Figure 7–4 shows a visual representation of the design flow for the
example design in Figure 7–3.
7–52
Altera Corporation
October 2007
Incremental Compilation and Block-Based Design
Figure 7–4. Design Flow Using Multiple VQM Files with One Quartus II Project
Creating Multiple Quartus II Projects for a Bottom-Up LogicLock
Design Flow
Generate multiple Quartus II projects, one for each partition and netlist in
the design. Each designer in the project can optimize their partition
separately within the Quartus II software and export the placement for
their partitions. Figure 7–5 shows a visual representation of the design
flow for the example design in Figure 7–3. The optimized sub-designs can
be brought into one top-level Quartus II project using incremental
compilation.
Figure 7–5. Design Flow Using Multiple VQM Files with Multiple Quartus II Projects
Quartus II Project
a.vqm
Quartus II Project
Use b.tcl to Import
Synplify Pro
Assignments
Altera Corporation
October 2007
Use a.tcl to Import
Synplify Pro Assignments
Quartus II Project
b.vqm
f.vqm
Use f.tcl to Import
Synplify Pro
Assignments
7–53
Quartus II Handbook, Volume 1
Generating a Design with Multiple VQM Files Using Black Boxes
This section describes how to manually generate multiple VQM files
using black boxes. This manual flow is supported in versions of the
Synplify software that do not include the MultiPoint Synthesis feature.
Manually Creating Multiple VQM Files Using Black Boxes
To create multiple VQM files manually in the Synplify software, create a
separate project for each low-level module and the top-level design that
you want to maintain as a separate VQM file. Implement black box
instantiations of lower-level partitions in your top-level project.
When synthesizing the projects for the lower-level modules, perform the
following steps:
1.
In the Implementation Options dialog box, turn on Disable I/O
Insertion for the target technology.
2.
Read the HDL files for the modules.
1
Modules may include black box instantiations of
lower-level modules that are also maintained as separate
VQM files.
3.
Add constraints with the SCOPE constraint window.
4.
Enter the clock frequency to ensure that the sub-design is correctly
optimized.
5.
In the Attributes tab, set syn_netlist_hierarchy to 0.
When synthesizing the top-level design project, perform the following
steps:
7–54
1.
Turn off Disable I/O Insertion for the target technology.
2.
Read the HDL files for top-level designs.
3.
Create black boxes using lower-level modules in the top-level
design.
4.
Add constraints with the SCOPE constraint window.
5.
Enter the clock frequency to ensure that the design is correctly
optimized.
Altera Corporation
October 2007
Incremental Compilation and Block-Based Design
6.
In the Attributes tab, set syn_netlist_hierarchy to 0.
The following sections describe an example of black box implementation
to create separate VQM files. Figure 7–3 for an example of a design
hierarchy that is split into multiple partitions.
Figure 7–6. Partitions in a Hierarchical Design
Partition Top
A
B
D
C
E
Partition B
F
Partition F
In Figure 7–3, the partition top contains the top-level block in the design
(block A) and the logic that is not defined as part of another partition. In
this example, the partition for top-level block A also includes the logic in
one of its sub-blocks, C. Because block F is contained in its own partition,
it is not treated as part of the top-level partition A. Another separate
partition, B, contains the logic in blocks B, D, and E. In a team-based
design, different engineers may work on the logic in different partitions.
One netlist is created for the top-level module A and its submodule C,
another netlist is created for B and its submodules D and E, while a third
netlist is created for F. To create multiple VQM files for this design, follow
these steps:
Altera Corporation
October 2007
1.
Generate a VQM file for module B. Use B.v/.vhd, D.v/.vhd, and
E.v/.vhd as the source files.
2.
Generate a VQM file for module F. Use F.v/.vhd as the source files.
3.
Generate a top-level VQM file for module A. Use A.v/.vhd and
C.v/.vhd as the source files. Ensure that you use black box modules
B and F, which were optimized separately in the previous steps.
7–55
Quartus II Handbook, Volume 1
Creating Black Boxes in Verilog HDL
Any design block that is not defined in the project or included in the list
of files to be read for a project are treated as a black box by the software.
Use the syn_black_box attribute to indicate that you intend to create a
black box for the given module. In Verilog HDL, you must provide an
empty module declaration for the module that is treated as a black box.
Example 7–24 shows an example of the A.v top-level file. Follow the same
procedure below for lower-level files which also contain a black box for
any module beneath the current level hierarchy.
Example 7–24. Verilog HDL Black Box for Top-Level File A.v
module A (data_in, clk, e, ld, data_out);
input data_in, clk, e, ld;
output [15:0] data_out;
wire [15:0] cnt_out;
B U1 (.data_in (data_in),.clk(clk), .ld (ld),.data_out(cnt_out));
F U2 (.d(cnt_out), .clk(clk), .e(e), .q(data_out));
// Any other code in A.v goes here.
endmodule
// Empty Module Declarations of Sub-Blocks B and F follow here.
// These module declarations (including ports) are required for black
boxes.
module B (data_in, clk, ld, data_out) /* synthesis syn_black_box */ ;
input data_in, clk, ld;
output [15:0] data_out;
endmodule
module F (d, clk, e, q) / *synthesis syn_black_box */ ;
input [15:0] d;
input clk, e;
output [15:0] q;
endmodule
7–56
Altera Corporation
October 2007
Incremental Compilation and Block-Based Design
Creating Black Boxes in VHDL
Any design block that is not defined in the project or included in the list
of files to be read for a project are treated as a black box by the software.
Use the syn_black_box attribute to indicate that you intend to treat the
given component as a black box. In VHDL, you need a component
declaration for the black box just like any other block in the design.
1
Although VHDL is not case-sensitive, VQM (a subset of
Verilog HDL) is case-sensitive. Entity names and their port
declarations are forwarded to the VQM. Black box names and
port declarations are also passed to the VQM. To prevent
case-based mismatches between VQM, use the same
capitalization for black box and entity declarations in VHDL
designs.
Example 7–25 shows an example of the A.vhd top-level file. Follow this
same procedure for any lower-level files that contain a black box for any
block beneath the current level of hierarchy.
Example 7–25. VHDL Black Box for Top-Level File A.vhd
LIBRARY ieee;
USE ieee.std_logic_1164.all;
LIBRARY synplify;
use synplify.attributes.all;
ENTITY A IS
PORT ( data_in : IN INTEGER RANGE 0 TO 15;
clk, e, ld : IN STD_LOGIC;
data_out : OUT INTEGER RANGE 0 TO 15 );
END A;
ARCHITECTURE a_arch OF A IS
COMPONENT B PORT(
data_in : IN INTEGER RANGE 0 TO 15;
clk, ld : IN STD_LOGIC;
d_out : OUT INTEGER RANGE 0 TO 15 );
END COMPONENT;
COMPONENT F PORT(
d : IN INTEGER RANGE 0 TO 15;
clk, e: IN STD_LOGIC;
q : OUT INTEGER RANGE 0 TO 15 );
END COMPONENT;
attribute syn_black_box of B: component is true;
attribute syn_black_box of F: component is true;
-- Other component declarations in A.vhd go here
Altera Corporation
October 2007
7–57
Quartus II Handbook, Volume 1
signal cnt_out : INTEGER RANGE 0 TO 15;
BEGIN
U1 : B
PORT MAP (
data_in => data_in,
clk => clk,
ld => ld,
d_out => cnt_out );
U2 : F
PORT MAP (
d => cnt_out,
clk => clk,
e => e,
q => data_out );
-- Any other code in A.vhd goes here
END a_arch;
After you have completed the steps described in this section, you have a
netlist file for each partition of the design. These files are ready for use
with incremental compilation in the Quartus II software.
Creating a Quartus II Project for Multiple VQM Files
The Synplify software creates a Tcl file for each VQM file that provides
the Quartus II software with the appropriate constraints and information
to set up a project. For details about using the Tcl script generated by the
Synplify software to set up your Quartus II project and pass your
constraints, refer to “Running the Quartus II Software Manually Using
the Synplify-Generated Tcl Script” on page 7–19.
Depending on your design methodology, you can create one Quartus II
project for all netlists (a top-down placement and routing flow) or a
separate Quartus II project for each netlist (a bottom-up placement and
routing flow). In a top-down incremental compilation design flow, you
create design partition assignments and LogicLock floorplan location
assignments for each partition in the design within a single Quartus II
project. This methodology allows for the best quality of results and
performance preservation during incremental changes to your design.
You may require a bottom-up design flow where each partition must be
optimized separately, such as in certain team-based design flows.
7–58
Altera Corporation
October 2007
Incremental Compilation and Block-Based Design
To perform a bottom-up compilation in the Quartus II software, create
separate Quartus II projects and import each design partition into a
top-level design using the incremental compilation export and import
features to maintain placement results.
The following sections describe how to create the Quartus II projects for
these two design flows.
Creating Compile Points in a Single Quartus II Project for a
Top-Down Incremental Compilation Flow
Use the <top-level project>.tcl file that contains the Synplify assignments
for the top-level design. This method allows you to import all of the
partitions into one Quartus II project and optimize all modules within the
project at once, taking advantage of the performance preservation and
compilation time reduction offered by incremental compilation.
Figure 7–7 shows a visual representation of the design flow for the
example design in Figure 7–3.
All of the constraints from the top-level project are passed to the
Quartus II software in the top-level Tcl file, but any constraints made in
the lower-level projects within the Synplify software is not
forward-annotated. Enter these constraints manually in your Quartus II
project.
Figure 7–7. Design Flow Using Multiple VQM Files with One Quartus II Project
Quartus II Project
a.vqm
Use a.tcl to import top-level
Synplify Pro assignment.
Enter any lower-level
asignments manually.
b.vqm
f.vqm
Creating Multiple Quartus II Projects for a Bottom-Up Design Flow
Use the Tcl file that is created for each VQM file by the Synplify software
for each Synplify Project. This method generates multiple Quartus II
projects, one for each block in the design. Each designer in the project can
Altera Corporation
October 2007
7–59
Quartus II Handbook, Volume 1
optimize their block separately within the Quartus II software and export
the placement of their blocks. Figure 7–8 shows a visual representation of
the design flow for the example in Figure 7–3 on page 7–48.
Designers should create a LogicLock region for each block; the top-level
designer should then import all the blocks and assignments into the toplevel project. This method allows each block in the design to be treated
separately; each block can then be imported into one top-level project.
Figure 7–8. Design Flow Using Multiple Synplify Projects and Multiple Quartus II Projects
Quartus II Project
a.vqm
Quartus II Project
Quartus II Project
b.vqm
Use b.tcl to Import
Synplify Assignments
Conclusion
7–60
Use a.tcl to Import
Synplify Assignments
f.vqm
Use f.tcl to Import
Synplify Assignments
Advanced synthesis is an important part of the design flow. Taking
advantage of the Synplicity Synplify and Quartus II design flows allow
you to control how your design files are prepared for the Quartus II
place-and-route process, as well as improve performance and optimize a
design for use with Altera devices. Several of the methodologies outlined
in this chapter can help optimize a design to achieve performance goals
and save design time.
Altera Corporation
October 2007
Referenced Documents
Referenced
Documents
This chapter references the following documents:
■
■
■
■
■
■
■
■
Document
Revision History
Netlist Optimizations and Physical Synthesis chapter in volume 2 of the
Quartus II Handbook
Design Recommendations for Altera Devices chapter in volume 1 of the
Quartus II Handbook
Area and Timing Optimization chapter in volume 2 of the Quartus II
Handbook
Tasks & Tips chapter of the Synplify Software User Guide
Altera I/O Standards in the Synplify Reference Manual
Quartus II Incremental Compilation for Hierarchical and Team-Based
Design chapter in volume 1 of the Quartus II Handbook
Synplify Pro User Guide and Reference Manual on the Synplicity web
site at www.synplicity.com/literature/index.html
Tcl Scripting chapter in volume 2 of the Quartus II Handbook
Table 7–6 shows the revision history for this chapter.
Table 7–6. Document Revision History
Changes Made
Summary of Changes
October 2007
v7.2.0
Date and Version
The following changes were made to this document:
● Updated Synplicity version support
● Added information on how to set the correct Quartus II
version prior to compiling a MegaWizard-generated file
Updated chapter based on the
Synplicity functionality
supported with the Quartus II
software release, version 7.2
May 2007
v7.1.0
●
Removed figure 7-2 (no longer applicable)
Updated the section “Instantiating Altera
Megafunctions Using the MegaWizard Plug-In
Manager” to specify using the MegaWizard Plug-In
Manager-generated wrapper file only when using
Synplify software version 8.8
Replaced references to “clear-box” methodologies with
information supporting Synthesis Area and Timing
Estimation Netlists
Minor updates for the Quartus II software version 7.1.
Added Referenced Documents section.
Updated chapter based on the
Synplify software, version 8.8
and the Quartus II software
release, version 7.1
Added Cyclone III to list of devices supported
Clarified that the Synplify software generates the .scf
file regardless of the device selected.
This chapter has been updated
to include Cyclone III support
for this release.
●
●
●
●
March 2007
v7.0.0
Altera Corporation
October 2007
●
●
7–61
Quartus II Handbook, Volume 1
Table 7–6. Document Revision History (Continued)
Date and Version
November 2006
v6.1.0
Changes Made
●
●
●
●
●
May 2006
v6.0.0
Chapter 9 was formally Chapter 8 in version 6.0.0.
Added that SCF is generated to pass SDC constraints
for TimeQuest.
Added timing constraint information when using
TimeQuest.
Moved note about alt_pll megafunctions from clear box
section to black box section.
Clarified that Synplify reads the alt_pll megafunction
black box file for Stratix and Cyclone series devices.
Summary of Changes
Updated to include Stratix III
support and added information
on how to pass timing
constraint information for
TimeQuest.
Updated for the Quartus II software version 6.0.0:
Updated cross probing information.
● Added NativeLink® integration information.
● Added Synplify design flow support.
● Added Altera megafunction guidelines and
architecture-specific features.
—
December 2005
v5.1.1
Minor typographical corrections
—
October 2005
v5.1.0
●
May 2005
v5.0.0
Chapter 9 was formerly chapter 7 in version 4.2.
December 2004
v2.1.0
●
●
●
●
●
●
Updated for the Quartus II software version 5.1.
Chapter 8 was formerly chapter 9 in version 5.0.
—
Updates to tables, figures.
New functionality for Quartus II software version 4.1.
—
●
February 2004
v1.0.0
Initial release.
7–62
—
Chapter 8 was formerly Chapter 9 in version 4.1.
Updated information.
New functionality for Quartus II software version 4.2.
Updated figure 8-1.
June 2004
v2.0.0
●
—
—
Altera Corporation
October 2007
8. Quartus II Integrated
Synthesis
QII51008-7.2.0
Introduction
As programmable logic designs become more complex and require
increased performance, advanced synthesis has become an important
part of the design flow. The Quartus® II software includes advanced
integrated synthesis that fully supports VHDL and Verilog HDL, as well
as Altera®-specific design entry languages, and provides options to
control the synthesis process. With this synthesis support, the Quartus II
software provides a complete, easy-to-use solution.
This chapter documents the design flow and language support in the
Quartus II software. It explains how you can use incremental compilation
to reduce your compilation time, and how you can improve synthesis
results with Quartus II synthesis options and by controlling the inference
of architecture-specific megafunctions. This chapter also explains some of
the node-naming conventions used during synthesis to help you better
understand your synthesized design, and the messages issued during
synthesis to improve your HDL code. Scripting techniques for applying
all the options and settings described are also provided.
This chapter contains the following sections:
■
■
■
■
■
■
■
■
“Design Flow” on page 8–2
“Language Support” on page 8–5
“Incremental Synthesis and Incremental Compilation” on page 8–23
“Quartus II Synthesis Options” on page 8–24
“Analyzing Synthesis Results” on page 8–73
“Analyzing and Controlling Synthesis Messages” on page 8–74
“Node-Naming Conventions in Quartus II Integrated Synthesis” on
page 8–79
“Scripting Support” on page 8–86
This chapter provides examples of how to use attributes described within
the chapter, but does not cover specific coding examples.
f
Altera Corporation
October 2007
For examples of Verilog HDL and VHDL code synthesized for specific
logic functions, refer to the Recommended HDL Coding Styles chapter in
volume 1 of the Quartus II Handbook. For information about coding with
primitives that describe specific low-level functions in Altera devices,
refer to the Designing With Low-Level Primitives User Guide.
8–1
Quartus II Handbook, Volume 1
Design Flow
The Quartus II Analysis and Synthesis process includes Quartus II
integrated synthesis, which fully supports Verilog HDL and VHDL
languages as well as Altera-specific languages, and supports major
features in the SystemVerilog language (refer to “Language Support” on
page 8–5 for details). This stage of the compilation flow performs logic
synthesis to optimize design logic, and performs technology mapping to
implement the design logic using device resources, such as logic elements
(LEs) or adaptive logic modules (ALMs) and other dedicated logic blocks.
This stage also generates the single project database that integrates all the
design files in a project (including any netlists from third-party synthesis
tools).
You can use the Analysis and Synthesis stage of the Quartus II
compilation to perform any of the following levels of analysis and
synthesis:
■
■
■
Analyze Current File—Parse the current design source file to check
for syntax errors. This command does not report on many semantic
errors that require further design synthesis. On the Processing menu,
click Analyze Current File.
Analysis & Elaboration—Check a design for syntax and semantic
errors and perform elaboration to identify the design hierarchy. On
the Processing menu, point to Start, then click Start Analysis &
Elaboration.
Analysis & Synthesis—Perform complete analysis and synthesis on
a design, including technology mapping. On the Processing menu,
point to Start, then click Start Analysis & Synthesis. This is the most
commonly used command and is part of the full compilation flow.
The Quartus II design and compilation flow using Quartus II integrated
synthesis is made up of the following steps:
8–2
1.
Create a project in the Quartus II software, and specify the general
project information, including the top-level design entity name. On
the File menu, click New Project Wizard.
2.
Create design files in the Quartus II software or with a text editor.
3.
On the Project menu, click Add/Remove Files in Project and add all
design files to your Quartus II project using the Files page of the
Settings dialog box.
4.
Specify compiler settings that control the compilation and
optimization of the design during synthesis and fitting. For
synthesis settings, refer to “Quartus II Synthesis Options” on
page 8–24. Add timing constraints to specify the timing
requirements.
Altera Corporation
October 2007
Design Flow
5.
Compile the design in the Quartus II software. To synthesize the
design, on the Processing menu, point to Start, and click Start
Analysis & Synthesis.
1
6.
On the Processing menu, click Start Compilation to run a
complete compilation flow including placement, routing,
creation of a programming file, and timing analysis.
After obtaining synthesis and place-and-route results that meet
your needs, program or configure the Altera device.
The software provides netlists that allow you to perform functional
simulation and gate-level timing simulation in the Quartus II simulator
or a third-party simulator, perform timing analysis in a third-party timing
analysis tool in addition to the TimeQuest Timing Analyzer or Classic
Timing Analyzer, and/or perform formal verification in a third-party
formal verification tool. The Quartus II software also provides many
additional analysis and debugging features.
f
Altera Corporation
October 2007
For more information about creating a project, compilation flow, and
other features in the Quartus II software, refer to the Quartus II Help.
For an overall summary of Quartus II features, refer to the Introduction to
the Quartus II Software.
8–3
Quartus II Handbook, Volume 1
Figure 8–1 shows the basic design flow using Quartus II integrated
synthesis.
Figure 8–1. Quartus II Design Flow Using Quartus II Integrated Synthesis
Verilog HDL VHDL
AHDL
Formal Verification
Using Source Code
as Golden Netlist
BDF
Functional/RTL
Simulation
Constraints
& Settings
Post Synthesis
Simulation File
(.vho/.vo)
Internal
Synthesis
Netlist
Constraints
& Settings
Gate-Level
Functional
Simulation
Analysis & Synthesis
Fitter
Assembler
Gate-Level Timing
Simulation
Timing
Analyzer
Post
Place-and-Route
Simulation File
(.vho/.vo)
No
Timing & Area
Requirements
Satisfied?
Formal Verification
Using VO as
Revised Netlist
Post
Place-and-Route
Formal Verification File
(.vo)
Yes
Configuration/
Programming
Files (.sof/.pof)
Configure/Program Device
8–4
Altera Corporation
October 2007
Language Support
Language
Support
This section explains the Quartus II software’s integrated synthesis
support for HDL and schematic design entry, as well as graphical state
machine entry, and explains how to specify the Verilog or VHDL
language version used in your design. It also documents language
features such as Verilog macros, initial constructs and memory system
tasks, and VHDL libraries. “Design Libraries” on page 8–14 describes
how to compile and reference design units in different custom libraries
and “Using Parameters/Generics” on page 8–18 describes how to use
parameters or generics and how to pass them between different
languages.
To ensure that the software reads all associated project files, add each file
to your Quartus II project. To add files to your project in the Quartus II
GUI, on the Project menu, click Add/Remove Files In Project. Design
files can be added to the project in any order. You can mix all supported
languages and netlists generated by third-party synthesis tools in a single
Quartus II project.
Verilog HDL Support
The Quartus II Compiler’s analysis and synthesis module supports the
following Verilog HDL standards:
■
■
■
f
Verilog-1995 (IEEE Standard 1364-1995)
Verilog-2001 (IEEE Standard 1364-2001)
SystemVerilog-2005 (IEEE Standard 1800-2005) (not all constructs are
supported)
For complete information about specific Verilog syntax features and
language constructs, refer to the Quartus II Help.
The Quartus II Compiler uses the Verilog-2001 standard by default for
files that have the extension .v, and the SystemVerilog standard for files
that have the extension .sv.
1
The Verilog HDL code samples provided in this document
follow the Verilog-2001 standard unless otherwise specified.
To specify a default Verilog HDL version for all files, perform the
following steps:
Altera Corporation
October 2007
1.
On the Assignments menu, click Settings.
2.
In the Settings dialog box, under Category, expand Analysis &
Synthesis Settings, and select Verilog HDL Input.
8–5
Quartus II Handbook, Volume 1
3.
On the Verilog HDL Input page, under Verilog version, select the
appropriate Verilog version, then click OK.
You can override the default Verilog HDL version for each Verilog design
file by performing the following steps:
1.
On the Project menu, click Add/Remove Files in Project. The
Settings dialog box appears.
2.
On the Files page, click on the appropriate file in the list and click
the Properties button.
3.
In the HDL Version list, select SystemVerilog_2005, Verilog_2001,
or Verilog_1995 and click OK.
You can also control the Verilog HDL version inside a design file using the
VERILOG_INPUT_VERSION synthesis directive, as shown in
Example 8–1. This directive overrides the default HDL version and any
HDL version specified in the File Properties dialog box.
Example 8–1. Controlling the Verilog HDL Input Version with a Synthesis Directive
// synthesis VERILOG_INPUT_VERSION <language version>
The variable <language version> takes one of the following values:
■
■
■
VERILOG_1995
VERILOG_2001
SYSTEMVERILOG_2005
When the software reads a VERILOG_INPUT_VERSION synthesis
directive, the current language version changes as specified until the end
of the file, or until the next VERILOG_INPUT_VERSION directive is
reached.
1
You cannot change the language version in the middle of a
Verilog module.
For more information about specifying synthesis directives, refer to
“Synthesis Directives” on page 8–29.
If you use scripts to add design files, you can use the -HDL_VERSION
command to specify the HDL version for each design file. Refer to
“Adding an HDL File to a Project and Setting the HDL Version” on
page 8–87.
8–6
Altera Corporation
October 2007
Language Support
The Quartus II software support for Verilog HDL is case-sensitive in
accordance with the Verilog HDL standard. The Quartus II software
supports the compiler directive `define, in accordance with the Verilog
HDL standard.
The Quartus II software supports the include compiler directive to
include files with absolute paths (with either “/” or “\” as the separator),
or relative paths (relative to project root, user libraries, or current file
location). When searching for a relative path, the Quartus II software
initially searches relative to the project directory. If the software cannot
find the file, it then searches relative to all user libraries, and finally
relative to the directory location of the current file.
Verilog-2001 Support
The Quartus II software does not support Verilog-2001 libraries and
configurations.
SystemVerilog Support
The Quartus II software supports the following SystemVerilog
constructs:
■
■
■
■
■
■
■
■
■
■
■
■
■
■
■
■
■
■
Altera Corporation
October 2007
Parameterized interfaces, generic interfaces, and modport
constructs
Packages
Extern module declarations
Built-in data types logic, bit, byte, shortint, longint, int
Unsized integer literals ‘0, ‘1, ‘x, ‘z, ‘X, and ‘Z
Structure data types using struct
Ports and parameters with unrestricted data types
Unpacked and packed arrays (does not support packed arrays with
more than one dimension)
User-defined types using typedef
Global declarations of task/functions/parameters/types (does not
support global variables)
Coding constructs always_comb, always_latch, always_ff
Continuous assignments to nodes other than nets, and procedural
assignments to nodes other than reg
Enumeration methods First, Last, Next(n), Prev(n), Num,
and Name
Assignment operators +=, -=, *=, /=, %=, &=, |=, ^=, <<=, >>=,
<<<=, and >>>=
Increment ++ and decrement -Jump statements return, break, and continue
Enhanced for loop (declare loop variables inside initial condition)
Do-while loop
8–7
Quartus II Handbook, Volume 1
■
■
■
■
■
■
■
Assignment patterns
Keywords unique and priority in case statements
Default values for function/task arguments
Closing labels
Extensions to directives ‘define and ‘include
Expression size system function $bits
Array query system functions $dimensions,
$unpacked_dimensions, $left, $right, $high, $low,
$increment, $size
Quartus II integrated synthesis also parses, but otherwise ignores,
SystemVerilog assertions.
1
Designs written to comply with the Verilog-2001 standard may
not compile successfully using the SystemVerilog setting
because the SystemVerilog standard adds a number of new
reserved keywords. For a list of reserved words in each
language standard, refer to the Quartus II Help.
Initial Constructs and Memory System Tasks
The Quartus II software infers power-up conditions from Verilog
initial constructs. The software creates power-up settings for
variables, including RAM blocks. If the Quartus II software encounters
non-synthesizable constructs in an initial block, it generates an error.
To avoid such errors, enclose non-synthesizable constructs (such as those
intended only for simulation) in translate_off and translate_on
synthesis directives, as described in “Translate Off and On / Synthesis Off
and On” on page 8–65. Synthesis of initial constructs enables the
power-up state of the synthesized design to match, as closely as possible,
the power-up state of the original HDL code in simulation.
1
Initial blocks do not infer power-up conditions in some
third-party EDA synthesis tools. If converting between
synthesis tools, ensure that your power-up conditions are set
correctly.
Quartus II integrated synthesis supports the $readmemb and
$readmemh system tasks to initialize memories. Example 8–2 shows an
initial construct that initializes an inferred RAM with $readmemb.
8–8
Altera Corporation
October 2007
Language Support
Example 8–2. Verilog Example of Initializing RAM with the readmemb Command
reg [7:0] ram[0:15];
initial
begin
$readmemb("ram.txt", ram);
end
When creating a text file to use for memory initialization, specify the
address using the format @<location> on a new line, then specify the
memory word such as 110101 or abcde on the next line. Example 8–3
shows a portion of a memory initialization file for the RAM in
Example 8–2.
Example 8–3. Text File Format for Initializing RAM with the readmemb Command
@0
00000000
@1
00000001
@2
00000010
…
@e
00001110
@f
00001111
Verilog HDL Macros
The Quartus II software fully supports Verilog HDL macros, which you
can define with the `define compiler directive in your source code. You
can also define macros in the GUI or on the command line.
Setting a Verilog Macro Default Value in the GUI
To specify a macro in the GUI, on the Assignments menu, click Settings.
Under Category, expand Analysis & Synthesis Settings and click
Verilog HDL Input. Under Verilog HDL macro, type the macro name in
the Name box, the value in the Setting box, and click Add.
Setting a Verilog Macro Default Value on the Command Line
To set a default value for a Verilog macro on the command line, use the
--verilog_macro option, as shown in Example 8–4.
Example 8–4. Command Syntax for Specifying a Verilog Macro
quartus_map <Design name> --verilog_macro= "<Macro Name>=<Macro Setting>" r
Altera Corporation
October 2007
8–9
Quartus II Handbook, Volume 1
The command in Example 8–5 has the same effect as specifying
`define a 2 in the Verilog HDL source code.
Example 8–5. Specifying a Verilog Macro a = 2
quartus_map my_design --verilog_macro="a=2" r
To specify multiple macros, you can repeat the option more than once, as
in Example 8–6.
Example 8–6. Specifying Verilog Macros a = 2 and a = 3
quartus_map my_design --verilog_macro="a=2" --verilog_macro="b=3" r
VHDL Support
The Quartus II Compiler’s Analysis and Synthesis module supports the
following VHDL standards:
■
■
f
VHDL 1987 (IEEE Standard 1076-1987)
VHDL 1993 (IEEE Standard 1076-1993)
For information about specific VHDL syntax features and language
constructs, refer to the Quartus II Help.
The Quartus II Compiler uses the VHDL 1993 standard by default for files
that have the extension .vhdl or .vhd.
1
The VHDL code samples provided in this document follow the
VHDL 1993 standard.
To specify a default VHDL version for all files, perform the following
steps:
1.
On the Assignments menu, click Settings.
2.
In the Settings dialog box, under Category, expand Analysis &
Synthesis Settings, and select VHDL Input.
3.
On the VHDL Input page, under VHDL version, select the
appropriate version, then click OK.
You can override the default VHDL version for each VHDL design file by
performing the following steps:
8–10
Altera Corporation
October 2007
Language Support
1.
On the Project menu, click Add/Remove Files in Project. The
Settings dialog box appears.
2.
On the Files page, click on the appropriate file in the list and click
Properties.
3.
In the HDL version list, select VHDL93 or VHDL87 and click OK.
You can also specify the VHDL version for each design file using the
VHDL_INPUT_VERSION synthesis directive, as shown in Example 8–7.
This directive overrides the default HDL version and any HDL version
specified in the File Properties dialog box.
Example 8–7. Controlling the VHDL Input Version with a Synthesis Directive
--synthesis VHDL_INPUT_VERSION <language version>
The variable <language version> takes one of the following values:
■
■
VHDL87
VHDL93
When the software reads a VHDL_INPUT_VERSION synthesis directive, it
changes the current language version as specified until the end of the file,
or until it reaches the next VHDL_INPUT_VERSION directive.
1
You cannot change the language version in the middle of a
VHDL design unit.
For more information about specifying synthesis directives, refer to
“Synthesis Directives” on page 8–29.
If you use scripts to add design files, you can use the —HDL_VERSION
command to specify the HDL version for each design file. Refer to
“Adding an HDL File to a Project and Setting the HDL Version” on
page 8–87.
The Quartus II software reads default values for registered signals
defined in the VHDL code and converts the default values into power-up
level settings. This enables the power-up state of the synthesized design
to match, as closely as possible, the power-up state of the original HDL
code in simulation.
Altera Corporation
October 2007
8–11
Quartus II Handbook, Volume 1
VHDL Standard Libraries and Packages
The Quartus II software includes the standard IEEE libraries and a
number of vendor-specific VHDL libraries. For information about
organizing your own design units into custom libraries, refer to “Design
Libraries” on page 8–14.
The IEEE library includes the standard VHDL packages
std_logic_1164, numeric_std, numeric_bit, and math_real.
The STD library is part of the VHDL language standard and includes the
packages standard (included in every project by default) and textio.
For compatibility with older designs, the Quartus II software also
supports the following vendor-specific packages and libraries:
■
■
■
■
f
Synopsys packages such as std_logic_arith and
std_logic_unsigned in the IEEE library
Mentor Graphics® packages such as std_logic_arith in the
ARITHMETIC library
Altera primitive packages altera_primitives_components
(for primitives such as GLOBAL and DFFE) and maxplus2 (for legacy
support of MAX+PLUS® II primitives) in the ALTERA library
Altera megafunction packages altera_mf_components and
stratixgx_mf_components in the ALTERA_MF library (for
Altera-specific megafunctions including LCELL), and
lpm_components in the LPM library for library of parameterized
modules (LPM) functions.
For a complete listing of library and package support, refer to the
Quartus II Help.
1
Beginning with the Quartus II software version 5.1, you should
import component declarations for Altera primitives such as
GLOBAL and DFFE from the
altera_primitives_components package and not the
altera_mf_components package.
AHDL Support
The Quartus II Compiler’s Analysis and Synthesis module fully supports
the Altera Hardware Description Language (AHDL).
AHDL designs use Text Design Files (.tdf). You can import AHDL
Include Files (.inc) into a Text Design File with an AHDL include
statement. Altera provides AHDL Include Files for all megafunctions
shipped with the Quartus II software.
8–12
Altera Corporation
October 2007
Language Support
f
For information about specific AHDL syntax features and language
constructs, refer to the Quartus II Help.
1
The AHDL language does not support the synthesis directives
or attributes described in this chapter.
Schematic Design Entry Support
The Quartus II Compiler’s analysis and synthesis module fully supports
Block Design Files (.bdf) for schematic design entry.
You can use the Quartus II software’s Block Editor to create and edit Block
Design Files and open Graphic Design Files (.gdf) imported from the
MAX+PLUS II software. Use the Symbol Editor to create and edit Block
Symbol Files (.bsf) and open MAX+PLUS II Symbol Files (.sym). You can
read and edit these legacy MAX+PLUS II formats with the Quartus II
Block and Symbol Editors; however, the Quartus II software saves them
as .bdf or .bsf files.
f
For information about creating and editing schematic designs, refer to
the Quartus II Help.
1
Schematic entry methods do not support the synthesis directives
or attributes described in this chapter.
State Machine Editor
The Quartus II software supports graphical state machine entry. To create
a new finite state machine (FSM) design, on the File menu, click New. On
the Device Design Files tab, choose State Machine Editor.
In the editor, you can use the State Machine Wizard to step you through
the state machine creation. Click the State Machine Wizard icon. Specify
the reset information, define the input ports, states, and transitions, and
then define the output ports and output conditions. Click Finish to create
the state machine diagram.
Alternately, create the state machine diagram in the editor GUI. Use the
icons or right-click menu options to insert new input and output signals
and create states in the schematic display. To specify transitions, select the
Transition Tool and click on the source state, then drag the mouse to the
destination state. Double-click on a transition to specify the transition
equation, using a syntax that conforms to Verilog HDL. Double-click on a
state to open the State Properties dialog box, where you can change the
state name, specify whether it acts as the reset state, and change the
incoming and outgoing transition equations.
Altera Corporation
October 2007
8–13
Quartus II Handbook, Volume 1
To view and edit state machine information in a table format, click the
State Machine Table icon.
The state machine diagram is saved as a State Machine File (.smf). When
you have finished defining the state machine logic, create a Verilog HDL
or VHDL design file by clicking the Generate HDL File icon. You can
then instantiate the state machine in your design using any design entry
language.
f
For more information about creating and editing state machine
diagrams, refer to the Quartus II Help.
Design Libraries
By default, the Quartus II software compiles all design files into the work
library. If you do not specify a design library, or if a file refers to a library
that does not exist, or if the library does not contain a referenced design
unit, the software searches the work library. This behavior allows the
Quartus II software to compile most designs with minimal setup.
(Creating separate custom design libraries is optional.)
To compile your design files into specific libraries (for example, when you
have two or more functionally different design entities that share the
same name), you can specify a destination library for each design file in
various ways, as described in the following subsections:
■
■
“Specifying a Destination Library Name in the Settings Dialog Box”
on page 8–15
“Specifying a Destination Library Name in the Quartus II Settings
File or Using Tcl” on page 8–15
When the Quartus II Compiler analyzes the file, it stores the analyzed
design units in the file’s destination library.
1
Beginning with the Quartus II software version 6.1, a design can
contain two or more entities with the same name if they are
compiled into separate libraries.
When compiling a design instance, the Quartus II software initially
searches for the entity in the library associated with the instance (which
is the work library if no other library is specified). If the entity definition
is not found, the software searches for a unique entity definition in all
design libraries. If more than one entity with the same name is found, the
software generates an error. If your design uses multiple entities with the
same name, you must compile the entities into separate libraries.
8–14
Altera Corporation
October 2007
Language Support
In VHDL, there are several ways to associate an instance with a particular
entity, as described in “Mapping a VHDL Instance to an Entity in a
Specific Library” on page 8–16. In Verilog HDL, BDF, AHDL, as well as
VQM and EDIF netlists, use different libraries for each of the entities that
have the same name, and compile the instantiation into the same library
as the appropriate entity.
Specifying a Destination Library Name in the Settings Dialog Box
To specify a library name for one of your design files, perform the
following steps:
1.
On the Assignments menu, click Settings.
2.
On the Files page of the Settings dialog box, select the file in the
File Name list.
3.
Click Properties.
4.
In the File Properties dialog box, select the type of design file from
the Type list.
5.
Type the desired library name in the Library field.
6.
Click OK.
Specifying a Destination Library Name in the Quartus II Settings File or
Using Tcl
You can specify the library name with the -library option to the
<language type>_FILE assignment in the Quartus II Settings File or with
Tcl commands.
For example, the following Quartus II Settings File or Tcl assignments
specify that the Quartus II software analyze my_file.vhd and store its
contents (design units) in the VHDL library my_lib, and analyze the
Verilog file my_header_file.h and store its contents in a library called
another_lib.
Example 8–8. Specifying a Destination Library Name
set_global_assignment –name VHDL_FILE my_file.vhd –library my_lib
set_global_assignment –name VERILOG_FILE my_header_file.h –library\
another_lib
For more information about Tcl scripting, refer to “Scripting Support” on
page 8–86.
Altera Corporation
October 2007
8–15
Quartus II Handbook, Volume 1
Specifying a Destination Library Name in a VHDL File
You can use the library synthesis directive to specify a library name in
your VHDL source file. This directive takes a single string argument: the
name of the destination library. Specify the library directive in a VHDL
comment prior to the context clause for a primary design unit (that is, a
package declaration, an entity declaration, or a configuration), using one
of the supported keywords for synthesis directives, that is, altera,
synthesis, pragma, synopsys, or exemplar.
For more information about specifying synthesis directives, refer to
“Synthesis Directives” on page 8–29.
The library directive overrides the default library destination work,
the library setting specified for the current file through the Settings
dialog box, any existing Quartus II Settings File setting, any setting made
through the Tcl interface, or any prior library directive in the current
file. The directive remains effective until the end of the file or the next
library synthesis directive.
Example 8–9 uses the library synthesis directive to create a library
called my_lib that contains the design unit my_entity.
Example 8–9. Using the library Synthesis Directive
-- synthesis library my_lib
library ieee;
use ieee.std_logic_1164.all;
entity my_entity(...)
end entity my_entity;
1
You can specify a single destination library for all the design
units in a given source file by specifying the library name in the
the Settings dialog box, editing the Quartus II Settings File, or
using the Tcl interface. Using the library directive to change
the destination VHDL library within a source file gives you the
option of organizing the design units in a single file into
different libraries, rather than just a single library.
The Quartus II software produces an error if you use the library directive
within a design unit.
Mapping a VHDL Instance to an Entity in a Specific Library
The VHDL language provides a number of ways to map or bind an
instance to an entity in a specific library, as described in the following
subsections.
8–16
Altera Corporation
October 2007
Language Support
Direct Entity Instantiation
In the direct entity instantiation method, the instantiation refers to an
entity in a specific library, as shown in Example 8–10.
Example 8–10. VHDL Example of Direct Entity Instantiation
entity entity1 is
port(...);
end entity entity1;
architecture arch of entity1 is
begin
inst: entity lib1.foo
port map(...);
end architecture arch;
Component Instantiation—Explicit Binding Indication
There is more than one mechanism for binding a component to an entity.
In an explicit binding indication, you bind a component instance to a
specific entity, as shown in Example 8–11.
Example 8–11. VHDL Example of Explicit Binding Instantiation
entity entity1 is
port(...);
end entity entity1;
package components is
component entity1 is
port map (...);
end component entity1;
end package components;
entity top_entity is
port(...);
end entity top_entity;
use lib1.components.all;
architecture arch of top_entity is
-- Explicitly bind instance I1 to entity1 from lib1
for I1: entity1 use
entity lib1.entity1
port map(...);
begin
I1: entity1 port map(...);
end architecture arch;
Altera Corporation
October 2007
8–17
Quartus II Handbook, Volume 1
Component Instantiation—Default Binding
If you do not provide an explicit binding indication, a component
instance is bound to the nearest visible entity with the same name. If no
such entity is visible in the current scope, the instance is bound to the
entity in the library in which the component was declared. For example,
if the component is declared in a package in library MY_LIB, an instance
of the component is bound to the entity in library MY_LIB. The portions
of code in Example 8–12 and 8–13 show this instantiation method.
Example 8–12. VHDL Example of Default Binding to the Entity in the Same Library as the Component
Declaration
use mylib.pkg.foo; -- import component declaration from package “pkg” in
-- library “mylib”
architecture rtl of top
...
begin
-- This instance will be bound to entity “foo” in library “mylib”
inst: foo
port map(...);
end architecture rtl;
Example 8–13. VHDL Example of Default Binding to the Directly Visible Entity
use mylib.foo; -- make entity “foo” in library “mylib” directly visible
architecture rtl of top
component foo is
generic (…)
port ( );
end component;
begin
-- This instance will be bound to entity “foo” in library “mylib”
inst: foo
port map(...);
end architecture rtl;
Using Parameters/Generics
This section describes how parameters (called generics in VHDL) are
supported in the Quartus II software, and how you can pass these
parameters between different design languages.
You can enter default parameter values for your design in the Default
Parameters box in the Analysis & Synthesis Settings page of the
Settings dialog box. Default parameters allow you to specify the
parameter overrides for your top-level entity. In AHDL, parameters are
inherited, so any default parameters apply to all AHDL instances in the
design. You can also specify parameters for instantiated modules in a
8–18
Altera Corporation
October 2007
Language Support
Block Design File. To modify parameters on a BDF instance, double-click
on the parameter value box for the instance symbol, or right-click on the
symbol and choose Properties, then click the Parameters tab. For these
GUI-based entry methods, refer to “Setting Default Parameter Values and
BDF Instance Parameter Values” on page 8–19 for information about how
parameter values are interpreted, and for recommendations about the
format you should use.
You can specify parameters for instantiated modules in your design
source files, using the syntax provided for that language. Some designs
instantiate entities in a different language; for example, they may
instantiate a VHDL entity from a Verilog design file. You can pass
parameters or generics between VHDL, Verilog HDL, AHDL, and BDF
schematic entry, and from EDIF or VQM to any of these languages. In
most cases, you do not have to do anything special to pass parameters
from one language to another. However, in some cases you may have to
specify the type of the parameter you are passing. In those cases you
should follow certain guidelines to ensure that the parameter value is
interpreted correctly. Refer to “Passing Parameters Between Two Design
Languages” on page 8–20 for parameter type rules.
Setting Default Parameter Values and BDF Instance Parameter Values
Default parameter values and BDF instance parameter values do not have
an explicitly declared type. In most cases, the Quartus II software can
correctly infer the type from the value without ambiguity. For example,
“ABC” is interpreted as a string, 123 as an integer, and 15.4 as a
floating-point value. In other cases, such as when the instantiated
subdesign language is VHDL, the Quartus II software uses the type of the
parameter/generic in the instantiated entity to determine how to
interpret the value, so that a value of 123 is interpreted as a string if the
VHDL parameter is of type string. In addition, you can set the parameter
value in a format that is legal in the language of the instantiated entity. For
example, to pass an unsized bit literal value from BDF to System/Verilog,
you can use '1 as the parameter value, and to pass a 4-bit binary vector
from BDF to Verilog, you can use 4'b1111 as the parameter value.
In a few cases, the Quartus II software cannot infer the correct type of
parameter value. To avoid ambiguity, specify the parameter value in a
type-encoded format where the first or first and second character of the
parameter indicate the type of the parameter, and the rest of the string
indicates the value in a quoted sub-string. For example, to pass a binary
string 1010 from BDF to Verilog HDL, you cannot simply use the value
1001, because the Quartus II software interprets it as a decimal value.
You also cannot use the string "1001", because the Quartus II software
interprets it as an ASCII string. You must use the type-encoded string
B"1001" for the Quartus II software to interpret the parameter value
Altera Corporation
October 2007
8–19
Quartus II Handbook, Volume 1
correctly. Table 8–1 provides a list of valid parameter strings and shows
how they are interpreted within the Quartus II software. Altera
recommends using the type-encoded format only when necessary to
resolve ambiguity.
Table 8–1. Valid Parameter Strings and How They are Interpreted
Parameter String
Quartus II Parameter Type, Format, and Value
S"abc", s"abc"
String value “abc”
"abc123", "123abc"
String value abc123 or 123abc
F"12.3", f"12.3"
Floating point number 12.3
-5.4
Floating point number -5.4
D"123", d"123"
Decimal number 123
123, -123
Decimal number 123, -123
X"ff", H"ff"
Hexadecimal value FF
Q"77", O"77"
Octal value 77
B"1010", b"1010"
Unsigned binary value 1010
SB"1010", sb"1010"
Signed binary value 1010
R"1", R"0", R"X", R"Z", r"1", r"0", r"X", r"Z"
Unsized bit literal
E"apple", e"apple"
Enum type, value name is apple
P"1 unit"
Physical literal, the value is (1, unit)
A(…), a(…)
Array type or record type, whose content is
determined by the string (...)
Passing Parameters Between Two Design Languages
When passing a parameter between two different languages, a design
block that is higher in the design hierarchy instantiates a lower-level
subdesign block and provides parameter information. It is essential that
the parameter be correctly interpreted by the subdesign language (the
design entity that is instantiated). Based on the information provided by
the higher-level design and the value format, and sometimes by the
parameter type of the subdesign entity, the Quartus II software interprets
the type and value of the passed parameter.
When passing a parameter whose value is an enumerated type value or
literal from a language that does not support enumerated types to one
that does (for example from Verilog to VHDL), it is essential that the
enumeration literal is spelled correctly in the higher-level design. The
parameter value is passed as a string literal, and it is up to the language
of the lower-level design to correctly convert the string literal into the
correct enumeration literal.
8–20
Altera Corporation
October 2007
Language Support
If the lower-level language is SystemVerilog, it is essential that the enum
value is used in the correct case. In SystemVerilog, it is recommended that
two enumeration literals do not only differ in case. For example, enum
{item, ITEM} is not a good choice of item names because these names
can create confusion among users and it is more difficult to pass
parameters from case-insensitive HDLs, such as VHDL.
Arrays have different support in different design languages. For details
about the array parameter format, refer to the Parameter section in the
Analysis & Synthesis Report of a design that contains array parameters or
generics.
The following code shows examples of passing parameters from one
design entry language to a subdesign written in another language.
Example 8–14 shows a VHDL subdesign that is instantiated into a
top-level Verilog design in Example 8–15. Example 8–16 shows a Verilog
subdesign that is instantiated in a top-level VHDL design in
Example 8–17.
Example 8–14. VHDL Parameterized Subdesign Entity
type fruit is (apple, orange, grape);
entity vhdl_sub is
generic (
name : string := "default",
width : integer := 8,
number_string : string := "123",
f : fruit := apple,
binary_vector : std_logic_vector(3 downto 0) := "0101",
signed_vector : signed (3 downto 0) := "1111");
Example 8–15. Verilog HDL Top-level Design Instantiating and Passing Parameters to VHDL Entity from
Example 8–14
vhdl_sub inst (...);
defparam inst.name = "lower";
defparam inst.width = 3;
defparam inst.num_string = "321";
defparam inst.f = "grape"; // Must exactly match enum value
defparam inst.binary_vector = 4'b1010;
defparam inst.signed_vector = 4'sb1010;
Altera Corporation
October 2007
8–21
Quartus II Handbook, Volume 1
Example 8–16. Verilog HDL Parameterized Subdesign Module
module veri_sub (...)
parameter name = "default";
parameter width = 8;
parameter number_string = "123";
parameter binary_vector = 4'b0101;
parameter signed_vector = 4'sb1111;
Example 8–17. VHDL Top-level Design Instantiating and Passing Parameters to the Verilog Module from
Example 8–16
inst:veri_sub
generic map (
name => "lower",
width => 3,
number_string => "321"
binary_vector = "1010"
signed_vector = "1010")
To use an HDL subdesign such as the one shown in Example 8–16 in a
top-level BDF design, you must first generate a symbol for the HDL file,
as shown in Figure 8–2. Open the HDL file in the Quartus II software, and
then, on the File menu, point to Create/Update and click Create Symbol
Files for Current File.
To modify parameters on a BDF instance, double-click on the parameter
value box for the instance symbol, or right-click on the symbol and choose
Properties, then click the Parameters tab.
Figure 8–2. BDF Top-Level Design Instantiating and Passing Parameters to the
Verilog Module from Example 8–16.
8–22
Altera Corporation
October 2007
Incremental Synthesis and Incremental Compilation
Incremental
Synthesis and
Incremental
Compilation
The incremental compilation feature in the Quartus II software manages
a design hierarchy for incremental design by allowing you to divide the
design into multiple partitions. Incremental compilation ensures that
when a design is compiled, only those partitions of the design that have
been updated will be resynthesized, reducing compilation time and
runtime memory usage. This also means that node names are maintained
during synthesis for all registered and combinational nodes in
unchanged partitions.
You can use just incremental synthesis, or use the default full incremental
compilation flow in which you can also preserve the placement (and
optionally routing) information for unchanged partitions. This feature
allows you to preserve performance of unchanged blocks in your design
and reduces the time required for placement and routing, which
significantly reduces your design compilation time. Altera recommends
using the full incremental compilation feature even if you want to
preserve just the synthesis information. You can perform incremental
synthesis by using full incremental compilation with the Netlist Type for
all design partitions set to Post-Synthesis. Some Quartus II features, such
as formal verification and incremental SignalTap® II logic analysis,
require that the full incremental compilation feature be turned on.
f
For information about using the recommended full 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. For information about the Incremental synthesis only option,
refer to the Quartus II Help.
Partitions for Preserving Hierarchical Boundaries
A design partition represents a portion of the design that you want to
synthesize and fit incrementally. Incremental compilation maintains the
hierarchical boundaries of design partitions, so you can use design
partitions if you need to preserve hierarchical boundaries through the
synthesis and fitting process. For example, if you are performing formal
verification, you must use partitions with the full incremental
compilation flow to ensure that no optimizations occur across specific
design hierarchies.
1
Altera Corporation
October 2007
Beginning with the Quartus II software version 6.0, Altera
recommends that you use Design Partition assignments instead
of the Preserve Hierarchical Boundary logic option, which may
be removed in future versions of the Quartus II software.
8–23
Quartus II Handbook, Volume 1
Quartus II
Synthesis
Options
8–24
The Quartus II software offers a number of options to help you control the
synthesis process and achieve the optimal results for your design.
“Setting Synthesis Options” on page 8–25 describes the Analysis &
Synthesis Settings page of the Settings dialog box, where you can set the
most common global settings and options, and defines the following
three types of synthesis options: Quartus II logic options, synthesis
attributes, and synthesis directives. The other subsections describe the
following common synthesis options in the Quartus II software, and
provide HDL examples of how to use each option where applicable:
■
Major Optimization Settings
●
“Optimization Technique” on page 8–30
●
“Speed Optimization Technique for Clock Domains” on
page 8–30
●
“PowerPlay Power Optimization” on page 8–31
●
“Restructure Multiplexers” on page 8–32
■
State Machine Settings and Enumerated Types
●
“State Machine Processing” on page 8–34
●
“Manually Specifying State Assignments Using the
syn_encoding Attribute” on page 8–35
●
“Manually Specifying Enumerated Types Using the
enum_encoding Attribute” on page 8–38
●
“Safe State Machines” on page 8–40
■
Register Power-Up Settings
●
“Power-Up Level” on page 8–42
●
“Power-Up Don’t Care” on page 8–43
■
Controlling, Preserving, Removing, and Duplicating Logic and
Registers
●
“Remove Duplicate Registers” on page 8–44
●
“Remove Redundant Logic Cells” on page 8–44
●
“Preserve Registers” on page 8–44
●
“Disable Register Merging/Don’t Merge Register” on page 8–45
●
“Noprune Synthesis Attribute/Preserve Fan-out Free Register
Node” on page 8–46
●
“Keep Combinational Node/Implement as Output of Logic
Cell” on page 8–47
●
“Don't Retime, Disabling Synthesis Netlist Optimizations” on
page 8–48
●
“Don't Replicate, Disabling Synthesis Netlist Optimizations” on
page 8–49
●
“Maximum Fan-Out” on page 8–50
●
“Controlling Clock Enable Signals with Auto Clock Enable
Replacement and direct_enable” on page 8–51
Altera Corporation
October 2007
Quartus II Synthesis Options
●
To preserve design hierarchy, refer to “Partitions for Preserving
Hierarchical Boundaries” on page 8–23
■
Megafunction Inference Options
●
“Megafunction Inference Control” on page 8–52
●
“RAM Style and ROM Style—for Inferred Memory” on
page 8–55
●
“Turning Off Add Pass-Through Logic to Inferred RAMs/
no_rw_check Attribute Setting” on page 8–57
●
“RAM Initialization File—for Inferred Memory” on page 8–59
●
“Multiplier Style—for Inferred Multipliers” on page 8–59
■
Controlling Synthesis with Other Synthesis Directives
●
“Full Case” on page 8–62
●
“Parallel Case” on page 8–63
●
“Translate Off and On / Synthesis Off and On” on page 8–65
●
“Ignore translate_off and synthesis_off Directives” on page 8–65
●
“Read Comments as HDL” on page 8–66
■
Specifying I/O-Related Assignments
●
“Use I/O Flipflops” on page 8–67
●
“Specifying Pin Locations with chip_pin” on page 8–68
■
Setting Quartus II Logic Options in Your HDL Source Code
●
“Using altera_attribute to Set Quartus II Logic Options” on
page 8–70
Setting Synthesis Options
You can set synthesis options in the Settings dialog box, or with logic
options in the Quartus II software, or you can use synthesis attributes and
directives within the HDL source code.
Analysis & Synthesis Settings Page of the Settings Dialog Box
On the Assignments menu, click Settings to open the Settings dialog box.
The Analysis & Synthesis Settings page allows you to set global
synthesis options that apply to the entire project. These options are
described in later subsections.
Quartus II Logic Options
Quartus II logic options control many aspects of the synthesis and
place-and-route process. To set logic options in the Quartus II graphical
user interface, on the Assignments menu, click Assignment Editor. You
can also use a corresponding Tcl command. Quartus II logic options allow
Altera Corporation
October 2007
8–25
Quartus II Handbook, Volume 1
you to set instance or node-specific assignments without editing the
source HDL code. Logic options can be used with all design entry
languages supported by the Quartus II software.
f
For more information about using the Assignment Editor, refer to the
Assignment Editor chapter in volume 2 of the Quartus II Handbook.
Synthesis Attributes
The Quartus II software supports synthesis attributes for Verilog HDL
and VHDL, also commonly called pragmas. These attributes are not
standard Verilog HDL or VHDL commands; synthesis tools use attributes
to control the synthesis process in a particular manner. Attributes always
apply to a specific design element, and are applied in the HDL source
code. Some synthesis attributes are also available as Quartus II logic
options via the Quartus II user interface or with Tcl. Each attribute
description in this chapter indicates whether there is a corresponding
setting or logic option that can be set in the user interface; some attributes
can be specified only with HDL synthesis attributes.
Attributes specified in your HDL code are not visible in the Assignment
Editor or in the Quartus II Settings File. Assignments or settings made
through the Quartus II user interface, the Quartus II Settings File, or the
Tcl interface take precedence over assignments or settings made with
synthesis attributes in your HDL code. The Quartus II software generates
warning messages if invalid attributes are found, but does not generate
an error or stop the compilation. This behavior is required because
attributes are specific to various design tools, and attributes not
recognized in the Quartus II software may be intended for a different
EDA tool. The Quartus II software lists the attributes specified in your
HDL code in the Source assignments table in the Analysis & Synthesis
report.
The Verilog-2001, SystemVerilog, and VHDL language definitions
provide specific syntax for specifying attributes, but in Verilog-1995 HDL,
you must embed attribute assignments in comments. You can enter
attributes in your code using the syntax in Examples 8–18, 8–19, and 8–20,
where <attribute>, <attribute type>, <value>, <object>, and <object type> are
variables, and the entry in brackets is optional. The examples in this
chapter demonstrate each syntax form.
1
8–26
Verilog HDL is case-sensitive; therefore, synthesis attributes are
also case-sensitive.
Altera Corporation
October 2007
Quartus II Synthesis Options
Example 8–18. Synthesis Attributes in Verilog-1995 HDL
// synthesis <attribute> [ = <value> ]
or
/* synthesis <attribute> [ = <value> ] */
Verilog-1995 comment-embedded attributes, as shown in Example 8–18,
must be used as a suffix to (that is, placed after) the declaration of an item
and must appear before the semicolon when one is required.
1
You cannot use the open one-line comment in Verilog HDL
when a semicolon is required at the end of the line, because it is
not clear to which HDL element the attribute applies. For
example, you cannot make an attribute assignment such as
reg r; // synthesis <attribute> because the attribute could
be read as part of the next line.
To apply multiple attributes to the same instance in Verilog-1995, separate
the attributes with spaces, as follows:
//synthesis <attribute1> [ = <value> ] <attribute2> [ = <value> ]
For example, to set the maxfan attribute to 16 (Refer to “Maximum FanOut” on page 8–50 for details) and set the preserve attribute (refer to
“Preserve Registers” on page 8–44 for details) on a register called
my_reg, use the following syntax:
reg my_reg /* synthesis maxfan = 16 preserve */;
In addition to the synthesis keyword as shown above, the keywords
pragma, synopsys, and exemplar are supported for compatibility with
other synthesis tools. The keyword altera is also supported, which
allows you to add synthesis attributes that will be recognized only by
Quartus II integrated synthesis and not by other tools that recognize the
same synthesis attribute.
1
Because formal verification tools do not recognize the
exemplar, pragma, and altera keywords, avoid using these
attribute keywords when using formal verification.
Example 8–19. Synthesis Attributes in Verilog-2001 and SystemVerilog
(* <attribute> [ = <value> ] *)
Altera Corporation
October 2007
8–27
Quartus II Handbook, Volume 1
Verilog-2001 attributes, as shown in Example 8–19, must be used as a
prefix to (that is, placed before) a declaration, module item, statement, or
port connection, and used as a suffix to (that is, placed after) an operator
or a Verilog HDL function name in an expression.
1
Because formal verification tools do not recognize the syntax,
the Verilog-2001 attribute syntax is not supported when using
formal verification.
To apply multiple attributes to the same instance in Verilog-2001 or
SystemVerilog, separate the attributes with commas, as shown in the
following example:
(* <attribute1> [ = <value1>], <attribute2> [ = <value2> ] *)
For example, to set the maxfan attribute to 16 (refer to“Maximum FanOut” on page 8–50 for details) and set the preserve attribute (refer to
“Preserve Registers” on page 8–44 for details) on a register called
my_reg, use the following syntax:
(* preserve, maxfan = 16 *) reg my_reg;
Example 8–20. Synthesis Attributes in VHDL
attribute <attribute> : <attribute type> ;
attribute <attribute> of <object> : <object type> is <value>;
VHDL attributes, as shown in Example 8–20, declare the attribute type
and then apply it to a specific object. For VHDL designs, all supported
synthesis attributes are declared in the altera_syn_attributes
package in the Altera library. You can call this library from your VHDL
code to declare the synthesis attributes, as follows:
LIBRARY altera;
USE altera.altera_syn_attributes.all;
8–28
Altera Corporation
October 2007
Quartus II Synthesis Options
Synthesis Directives
The Quartus II software supports synthesis directives, also commonly
called compiler directives or pragmas. You can include synthesis
directives in Verilog HDL or VHDL code as comments. These directives
are not standard Verilog HDL or VHDL commands; synthesis tools use
directives to control the synthesis process in a particular manner.
Directives do not apply to a specific design node but change the behavior
of the synthesis tool from the point where they occur in the HDL source
code. Other tools, such as simulators, ignore these directives and treat
them as comments.
You can enter synthesis directives in your code using the syntax shown
in Example 8–21 and 8–22, where <directive> and <value> are variables,
and the entry in brackets is optional. Notice that for synthesis directives
there is no = sign before the value; this is different than the syntax for
synthesis attributes. The examples in this chapter demonstrate each
syntax form.
1
Verilog HDL is case-sensitive; therefore, all synthesis directives
are also case-sensitive.
Example 8–21. Synthesis Directives in Verilog HDL
// synthesis <directive> [ <value> ]
or
/* synthesis <directive> [ <value> ] */
Example 8–22. Synthesis Directives in VHDL
-- synthesis <directive> [ <value> ]
In addition to the synthesis keyword shown above, the pragma,
synopsys, and exemplar keywords are supported in both Verilog HDL
and VHDL for compatibility with other synthesis tools. The keyword
altera is also supported, which allows you to add synthesis directives
that will be recognized only by Quartus II integrated synthesis and not by
other tools that recognize the same synthesis directive.
1
Altera Corporation
October 2007
Because formal verification tools ignore keywords exemplar,
pragma, and altera, avoid using these directive keywords
when you are using formal verification to prevent mismatches
with the Quartus II results.
8–29
Quartus II Handbook, Volume 1
Optimization Technique
The Optimization Technique logic option specifies the goal for logic
optimization during compilation; that is, whether to attempt to achieve
maximum speed performance or minimum area usage, or a balance
between the two. Table 8–2 lists the settings for this logic option, which
you can apply only to a design entity. You can also set this logic option for
your whole project on the Analysis & Synthesis Settings page in the
Settings dialog box.
Table 8–2. Optimization Technique Settings
Setting
Description
Area
The Compiler makes the design as small as possible to minimize resource usage.
Speed
The Compiler chooses a design implementation that has the fastest fMAX.
Balanced (1)
The Compiler maps part of the design for area and part for speed, providing better area
utilization than optimizing for speed, with only a slightly slower fMAX than optimizing for speed.
Note to Table 8–2:
(1)
The balanced optimization technique is not supported for all device families.
The default setting varies by device family, and is generally optimized for
the best area/speed trade-off. Results are design-dependent and vary
depending on which device family you use.
Speed Optimization Technique for Clock Domains
The Speed Optimization Technique for Clock Domains logic option
specifies that all combinational logic in or between the specified clock
domain(s) is optimized for speed.
When this option is set on a particular clock signal, all the logic in this
clock domain is optimized for speed during synthesis. The remainder of
the design in other clock domains is synthesized with the project-wide
Optimization Technique that is set in the Analysis & Synthesis Settings.
The option can also be set from one clock to another clock signal, in which
case the logic in paths from registers in the first clock domain to registers
in the second clock domain are synthesized for speed. The advantage of
using this option over the project-wide setting to optimize for speed is
that there is less penalty to the area of the design because a smaller part
of the circuit is optimized for speed. This may also have a positive effect
on clock speed. This option also has an advantage over setting the
Optimization Technique on a design entity because that option forces
the hierarchical blocks to be synthesized separately. Doing so may
increase area and decrease performance due to the lack of optimizations
across hierarchies. The Speed Optimization Technique for Clock
8–30
Altera Corporation
October 2007
Quartus II Synthesis Options
Domains option does not treat hierarchical entities separately, and can
optimize across hierarchical boundaries for logic within the same clock
domain.
This option is useful if you have one or more clock domains that do not
meet your timing requirements. When there are failing paths within a
clock domain, the option can be set on the clock of that clock domain.
When there are failing paths between clock domains, the option can be set
from one clock domain to the other clock domain.
This option is available for the following device families: Arria™ GX,
Stratix® series, Cyclone® series, HardCopy® II, HardCopy Stratix, and
MAX® II.
PowerPlay Power Optimization
This logic option controls the power-driven compilation setting of
Analysis and Synthesis and determines how aggressively Analysis and
Synthesis optimizes the design for power. On the Assignments menu,
click Settings, and under Category, click Analysis & Synthesis Settings.
This displays the Analysis & Synthesis Settings page. The following
three settings are available for the PowerPlay Power Optimization
option:
■
■
■
Off—Analysis and Synthesis does not perform any power
optimizations.
Normal Compilation—Analysis and Synthesis performs power
optimizations, without reducing design performance.
Extra Effort—Analysis and Synthesis performs additional power
optimizations, which may reduce design performance.
This logic option is available for the following device families: Arria GX,
Stratix series, Cyclone series, HardCopy II, and MAX II.
f
Altera Corporation
October 2007
For more information about optimizing your design for power
utilization, refer to the Power Optimization chapter in volume 2 of the
Quartus II Handbook. For information about analyzing your power
results, refer to the PowerPlay Power Analysis chapter in volume 3 of the
Quartus II Handbook.
8–31
Quartus II Handbook, Volume 1
Restructure Multiplexers
This option specifies whether the Quartus II software should extract and
optimize buses of multiplexers during synthesis.
This option is useful if your design contains buses of fragmented
multiplexers. This option restructures multiplexers more efficiently for
area, allowing the design to implement multiplexers with a reduced
number of LEs or ALMs. This option is available for the following device
families: Arria GX, Stratix series, Cyclone series, HardCopy II, and
MAX II.
The Restructure Multiplexers option works on entire trees of
multiplexers. Multiplexers may arise in different parts of the design
through Verilog HDL or VHDL constructs such as the “if,” “case,” or
“?:” statements. When multiplexers from one part of the design feed
multiplexers in another part of the design, trees of multiplexers are
formed. Multiplexer buses occur most often as a result of multiplexing
together vectors in Verilog HDL, or STD_LOGIC_VECTOR signals in
VHDL. The Restructure Multiplexers option identifies buses of
multiplexer trees that have a similar structure. When it is turned on, the
Restructure Multiplexers option optimizes the structure of each
multiplexer bus for the target device to reduce the overall amount of logic
used in the design.
Results of the multiplexer optimizations are design dependent, but area
reductions as high as 20% are possible. The option may negatively affect
your design’s fMAX.
Table 8–3 lists the settings for the logic option, which you can apply only
to a design entity. You can also specify this option on the Analysis &
Synthesis Settings page in the Settings dialog box for your whole
project.
Table 8–3. Restructure Multiplexers Settings
Setting
Description
On
Enables multiplexer restructuring to minimize your design area. This setting may reduce the
fM A X .
Off
Disables multiplexer restructuring to avoid possible reductions in fM A X .
Auto (Default)
Allows the Compiler to determine whether to enable the option based on your other Quartus II
synthesis settings. The option is On when the Optimization Technique option is set to Area
or Balanced, and Off when the Optimization Technique option is Speed. (Note that since the
default Optimization Technique is Balanced for many device families, including the Stratix
series, this option is turned on by default for those families.)
8–32
Altera Corporation
October 2007
Quartus II Synthesis Options
After you have compiled your design, you can view multiplexer
restructuring information in the Multiplexer Restructuring Statistics
report in the Multiplexer Statistics folder under Analysis & Synthesis
Optimization Results in the Analysis & Synthesis section of the
Compilation Report. Table 8–4 describes the information that is listed in
the Multiplexer Restructuring Statistics report table for each bus of
multiplexers.
Table 8–4. Multiplexer Information in the Multiplexer Restructuring Statistics Report
Heading
Description
Multiplexer Inputs
The number of different choices that are multiplexed together.
Bus Width
The width of the bus in bits.
Baseline Area
An estimate of how many logic cells are needed to implement the bus of
multiplexers (before any multiplexer restructuring takes place). This estimate can
be used to identify any large multiplexers in the design.
Area if Restructured
An estimate of how many logic cells are needed to implement the bus of
multiplexers if Multiplexer Restructuring is applied.
Saving if Restructured
An estimate of how many logic cells are saved if Multiplexer Restructuring is
applied.
Registered
An indication of whether registers are present on the multiplexer outputs.
Multiplexer Restructuring uses the secondary control signals of a register (such
as synchronous clear and synchronous-load) to further reduce the amount of
logic needed to implement the bus of multiplexers.
Example Multiplexer Output
The name of one of the multiplexers’ outputs. This name can help determine
where in the design the multiplexer bus originated.
For more information about optimizing for multiplexers, refer to the
Multiplexers section of the Design Recommendations for Altera Devices and
the Quartus II Design Assistant chapter in volume 1 of the Quartus II
Handbook.
Altera Corporation
October 2007
8–33
Quartus II Handbook, Volume 1
State Machine Processing
This logic option specifies the processing style used to compile a state
machine. Table 8–5 lists the settings for this logic option, which you can
apply to a state machine name or to a design entity containing a state
machine. You can also set this option for your whole project on the
Analysis & Synthesis Settings page in the Settings dialog box.
Table 8–5. State Machine Processing Settings
Setting
Description
Auto (Default)
Allows the Compiler to choose what it determines to be the
best encoding for the state machine
Minimal Bits
Uses the least number of bits to encode the state machine
One-Hot
Encodes the state machine in the one-hot style. See the
example below for details.
User-Encoded
Encodes the state machine in the manner specified by the
user
Sequential
Uses a binary encoding in which the first enumeration literal
in the Enumeration Type has encoding 0, the second 1, and
so on.
Gray
Uses an encoding in which the encodings for adjacent
enumeration literals differ by exactly one bit. An N-bit gray
code can represent 2N values.
Johnson
Uses an encoding similar to a gray code, in which each state
only has one bit different from its neighboring states. Each
state is generated by shifting the previous state’s bits to the
right by 1; the most significant bit of each state is the negation
of the least significant bit of the previous state. An N-bit
Johnson code can represent at most 2N states but requires
less logic than a gray encoding.
The default state machine encoding, which is Auto, uses one-hot
encoding for FPGA devices and minimal-bits encoding for CPLDs. These
settings achieve the best results on average, but another encoding style
might be more appropriate for your design, so this option allows you to
control the state machine encoding.
f
For guidelines to ensure that your state machine is inferred and encoded
correctly, refer to the Recommended HDL Coding Styles chapter in
volume 1 of the Quartus II Handbook.
For one-hot encoding, the Quartus II software does not guarantee that
each state has one bit set to one and all other bits to zero. Quartus II
integrated synthesis creates one-hot register encoding by using standard
8–34
Altera Corporation
October 2007
Quartus II Synthesis Options
one-hot encoding and then inverting the first bit. This results in an initial
state with all zero values, and the remaining states have two 1 values.
Quartus II integrated synthesis encodes the initial state with all zeros for
the state machine power-up because all device registers power up to a
low value. This encoding has the same properties as true one-hot
encoding: each state can be recognized by the value of one bit. For
example, in a one-hot-encoded state machine with five states including
an initial or reset state, the software uses the following register encoding:
State
State
State
State
State
0
1
2
3
4
0
0
0
0
1
0
0
0
1
0
0
0
1
0
0
0
1
0
0
0
0
1
1
1
1
If the State Machine Processing logic option is set to User-Encoded in a
Verilog HDL design, the software starts with the original design values
for the state constants. For example, a Verilog HDL design can contain a
declaration such as the following:
parameter S0 = 4'b1010, S1 = 4'b0101, ...
If the software infers states S0, S1,... it uses the encoding 4'b1010,
4'b0101,... . If necessary, the software inverts bits in a user-encoded
state machine to ensure that all bits of the reset state of the state machine
are zero.
To assign your own state encoding with the User-Encoded setting of the
State Machine Processing option in a VHDL design, you must apply
specific binary encoding to the elements of an enumerated type because
enumeration literals have no numeric values in VHDL. Use the
syn_encoding synthesis attribute to apply your encoding values. Refer
to “Manually Specifying State Assignments Using the syn_encoding
Attribute” for more information.
For information about the Safe State Machine option, refer to “Safe State
Machines” on page 8–40.
Manually Specifying State Assignments Using the syn_encoding
Attribute
The Quartus II software infers state machines from enumerated types and
automatically assigns state encoding based on “State Machine
Processing” on page 8–34. With this logic option, you can choose the
value User-Encoded to use the encoding from your HDL code. However,
Altera Corporation
October 2007
8–35
Quartus II Handbook, Volume 1
in standard VHDL code, you cannot specify user encoding in the state
machine description because enumeration literals have no numeric
values in VHDL.
To assign your own state encoding for the User-Encoded State Machine
Processing setting, use the syn_encoding synthesis attribute to apply
specific binary encodings to the elements of an enumerated type or to
specify an encoding style. The Quartus II software can implement
Enumeration Types with the different encoding styles shown in
Table 8–6.
Table 8–6. syn_encoding Attribute Values
Attribute Value
"default"
Description
Use an encoding based on the number of enumeration literals
in the Enumeration Type. If there are fewer than five literals,
use the "sequential" encoding. If there are more than
five but fewer than 50 literals, use a "one-hot" encoding.
Otherwise, use a "gray" encoding.
"sequential" Use a binary encoding in which the first enumeration literal in
the Enumeration Type has encoding 0, the second 1, and so
on.
"gray"
Use an encoding in which the encodings for adjacent
enumeration literals differ by exactly one bit. An N-bit gray
code can represent 2N values.
"johnson"
Use an encoding similar to a gray code. An N-bit Johnson
code can represent at most 2N states but requires less logic
than a gray encoding.
"one-hot"
The default encoding style requiring N bits, where N is the
number of enumeration literals in the Enumeration Type.
"compact"
Use an encoding with the fewest bits.
The syn_encoding attribute must follow the enumeration type
definition but precede its use.
In Example 8–23, the syn_encoding attribute associates a binary
encoding with the states in the enumerated type count_state. In this
example, the states are encoded with the following values: zero = “11”,
one = “01”, two = “10”, three = “00”.
8–36
Altera Corporation
October 2007
Quartus II Synthesis Options
Example 8–23. Specifying User Encoded States with the syn_encoding Attribute in VHDL
ARCHITECTURE rtl OF my_fsm IS
TYPE count_state is (zero, one, two, three);
ATTRIBUTE syn_encoding : STRING;
ATTRIBUTE syn_encoding OF count_state : TYPE IS "11 01 10 00";
SIGNAL present_state, next_state : count_state;
BEGIN
You can also use the syn_encoding attribute in Verilog HDL to direct
the synthesis tool to use the encoding from your HDL code, instead of
using the State Machine Processing option.
The syn_encoding value “user” instructs the Quartus II software to
encode each state with its corresponding value from the Verilog source
code. By changing the values of your state constants, you can change the
encoding of your state machine.
Example 8–24. Specifying User Encoded States with the syn_encoding Attribute in Verilog-2001
(* syn_encoding = "user" *) reg [1:0] state;
parameter init = 0, last = 3, next = 1, later = 2;
always @ (state) begin
case (state)
init:
out = 2'b01;
next:
out = 2'b10;
later:
out = 2'b11;
last:
out = 2'b00;
endcase
end
In Example 8–24, the states will be encoded as follows:
init = "00"
last = "11"
next = "01"
later = "10"
Without the syn_encoding attribute, the Quartus II software would
encode the state machine based on the current value of the State Machine
Processing logic option.
Altera Corporation
October 2007
8–37
Quartus II Handbook, Volume 1
If you are also specifying a safe state machine (as described in “Safe State
Machines” on page 8–40), separate the encoding style value in the
quotation marks with the safe value with a comma, as follows: “safe,
one-hot” or “safe, gray”.
Manually Specifying Enumerated Types Using the
enum_encoding Attribute
By default, the Quartus II software one-hot encodes all user-defined
Enumerated Types. With the enum_encoding attribute, you can specify
the logic encoding for an Enumerated Type and override the default
one-hot encoding to improve the logic efficiency.
1
If an Enumerated Type represents the states of a state machine,
using the enum_encoding attribute to specify a manual state
encoding prevents the Compiler from recognizing state
machines based on the Enumerated Type. Instead, the Compiler
processes these state machines as “regular” logic using the
encoding specified by the attribute, and they are not listed as
state machines in the Report window for the project. If you wish
to control the encoding for a recognized state machine, use the
State Machine Processing logic option and the syn_encoding
synthesis attribute.
To use the enum_encoding attribute in a VHDL design file, associate the
attribute with the Enumeration Type whose encoding you want to
control. The enum_encoding attribute must follow the Enumeration
Type Definition but precede its use. In addition, the attribute value must
be a string literal that specifies either an arbitrary user encoding or an
encoding style of "default", "sequential", "gray", "johnson", or
"one-hot".
An arbitrary user encoding consists of a space-delimited list of encodings.
The list must contain as many encodings as there are enumeration literals
in your Enumeration Type. In addition, the encodings must all have the
same length, and each encoding must consist solely of values from the
std_ulogic type declared by the std_logic_1164 package in the
IEEE library. In the code fragment of Example 8–25, the
enum_encoding attribute specifies an arbitrary user encoding for the
Enumeration Type fruit.
Example 8–25. Specifying an Arbitrary User Encoding for Enumerated Type
type fruit is (apple, orange, pear, mango);
attribute enum_encoding : string;
attribute enum_encoding of fruit : type is "11 01 10 00";
8–38
Altera Corporation
October 2007
Quartus II Synthesis Options
In this example, the enumeration literals are encoded as:
apple
orange
pear
mango
=
=
=
=
"11"
"01"
"10"
"00"
You may wish to specify an encoding style, rather than a manual user
encoding, especially when the Enumeration Type has a large number of
enumeration literals. The Quartus II software can implement
Enumeration Types with the different encoding styles shown in
Table 8–7.
Table 8–7. enum_encoding Attribute Values
Attribute Value
"default"
Description
Use an encoding based on the number of enumeration literals
in the Enumeration Type. If there are fewer than five literals,
use the "sequential" encoding. If there are more than
five but fewer than 50 literals, use a "one-hot" encoding.
Otherwise, use a "gray" encoding.
"sequential" Use a binary encoding in which the first enumeration literal in
the Enumeration Type has encoding 0, the second 1, and so
on.
"gray"
Use an encoding in which the encodings for adjacent
enumeration literals differ by exactly one bit. An N-bit gray
code can represent 2N values.
"johnson"
Use an encoding similar to a gray code. An N-bit Johnson
code can represent at most 2N states but requires less logic
than a gray encoding.
"one-hot"
The default encoding style requiring N bits, where N is the
number of enumeration literals in the Enumeration Type.
Observe that in Example 8–25, the enum_encoding attribute manually
specified a gray encoding for the Enumeration Type fruit. This example
could be written more concisely by specifying the "gray" encoding style
instead of a manual encoding, as shown in Example 8–26.
Example 8–26. Specifying the “gray” Encoding Style or Enumeration Type
type fruit is (apple, orange, pear, mango);
attribute enum_encoding : string;
attribute enum_encoding of fruit : type is "gray";
Altera Corporation
October 2007
8–39
Quartus II Handbook, Volume 1
Safe State Machines
The Safe State Machine option and corresponding syn_encoding
attribute value safe specify that the software should insert extra logic to
detect an illegal state and force the state machine’s transition to the reset
state.
It is possible for a finite state machine to enter an illegal state—meaning
the state registers contain a value that does not correspond to any defined
state. By default, the behavior of the state machine that enters an illegal
state is undefined. However, you can set the syn_encoding attribute to
safe or use the Safe State Machine logic option if you want the state
machine to recover deterministically from an illegal state. Use this option
if you have asynchronous inputs to your state machine. The most
common cause of this situation is a state machine that has control inputs
that come from another clock domain, such as the control logic for a
clock-crossing FIFO, because the state machine must have inputs from
another clock domain. An alternative is to add synchronizer registers to
the inputs.
It is important to note that the safe state machine value does not use any
user-defined default logic from your HDL code that corresponds to
unreachable states. Verilog HDL and VHDL allow you to explicitly
specify a behavior for all states in the state machine, including
unreachable states. However, synthesis tools detect if state machine logic
is unreachable and minimize or remove the logic. Any flag signals or logic
used in the design to indicate such an illegal state are also removed. If the
state machine is implemented as safe, the recovery logic forces its
transition from an illegal state to the reset state.
The Safe State Machine option can be set globally, or on individual state
machines. To set this option, perform the following steps:
8–40
1.
On the Assignments menu, click Settings. The Settings dialog box
appears.
2.
In the Category list, select Analysis & Synthesis Settings. The
Analysis & Synthesis Settings page appears.
3.
Click More Settings. The More Analysis & Synthesis Settings
dialog box appears.
4.
In the Existing option settings list, select Safe State Machine.
5.
Under Option, in the Setting list, select On.
6.
Click OK.
Altera Corporation
October 2007
Quartus II Synthesis Options
7.
Click OK to close the Settings dialog box.
You can also use the Assignment Editor to turn on the Safe State Machine
option for specific state machines.
You can set the syn_encoding safe attribute on a state machine in
HDL, as shown in Example 8–27, 8–28, and 8–29.
Example 8–27. Verilog HDL Example of a Safe State Machine Attribute
reg [2:0] my_fsm /* synthesis syn_encoding = "safe" */;
Example 8–28. Verilog-2001 Example of a Safe State Machine Attribute
(* syn_encoding = "safe" *) reg [2:0] my_fsm;
Example 8–29. VHDL Example of a Safe State Machine Attribute
ATTRIBUTE syn_encoding OF my_fsm : TYPE IS "safe";
If you are also specifying an encoding style (as described in “Manually
Specifying State Assignments Using the syn_encoding Attribute” on
page 8–35), separate the encoding style value in the quotation marks with
the safe value with a comma, as follows: "safe, one-hot" or "safe,
gray".
Safe state machine implementation can result in a noticeable area increase
for the design. Therefore, Altera recommends that you set this option
only on the critical state machines in the design where the safe mode is
required, such as a state machine that uses inputs from asynchronous
clock domains. You can also reduce the necessity of this option by
correctly synchronizing inputs coming from other clock domains.
Note that if the safe state machine assignment is made on an instance
that is not recognized as a state machine, or an entity that contains a state
machine, the software takes no action. You must restructure the code so
that the instance is recognized and properly inferred as a state machine.
f
Altera Corporation
October 2007
For guidelines to ensure that your state machine is inferred correctly,
refer to the Recommended HDL Coding Styles chapter in volume 1 of the
Quartus II Handbook.
8–41
Quartus II Handbook, Volume 1
Power-Up Level
This logic option causes a register (flipflop) to power up with the
specified logic level, either High (1) or Low (0). Registers in the device
core hardware power up to 0 in all Altera devices. For the register to
power up with a logic level High specified using this option, the
Compiler performs an optimization referred to as NOT-gate push back on
the register. NOT-gate push back adds an inverter to the input and the
output of the register so that the reset and power-up conditions will
appear to be high and the device operates as expected. The register itself
still powers up low, but the register output is inverted so the signal
arriving at all destinations is high. This option is available for all Altera
devices supported by the Quartus II software except MAX® 3000A and
MAX 7000S devices.
The Power-Up Level option supports wildcard characters, and you can
apply this option to any register, registered logic cell WYSIWYG
primitive, or to a design entity containing registers if you want to set the
power level for all registers in the design entity. If this option is assigned
to a registered logic cell WYSIWYG primitive, such as an atom primitive
from a third-party synthesis tool, you must turn on the Perform
WYSIWYG Primitive Resynthesis logic option for it to take effect. You
can also apply the option to a pin with the logic configurations described
in the following list:
■
If this option is turned on for an input pin, the option is transferred
automatically to the register that is driven by the pin if the following
conditions are present:
●
There is no logic, other than inversion, between the pin and the
register
●
The input pin drives the data input of the register
●
The input pin does not fan-out to any other logic
■
If this option is turned on for an output or bidirectional pin, it is
transferred automatically to the register that feeds the pin, if the
following conditions are present:
●
There is no logic, other than inversion, between the register and
the pin
●
The register does not fan-out to any other logic
Inferred Power-Up Levels
Quartus II integrated synthesis reads default values for registered signals
defined in Verilog HDL and VHDL code, and converts the default values
into Power-Up Level settings. The software also synthesizes variables
that are assigned values in Verilog HDL initial blocks into power-up
8–42
Altera Corporation
October 2007
Quartus II Synthesis Options
conditions. Synthesis of these default and initial constructs enables the
design’s synthesized behavior to match, as closely as possible, the
power-up state of the HDL code during a functional simulation.
For example, the following register declarations all set a power-up level
of VCC or a logic value "1":
signal q : std_logic = '1';
reg q = 1'b1;
// power-up to VCC
reg q;
initial begin q = 1'b1; end
f
-- power-up to VCC
// power-up to VCC
For more information about NOT gate push-back, the power-up states for
Altera devices, and how the power-up level is affected by set and reset
control signals, refer to Recommended HDL Coding Styles chapter in
volume 1 of the Quartus II Handbook.
Power-Up Don’t Care
This logic option allows the compiler to optimize registers in the design
which do not have a defined power-up condition. This option is turned
on by default.
For example, your design may have a register with its D input tied to VCC,
and with no clear signal or other secondary signals. If this option is
enabled, the compiler can choose for the register to power up to VCC.
Therefore, the output of the register is always VCC. The compiler can
remove the register and connect its output to VCC. If you turn this option
off or if you set a Power-Up Level assignment of low for this register, the
register transitions from GND to VCC when the design starts up on the
first clock signal. Thus, the register is not stuck at VCC and cannot be
removed. Similarly, if the register has a clear signal, it will not be removed
because after the clear is asserted, the register will again transition to
GND and back to VCC.
If the Compiler performs a Power-Up Don’t Care optimization that
allows it to remove a register, it issues a message indicating it is doing so.
This project-wide option does not apply to registers that have the
Power-Up Level logic option set to either High or Low.
Altera Corporation
October 2007
8–43
Quartus II Handbook, Volume 1
Remove Duplicate Registers
If you turn on this logic option, the Compiler removes registers that are
identical to another register. If two registers generate the same logic, the
Compiler removes the second one, and the first one fans out to the second
one’s destinations. Also, if the deleted register has different logic option
assignments, the Compiler ignores them. This option is turned on by
default.
Typically, you should use this option only if you want to prevent the
Compiler from removing duplicate registers. That is, you should use this
option only with the Off setting. You can apply this option to an
individual register or a design entity that contains registers.
Remove Redundant Logic Cells
This logic option removes redundant LCELL primitives or WYSIWYG
cells. The option is off by default to preserve logic cells that have been
used intentionally. If you turn on this option, the Compiler optimizes a
circuit for area and speed. You can set this option globally or apply it to
individual nodes and entities. If you turn on the option at the global level,
you can use the keep attribute or Implement as Output of Logic Cell
logic option to preserve specific wire signals or nodes (refer to “Keep
Combinational Node/Implement as Output of Logic Cell” on page 8–47).
Preserve Registers
This attribute and logic option directs the Compiler not to minimize or
remove a specified register during synthesis optimizations or register
netlist optimizations. Optimizations can eliminate redundant registers
and registers with constant drivers; this option prevents a register from
being reduced to a constant or merged with a duplicate register. This
option can preserve a register so you can observe it during simulation or
with the SignalTap II logic analyzer. Additionally, it can preserve registers
if you are creating a preliminary version of the design in which secondary
signals are not specified. You can also use the attribute to preserve a
duplicate of an I/O register so that one copy can be placed in an I/O cell
and the second can be placed in the core. By default, the software may
remove one of the two duplicate registers. In this case, the preserve
attribute can be added to both registers to prevent this.
1
8–44
This option cannot preserve registers that have no fan-out. To
prevent the removal of registers with no fan-out, refer to
“Noprune Synthesis Attribute/Preserve Fan-out Free Register
Node” on page 8–46.
Altera Corporation
October 2007
Quartus II Synthesis Options
The Preserve Registers option prevents a register from being
inferred as a state machine.
You can set the Preserve Registers logic option in the Quartus II GUI or
you can set the preserve attribute in your HDL code, as shown in
Example 8–30, 8–31, and 8–32. In these examples, the my_reg register is
preserved.
1
In addition to preserve, the Quartus II software supports the
syn_preserve attribute name for compatibility with other
synthesis tools.
Example 8–30. Verilog HDL Example of a syn_preserve Attribute
reg my_reg /* synthesis syn_preserve = 1 */;
Example 8–31. Verilog-2001 Example of a syn_preserve Attribute
(* syn_preserve = 1 *) reg my_reg;
1
The " = 1" after the "preserve" in Example 8–30 and 8–31 is
optional, because the assignment uses a default value of 1 when
it is specified.
Example 8–32. VHDL Example of a preserve Attribute
signal my_reg : stdlogic;
attribute preserve : boolean;
attribute preserve of my_reg : signal is true;
Disable Register Merging/Don’t Merge Register
This logic option and attribute prevents the specified register from being
merged with other registers, and prevents other registers from being
merged with the specified register. When applied to a design entity, it
applies to all registers in the entity.
You can use this option to instruct the Compiler to correctly use your
timing constraints for the register during synthesis. For example, if the
register has a multicycle constraint, this option prevents the Compiler
from merging other registers into the specified register, avoiding
unintended timing effects and functional differences.
Altera Corporation
October 2007
8–45
Quartus II Handbook, Volume 1
This option differs from the Preserve Register option because it does not
prevent a register with constant drivers or a redundant register from
being removed. In addition, this option prevents other registers from
merging with the specified register.
You can set the Disable Register Merging logic option in the Quartus II
GUI, or you can set the dont_merge attribute in your HDL code, as
shown in Example 8–33, 8–34, and 8–35. In these examples, the my_reg
register is prevented from merges.
Example 8–33. Verilog HDL Example of a dont_merge Attribute
reg my_reg /* synthesis dont_merge */;
Example 8–34. Verilog-2001 Example of a dont_merge Attribute
(* dont_merge *) reg my_reg;
Example 8–35. VHDL Example of a dont_merge Attribute
signal my_reg : stdlogic;
attribute dont_merge : boolean;
attribute dont_merge of my_reg : signal is true;
Noprune Synthesis Attribute/Preserve Fan-out Free Register
Node
This synthesis attribute and corresponding logic option direct the
Compiler to preserve a fan-out-free register through the entire
compilation flow. This is different from the Preserve Registers option,
which prevents a register from being reduced to a constant or merged
with a duplicate register. Standard synthesis optimizations remove nodes
that do not directly or indirectly feed a top-level output pin. This option
can retain a register so you can observe it in the Simulator or the
SignalTap II logic analyzer. Additionally, it can retain registers if you are
creating a preliminary version of the design in which the registers’
fan-out logic is not specified. This option is supported for inferred
registers in the following device families: Arria GX, Stratix series,
Cyclone series, and MAX II.
You can set the Preserve Fan-out Free Register Node logic option in the
Quartus II GUI, or you can set the noprune attribute in your HDL code,
as shown in Example 8–36, 8–37, and 8–38. In these examples, the my_reg
register is preserved.
8–46
Altera Corporation
October 2007
Quartus II Synthesis Options
1
You must use the noprune attribute instead of the logic option
if the register has no immediate fan-out in its module or entity.
If you do not use the synthesis attribute, registers with no
fan-out are removed (or “pruned”) during analysis and
elaboration before the logic synthesis stage applies any logic
options. If the register has no fan-out in the full design, but has
fan-out within its module or entity, you can use the logic option
to retain the register through compilation.
The attribute name syn_noprune is supported for
compatibility with other synthesis tools.
Example 8–36. Verilog HDL Example of a syn_noprune Attribute
reg my_reg /* synthesis syn_noprune */;
Example 8–37. Verilog-2001 Example of a noprune Attribute
(* noprune *) reg my_reg;
Example 8–38. VHDL Example of a noprune Attribute
signal my_reg : stdlogic;
attribute noprune: boolean;
attribute noprune of my_reg : signal is true;
Keep Combinational Node/Implement as Output of Logic Cell
This synthesis attribute and corresponding logic option direct the
Compiler to keep a wire or combinational node through logic synthesis
minimizations and netlist optimizations. A wire that has a keep attribute
or a node that has the Implement as Output of Logic Cell logic option
applied becomes the output of a logic cell in the final synthesis netlist, and
the name of the logic cell will be the same as the name of the wire or node.
You can use this directive to make combinational nodes visible to the
SignalTap II logic analyzer.
1
The option cannot keep nodes that have no fan-out. Node names
cannot be maintained for wires with tri-state drivers, or if the
signal feeds a top-level pin of the same name (in this case the
node name is changed to a name such as <net name>~buf0).
You can set the Implement as Output of Logic Cell logic option in the
Quartus II GUI, or you can set the keep attribute in your HDL code, as
shown in Example 8–39, 8–40, and 8–41. In these examples, the Compiler
maintains the node name my_wire.
Altera Corporation
October 2007
8–47
Quartus II Handbook, Volume 1
1
In addition to keep, the Quartus II software supports the
syn_keep attribute name for compatibility with other synthesis
tools.
Example 8–39. Verilog HDL Example of a keep Attribute
wire my_wire /* synthesis keep = 1 */;
Example 8–40. Verilog-2001 Example of a keep Attribute
(* keep = 1 *) wire my_wire;
Example 8–41. VHDL Example of a syn_keep Attribute
signal my_wire: bit;
attribute syn_keep: boolean;
attribute syn_keep of my_wire: signal is true;
Don't Retime, Disabling Synthesis Netlist Optimizations
This attribute disables synthesis retiming optimizations on the specified
register. When applied to a design entity, it applies to all registers in the
entity.
You can use this option to turn off retiming optimizations and prevent
node name changes so that the Compiler can correctly use your timing
constraints for the register.
You can set the Netlist Optimizations logic option to Never Allow in the
Quartus II GUI to disable retiming along with other synthesis netlist
optimizations, or you can set the dont_retime attribute in your HDL
code, as shown in Example 8–42 and 8–43. In these examples, the my_reg
register is prevented from being retimed.
Example 8–42. Verilog HDL Example of a dont_retime Attribute
reg my_reg /* synthesis dont_retime */;
Example 8–43. Verilog-2001 Example of a dont_retime Attribute
(* dont_retime *) reg my_reg;
8–48
Altera Corporation
October 2007
Quartus II Synthesis Options
Example 8–44. VHDL Example of a dont_retime Attribute
signal my_reg : std_logic;
attribute dont_retime : boolean;
attribute dont_retime of my_reg : signal is true;
1
For compatibility with third-party synthesis tools, Quartus II
integrated synthesis also supports the attribute
syn_allow_retiming. To disable retiming, set
syn_allow_retiming to 0 (Verilog) or false (VHDL). This
attribute does not have any effect when set to 1 or true.
Don't Replicate, Disabling Synthesis Netlist Optimizations
This attribute disables synthesis replication optimizations on the
specified register. When applied to a design entity, it applies to all
registers in the entity.
You can use this option to turn off register replication (or duplication)
optimizations so that the Compiler can use your timing constraints for the
register.
You can set the Netlist Optimizations logic option to Never Allow in the
Quartus II GUI to disable replication along with other synthesis netlist
optimizations, or you can set the dont_replicate attribute in your
HDL code, as shown in Example 8–45 and 8–46. In these examples, the
my_reg register is prevented from being replicated.
Example 8–45. Verilog HDL Example of a dont_replicate Attribute
reg my_reg /* synthesis dont_replicate */;
Example 8–46. Verilog-2001 Example of a dont_replicate Attribute
(* dont_replicate *) reg my_reg;
Example 8–47. VHDL Example of a dont_replicate Attribute
signal my_reg : std_logic;
attribute dont_replicate : boolean;
attribute dont_replicate of my_reg : signal is true;
Altera Corporation
October 2007
8–49
Quartus II Handbook, Volume 1
1
For compatibility with third-party synthesis tools, Quartus II
integrated synthesis also supports the attribute
syn_replicate. To disable replication, set syn_replicate
to 0 (Verilog) or false (VHDL). This attribute does not have
any effect when set to 1 or true.
Maximum Fan-Out
This attribute and logic option directs the Compiler to control the number
of destinations fed by a node. The Compiler duplicates a node and splits
its fan-out until the individual fan-out of each copy falls below the
maximum fan-out restriction. You can apply this option to a register or a
logic cell buffer, or to a design entity that contains these elements. You can
use this option to reduce the load of critical signals, which can improve
performance. You can use the option to instruct the Compiler to duplicate
(or replicate) a register that feeds nodes in different locations on the target
device. Duplicating the register may allow the Fitter to place these new
registers closer to their destination logic, minimizing routing delay.
This option is available for all devices supported in the Quartus II
software except MAX 3000, MAX 7000, FLEX 10K®, ACEX® 1K, and
Mercury™ devices. To turn off the option for a given node if the option is
set at a higher level of the design hierarchy, in the Netlist Optimizations
logic option, select Never Allow. If not disabled by the Netlist
Optimizations option, the maximum fan-out constraint is honored as
long as the following conditions are met:
■
■
■
The node is not part of a cascade, carry, or register cascade chain
The node does not feed itself
The node feeds other logic cells, DSP blocks, RAM blocks, and/or
pins through data, address, clock enable, etc, but not through any
asynchronous control ports (such as asynchronous clear)
The software does not create duplicate nodes in these cases either because
there is no clear way to duplicate the node, or, to avoid the possible
situation that small differences in timing could produce functional
differences in the implementation (in the third condition above where
asynchronous control signals are involved). If the constraint cannot be
applied because one of these conditions is not met, the Quartus II
software issues a message indicating that it ignored maximum fan-out
assignment. To instruct the software not to check the node’s destinations
for possible problems like the third condition, you can set the Netlist
Optimizations logic option to Always Allow for a given node.
8–50
Altera Corporation
October 2007
Quartus II Synthesis Options
1
f
If you have enabled any of the Quartus II netlist optimizations
that affect registers, add the preserve attribute to any registers
to which you have set a maxfan attribute. The preserve
attribute ensures that the registers are not affected by any of the
netlist optimization algorithms, such as register retiming.
For details about netlist optimizations, refer to the Netlist Optimization
and Physical Synthesis chapter in volume 2 of the Quartus II Handbook.
You can set the Maximum Fan-Out logic option in the Quartus II GUI,
and this option supports wildcard characters. You can also set the
maxfan attribute in your HDL code, as shown in Example 8–48, 8–49,
and 8–50. In these examples, the Compiler duplicates the clk_gen
register, so its fan-out is not greater than 50.
1
In addition to maxfan, the Quartus II software supports the
syn_maxfan attribute name for compatibility with other
synthesis tools.
Example 8–48. Verilog HDL Example of a syn_maxfan Attribute
reg clk_gen /* synthesis syn_maxfan = 50 */;
Example 8–49. Verilog-2001 Example of a maxfan Attribute
(* maxfan = 50 *) reg clk_gen;
Example 8–50. VHDL Example of a maxfan Attribute
signal clk_gen : stdlogic;
attribute maxfan : signal ;
attribute maxfan of clk_gen : signal is 50;
Controlling Clock Enable Signals with Auto Clock Enable
Replacement and direct_enable
The Auto Clock Enable Replacement logic option allows the software to
find logic that feeds a register and move the logic to the register’s clock
enable input port. The option is on by default. You can set this option to
Off for individual registers or design entities to solve fitting or
performance issues with designs that have many clock enables. Turning
the option off prevents the software from using the register’s clock enable
port, and the software implements the clock enable functionality using
multiplexers in logic cells.
Altera Corporation
October 2007
8–51
Quartus II Handbook, Volume 1
If specific logic is not automatically moved to a clock enable input with
the Auto Clock Enable Replacement logic option, you can instruct the
software to use a direct clock enable signal. Applying the
direct_enable attribute to a specific signal instructs the software to
use the clock enable port of a register to implement the signal. The
attribute ensures that the clock enable port is driven directly by the signal,
and the signal is not optimized or combined with any other logic.
Example 8–51, 8–52, and 8–53 show how to set this attribute to ensure that
the signal is preserved and used directly as a clock enable.
1
In addition to direct_enable, the Quartus II software
supports the syn_direct_enable attribute name for
compatibility with other synthesis tools.
Example 8–51. Verilog HDL Example of a direct_enable attribute
wire my_enable /* synthesis direct_enable = 1 */ ;
Example 8–52. Verilog-2001 Example of a syn_direct_enable attribute
(* syn_direct_enable *) wire my_enable;
Example 8–53. VHDL Example of a direct_enable attribute
attribute direct_enable: boolean;
attribute direct_enable of my_enable: signal is true;
Megafunction Inference Control
The Quartus II Compiler automatically recognizes certain types of HDL
code and infers the appropriate megafunction. The software uses the
Altera megafunction code when compiling your design, even when you
do not specifically instantiate the megafunction. The software infers
megafunctions to take advantage of logic that is optimized for Altera
devices. The area and performance of such logic may be better than the
results obtained by inferring generic logic from the same HDL code.
Additionally, you must use megafunctions to access certain
architecture-specific features, such as RAM, digital signal processing
(DSP) blocks, and shift registers, that generally provide improved
performance compared with basic logic cells.
f
8–52
For details about coding style recommendations when targeting
megafunctions in Altera devices, refer to the Recommended HDL Coding
Styles chapter in volume 1 of the Quartus II Handbook.
Altera Corporation
October 2007
Quartus II Synthesis Options
The Quartus II software provides options to control the inference of
certain types of megafunctions, as described in the following subsections.
Multiply-Accumulators and Multiply-Adders
Use the Auto DSP Block Replacement logic option to control DSP block
inference for multiply-accumulations and multiply-adders. This option is
turned on by default. To disable inference, turn off this option for your
whole project on the Analysis & Synthesis Settings page of the Settings
dialog box, or disable the option for a specific block with the Assignment
Editor.
1
Any registers that the software maps to the altmult_accum and
altmult_add megafunctions and places in DSP blocks are not
available in the Simulator because their node names do not exist
after synthesis.
Shift Registers
Use the Auto Shift Register Replacement logic option to control shift
register inference. This option is turned on by default. To disable
inference, turn off this option for your whole project on the Analysis &
Synthesis Settings page of the Settings dialog box, or for a specific block
with the Assignment Editor. The software may not infer small shift
registers because small shift registers typically do not benefit from
implementation in dedicated memory. However, you can use the Allow
Any Shift Register Size for Recognition logic option to instruct
synthesis to infer a shift register even when its size is considered too
small.
1
The registers that the software maps to the altshift_taps
megafunction and places in RAM are not available in the
Simulator because their node names do not exist after synthesis.
The Auto Shift Register Replacement logic option is turned off
automatically when a formal verification tool is selected in the
EDA Tool Settings. The software issues a warning and lists shift
registers that would have been inferred if no formal verification
tool was selected in the compilation report. To allow the use of a
megafunction for the shift register in the formal verification
flow, you can either instantiate a shift register explicitly using
the MegaWizard® Plug-in Manager or black box the shift
register in a separate entity/module.
Altera Corporation
October 2007
8–53
Quartus II Handbook, Volume 1
RAM and ROM
Use the Auto RAM Replacement and Auto ROM Replacement logic
options to control RAM and ROM inference, respectively. These options
are turned on by default. To disable inference, turn off the appropriate
option for your whole project on the Analysis & Synthesis Settings page
of the Settings dialog box, or disable the option for a specific block with
the Assignment Editor.
1
Although inferred shift registers are implemented in RAM
blocks, you cannot turn off the Auto RAM replacement option to
disable shift register replacement. Use the Auto Shift Register
Replacement option (refer to “Shift Registers”).
The software may not infer very small RAM or ROM blocks because very
small memory blocks can typically be implemented more efficiently by
using the registers in the logic. However, you can use the Allow Any
RAM Size for Recognition and Allow Any ROM Size for Recognition
logic options to instruct synthesis to infer a memory block even when its
size is considered too small.
1
The Auto ROM Replacement logic option is automatically
turned off when a formal verification tool is selected in the EDA
Tool Settings page. A warning is issued and a report panel lists
ROMs that would have been inferred if no formal verification
tool was selected. To allow the use of a megafunction for the
shift register in the formal verification flow, you can either
instantiate a ROM explicitly using the MegaWizard Plug-In
Manager or create a black box for the ROM in a separate
entity/module.
Although formal verification tools do not support inferred RAM blocks,
because of the importance of inferring RAM in many designs, the Auto
RAM Replacement logic option remains on when a formal verification
tool is selected in the EDA Tool Settings page. The Quartus II software
automatically black boxes any module or entity that contains a RAM
block that is inferred. The software issues a warning and lists the
black box that is created in the compilation report. This block box allows
formal verification tools to proceed; however, the entire module or entity
containing the RAM cannot be verified in the tool. Altera recommends
that you explicitly instantiate RAM blocks in separate modules or entities
so that as much logic as possible can be verified by the formal verification
tool.
8–54
Altera Corporation
October 2007
Quartus II Synthesis Options
RAM to Logic Cell Conversion
The Auto RAM to Logic Cell Conversion option allows the Quartus II
integrated synthesis to convert RAM blocks that are small in size to logic
cells if the logic cell implementation is deemed to give better quality of
results. Only single-port or simple-dual port RAMs with no initialization
files can be converted to logic cells. This option is off by default. You can
set this option globally or apply it to individual RAM nodes.
For FLEX 10K, APEX, Arria GX, and the Stratix series of devices, the
software uses the following rules to determine whether a RAM should be
placed in logic cells or a dedicated RAM block:
■
■
■
If the number of words is less than 16, use a RAM block if the total
number of bits is greater than or equal to 64.
If the number of words is greater than or equal to 16, use a RAM
block if the total number of bits is greater than or equal to 32.
Otherwise, implement the RAM in logic cells.
For the Cyclone series of devices, the software uses the following rules:
■
■
■
If the number of words is greater than or equal to 64, use a RAM
block.
If the number of words is greater than or equal to 16 and less than 64,
use a RAM block if the total number of bits is greater than or equal to
128.
Otherwise, implement the RAM in logic cells.
RAM Style and ROM Style—for Inferred Memory
These attributes specify the implementation for an inferred RAM or ROM
block. You can specify the type of TriMatrix™ embedded memory block
to be used, or specify the use of standard logic cells (LEs or ALMs). The
attributes are supported only for device families with TriMatrix
embedded memory blocks.
The ramstyle and romstyle attributes take a single string value. The
values "M512", "M4K", "M-RAM", "MLAB", "M9K", and "M144K" (as
applicable for the target device family) indicate the type of memory block
to use for the inferred RAM or ROM. If you set the attribute to a block
type that does not exist in the target device family, the software generates
a warning and ignores the assignment. The value logic indicates that
the RAM or ROM should be implemented in regular logic rather than
dedicated memory blocks. You can set the attribute on a module or entity,
in which case it specifies the default implementation style for all inferred
memory blocks in the immediate hierarchy. You can also set the attribute
Altera Corporation
October 2007
8–55
Quartus II Handbook, Volume 1
on a specific signal (VHDL) or variable (Verilog HDL) declaration, in
which case it specifies the preferred implementation style for that specific
memory, overriding the default implementation style.
1
If you specify a value of logic, the memory still appears as a
RAM or ROM block in the RTL Viewer, but it is converted to
regular logic during a later synthesis step.
In addition to ramstyle and romstyle, the Quartus II
software supports the syn_ramstyle attribute name for
compatibility with other synthesis tools.
Example 8–54, 8–55, and 8–56 specify that all memory in the module or
entity my_memory_blocks should be implemented using a specific type
of block.
Example 8–54. Verilog-1995 Example of Applying a romstyle Attribute to a Module Declaration
module my_memory_blocks (...) /* synthesis romstyle = "M4K" */
Example 8–55. Verilog-2001 Example of Applying a ramstyle Attribute to a Module Declaration
(* ramstyle = "M512" *) module my_memory_blocks (...);
Example 8–56. VHDL Example of Applying a romstyle Attribute to an Architecture
architecture rtl of my_ my_memory_blocks is
attribute romstyle : string;
attribute romstyle of rtl : architecture is "M-RAM";
begin
Example 8–57, 8–58, and 8–59 specify that the inferred memory my_ram
or my_rom should be implemented using regular logic instead of a
TriMatrix memory block.
Example 8–57. Verilog-1995 Example of Applying a syn_ramstyle Attribute to a Variable Declaration
reg [0:7] my_ram[0:63] /* synthesis syn_ramstyle = "logic" */;
Example 8–58. Verilog-2001 Example of Applying a romstyle Attribute to a Variable Declaration
(* romstyle = "logic" *) reg [0:7] my_rom[0:63];
8–56
Altera Corporation
October 2007
Quartus II Synthesis Options
Example 8–59. VHDL Example of Applying a ramstyle Attribute to a Signal Declaration
type memory_t is array (0 to 63) of std_logic_vector (0 to 7);
signal my_ram : memory_t;
attribute ramstyle : string;
attribute ramstyle of my_ram : signal is "logic";
Turning Off Add Pass-Through Logic to Inferred RAMs/
no_rw_check Attribute Setting
Setting the no_rw_check value for the ramstyle attribute, or turning
off the corresponding global logic option Add Pass-Through Logic to
Inferred RAMs indicates that your design does not depend on the
behavior of the inferred RAM when there are reads and writes to the same
address in the same clock cycle. If you specify the attribute or turn off the
logic option, the Quartus II software can choose a read-during-write
behavior instead of using the read-during-write behavior of your HDL
source code.
In some cases, an inferred RAM must be mapped into regular logic cells
because it has a read-during-write behavior that is not supported by the
TriMatrix memory blocks in your target device. In other cases, the
Quartus II software must insert extra logic to mimic read-during-write
behavior of the HDL source, increasing the area of your design and
potentially reducing its performance. In these cases, you can use the
attribute to specify that the software can implement the RAM directly in
a TriMatrix memory block without using logic. You can also use the
attribute to prevent a warning message for dual-clock RAMs in the case
that the inferred behavior in the device does not exactly match the
read-during-write conditions described in the HDL code.
f
For more information about recommended styles for inferring RAM and
some of the issues involved with different read-during-write conditions,
refer to the Recommended HDL Coding Styles chapter in volume 1 of the
Quartus II Handbook.
To set the Add Pass-Through Logic to Inferred RAMs logic option
through the Quartus II GUI, click More Settings on the Analysis &
Synthesis Settings page of the Settings dialog box. Example 8–60 and
8–61 use two addresses and normally require extra logic after the RAM to
ensure that the read-during-write conditions in the device match the
HDL code. If you don’t require a defined read-during-write condition in
your design, this extra logic is not required. With the no_rw_check
attribute, Quartus II integrated synthesis won’t generate the extra logic.
Altera Corporation
October 2007
8–57
Quartus II Handbook, Volume 1
Example 8–60. Verilog HDL Inferred RAM Using no_rw_check Attribute
module ram_infer (q, wa, ra, d, we, clk);
output [7:0] q;
input [7:0] d;
input [6:0] wa;
input [6:0] ra;
input we, clk;
reg [6:0] read_add;
(* ramstyle = "no_rw_check" *) reg [7:0] mem [127:0];
always @ (posedge clk) begin
if (we)
mem[wa] <= d;
read_add <= ra;
end
assign q = mem[read_add];
endmodule
Example 8–61. VHDL Inferred RAM Using no_rw_check Attribute
LIBRARY ieee;
USE ieee.std_logic_1164.ALL;
ENTITY ram IS
PORT (
clock: IN STD_LOGIC;
data: IN STD_LOGIC_VECTOR (2 DOWNTO 0);
write_address: IN INTEGER RANGE 0 to 31;
read_address: IN INTEGER RANGE 0 to 31;
we: IN STD_LOGIC;
q: OUT STD_LOGIC_VECTOR (2 DOWNTO 0)
);
END ram;
ARCHITECTURE rtl OF ram IS
TYPE MEM IS ARRAY(0 TO 31) OF STD_LOGIC_VECTOR(2 DOWNTO 0);
SIGNAL ram_block: MEM;
ATTRIBUTE ramstyle : string;
ATTRIBUTE ramstyle of ram_block : signal is "no_rw_check";
SIGNAL read_address_reg: INTEGER RANGE 0 to 31;
BEGIN
PROCESS (clock)
BEGIN
IF (clock'event AND clock = '1') THEN
IF (we = '1') THEN
ram_block(write_address) <= data;
END IF;
read_address_reg <= read_address;
END IF;
END PROCESS;
q <= ram_block(read_address_reg);
END rtl;
8–58
Altera Corporation
October 2007
Quartus II Synthesis Options
RAM Initialization File—for Inferred Memory
The ram_init_file attribute specifies the initial contents of an inferred
memory in the form of a Memory Initialization File (.mif). The attribute
takes a string value containing the name of the RAM initialization file.
Example 8–62. Verilog-1995 Example of Applying a ram_init_file Attribute
reg [7:0] mem[0:255] /* synthesis ram_init_file
= " my_init_file.mif" */;
Example 8–63. Verilog-2001 Example of Applying a ram_init_file Attribute
(* ram_init_file = "my_init_file.mif" *) reg [7:0] mem[0:255];
Example 8–64. VHDL Example of Applying a ram_init_file Attribute
type mem_t is array(0 to 255) of unsigned(7 downto 0);
signal ram : mem_t;
attribute ram_init_file : string;
attribute ram_init_file of ram :
signal is "my_init_file.mif";
1
In VHDL, you can also initialize the contents of an inferred
memory by specifying a default value for the corresponding
signal. In Verilog HDL, you can use an initial block to specify the
memory contents. Quartus II integrated synthesis automatically
converts the default value into a MIF for the inferred RAM.
Multiplier Style—for Inferred Multipliers
The multstyle attribute specifies the implementation style for
multiplication operations (*) in your HDL source code. You can use this
attribute to specify whether you prefer the Compiler to implement a
multiplication operation in general logic or dedicated hardware, if
available in the target device.
The multstyle attribute takes a string value of "logic" or "dsp",
indicating a preferred implementation in logic or in dedicated hardware,
respectively. In Verilog HDL, apply the attribute to a module declaration,
a variable declaration, or a specific binary expression containing the
* operator. In VHDL, apply the synthesis attribute to a signal, variable,
entity, or architecture.
Altera Corporation
October 2007
8–59
Quartus II Handbook, Volume 1
1
Specifying a multstyle of "dsp" does not guarantee that the
Quartus II software can implement a multiplication in dedicated
DSP hardware. The final implementation depends on several
things, including the availability of dedicated hardware in the
target device, the size of the operands, and whether or not one
or both operands are constant.
In addition to multstyle, the Quartus II software supports the
syn_multstyle attribute name for compatibility with other
synthesis tools.
When applied to a Verilog HDL module declaration, the attribute
specifies the default implementation style for all instances of the
* operator in the module. For example, in the following code examples,
the multstyle attribute directs the Quartus II software to implement all
multiplications inside module my_module in dedicated multiplication
hardware.
Example 8–65. Verilog-1995 Example of Applying a multstyle Attribute to a Module Declaration
module my_module (...) /* synthesis multstyle = "dsp" */;
Example 8–66. Verilog-2001 Example of Applying a multstyle Attribute to a Module Declaration
(* multstyle = "dsp" *) module my_module(...);
When applied to a Verilog HDL variable declaration, the attribute
specifies the implementation style to be used for a multiplication operator
whose result is directly assigned to the variable. It overrides the
multstyle attribute associated with the enclosing module, if present. In
Example 8–67 and 8–68, the multstyle attribute applied to variable
result directs the Quartus II software to implement a * b in general
logic rather than dedicated hardware.
Example 8–67. Verilog-2001 Example of Applying a multstyle Attribute to a Variable Declaration
wire [8:0] a, b;
(* multstyle = "logic" *) wire [17:0] result;
assign result = a * b; //Multiplication must be
//directly assigned to result
Example 8–68. Verilog-1995 Example of Applying a multstyle Attribute to a Variable Declaration
wire [8:0] a, b;
wire [17:0] result /* synthesis multstyle = "logic" */;
assign result = a * b; //Multiplication must be
//directly assigned to result
8–60
Altera Corporation
October 2007
Quartus II Synthesis Options
When applied directly to a binary expression containing the * operator,
the attribute specifies the implementation style for that specific operator
alone and overrides any multstyle attribute associated with the target
variable or enclosing module. In Example 8–69, the multstyle attribute
indicates that a * b should be implemented in dedicated hardware.
Example 8–69. Verilog-2001 Example of Applying a multstyle Attribute to a Binary Expression
wire [8:0] a, b;
wire [17:0] result;
assign result = a * (* multstyle = "dsp" *) b;
1
You cannot use Verilog-1995 attribute syntax to apply the
multstyle attribute to a binary expression.
When applied to a VHDL entity or architecture, the attribute specifies the
default implementation style for all instances of the * operator in the
entity or architecture. In Example 8–70, the multstyle attribute directs
the Quartus II software to use dedicated hardware, if possible, for all
multiplications inside architecture rtl of entity my_entity.
Example 8–70. VHDL Example of Applying a multstyle Attribute to an Architecture
architecture rtl of my_entity is
attribute multstyle : string;
attribute multstyle of rtl : architecture is "dsp";
begin
When applied to a VHDL signal or variable, the attribute specifies the
implementation style to be used for all instances of the * operator whose
result is directly assigned to the signal or variable. It overrides the
multstyle attribute associated with the enclosing entity or architecture,
if present. In Example 8–71, the multstyle attribute associated with
signal result directs the Quartus II software to implement a * b in
general logic rather than dedicated hardware.
Example 8–71. VHDL Example of Applying a multstyle Attribute to a Signal or Variable
signal a, b : unsigned(8 downto 0);
signal result : unsigned(17 downto 0);
attribute multstyle : string;
attribute multstyle of result : signal is "logic";
result <= a * b;
Altera Corporation
October 2007
8–61
Quartus II Handbook, Volume 1
Full Case
A Verilog HDL case statement is considered full when its case items cover
all possible binary values of the case expression or when a default case
statement is present. A full_case attribute attached to a case statement
header that is not full forces the unspecified states to be treated as a “don’t
care” value. VHDL case statements must be full, so the attribute does not
apply to VHDL.
f
Using this attribute on a case statement that is not full avoids the latch
inference problems discussed in the Design Recommendations for Altera
Devices and the Quartus II Design Assistant chapter in volume 1 of the
Quartus II Handbook.
1
Latches have limited support in formal verification tools. It is
important to ensure that you do not infer latches
unintentionally, for example, through an incomplete case
statement when using formal verification. Formal verification
tools do support the full_case synthesis attribute (with
limited support for attribute syntax, as described in “Synthesis
Attributes” on page 8–26).
When you are using the full_case attribute, there is a potential cause
for a simulation mismatch between Verilog HDL functional and
post-Quartus II simulation because unknown case statement cases may
still function like latches during functional simulation. For example, a
simulation mismatch may occur with the code in Example 8–72 when
sel is 2'b11 because a functional HDL simulation output behaves like a
latch while the Quartus II simulation output behaves like “don’t care.”
1
Altera recommends making the case statement “full” in your
regular HDL code, inste