Quartus® Prime Standard Edition User Guide: Design Compilation

Download PDF
ID 683283
Date 10/22/2021
Public
Document Table of Contents
Document Table of Contents x
1. Quartus® Prime Incremental Compilation for Hierarchical and Team-Based Design 2. Best Practices for Incremental Compilation Partitions and Floorplan Assignments 3. Quartus® Prime Integrated Synthesis 4. Reducing Compilation Time A. Quartus® Prime Standard Edition User Guides
1. Quartus® Prime Incremental Compilation for Hierarchical and Team-Based Design x
1.1. About Quartus® Prime Incremental Compilation 1.2. Deciding Whether to Use an Incremental Compilation Flow 1.3. Incremental Compilation Summary 1.4. Common Design Scenarios Using Incremental Compilation 1.5. Deciding Which Design Blocks Should Be Design Partitions 1.6. Specifying the Level of Results Preservation for Subsequent Compilations 1.7. Exporting Design Partitions from Separate Quartus® Prime Projects 1.8. Team-Based Design Optimization and Third-Party IP Delivery Scenarios 1.9. Creating a Design Floorplan With LogicLock Regions 1.10. Incremental Compilation Restrictions 1.11. Scripting Support 1.12. Document Revision History
1.2. Deciding Whether to Use an Incremental Compilation Flow x
1.2.1. Flat Compilation Flow with No Design Partitions 1.2.2. Incremental Compilation Flow With Design Partitions 1.2.3. Team-Based Design Flows and IP Delivery
1.2.1. Flat Compilation Flow with No Design Partitions x
1.2.1.1. Incremental Capabilities Available When A Design Has No Partitions
1.2.1.1. Incremental Capabilities Available When A Design Has No Partitions x
1.2.1.1.1. With Smart Compilation 1.2.1.1.2. With Rapid Recompile 1.2.1.1.3. With Signal Tap Logic Analyzer
1.2.2. Incremental Compilation Flow With Design Partitions x
1.2.2.1. Impact of Using Incremental Compilation with Design Partitions 1.2.2.2. Quartus® Prime Design Stages for Incremental Compilation
1.2.2.2. Quartus® Prime Design Stages for Incremental Compilation x
1.2.2.2.1. Analysis and Synthesis Stage 1.2.2.2.2. Partition Merge Stage 1.2.2.2.3. Fitter Stage 1.2.2.2.4. How to Compare Incremental Compilation Results with Flat Design Results
1.2.3. Team-Based Design Flows and IP Delivery x
1.2.3.1. With a Single Quartus® Prime Project 1.2.3.2. With Multiple Quartus® Prime Projects 1.2.3.3. Collaboration on a Team-Based Design
1.2.3.2. With Multiple Quartus® Prime Projects x
1.2.3.2.1. Additional Planning Needed
1.3. Incremental Compilation Summary x
1.3.1. Incremental Compilation Single Quartus® Prime Project Flow 1.3.2. Steps for Incremental Compilation 1.3.3. Creating Design Partitions
1.3.2. Steps for Incremental Compilation x
1.3.2.1. Preparing a Design for Incremental Compilation 1.3.2.2. Compiling a Design Using Incremental Compilation
1.3.3. Creating Design Partitions x
1.3.3.1. Creating Design Partitions in the Project Navigator 1.3.3.2. Creating Design Partitions in the Design Partitions Window 1.3.3.3. Creating Design Partitions With the Design Partition Planner 1.3.3.4. Creating Design Partitions With Tcl Scripting 1.3.3.5. Automatically-Generated Partitions
1.4. Common Design Scenarios Using Incremental Compilation x
1.4.1. Reducing Compilation Time When Changing Source Files for One Partition 1.4.2. Optimizing a Timing-Critical Partition 1.4.3. Adding Design Logic Incrementally or Working With an Incomplete Design 1.4.4. Debugging Incrementally With the Signal Tap Logic Analyzer 1.4.5. Functional Safety IP Implementation
1.4.5. Functional Safety IP Implementation x
1.4.5.1. Software Tool Impact on Safety 1.4.5.2. Functional Safety Separation Flow 1.4.5.3. How to Turn On the Functional Safety Separation Flow 1.4.5.4. Preservation of Device Resources 1.4.5.5. Preservation of Placement in the Device with LogicLock 1.4.5.6. Assigning I/O Pins 1.4.5.7. General Guidelines for Implementation 1.4.5.8. Reports for Safety IP 1.4.5.9. SIP Partial Bitstream Generation 1.4.5.10. Exporting and Importing Your Safety IP 1.4.5.11. POF Comparison Tool for Verification
1.4.5.2. Functional Safety Separation Flow x
1.4.5.2.1. Design Creation Flow 1.4.5.2.2. Design Modification Flow
1.4.5.8. Reports for Safety IP x
1.4.5.8.1. Fitter Report
1.5. Deciding Which Design Blocks Should Be Design Partitions x
1.5.1. Impact of Design Partitions on Design Optimization 1.5.2. Design Partition Assignments Compared to Physical Placement Assignments 1.5.3. Using Partitions With Third-Party Synthesis Tools 1.5.4. Assessing Partition Quality
1.5.1. Impact of Design Partitions on Design Optimization x
1.5.1.1. Turning On Supported Cross-boundary Optimizations
1.5.3. Using Partitions With Third-Party Synthesis Tools x
1.5.3.1. Synopsys Synplify Pro/Premier and Mentor Graphics Precision RTL Plus 1.5.3.2. Other Synthesis Tools
1.5.4. Assessing Partition Quality x
1.5.4.1. Partition Statistics Reports 1.5.4.2. Partition Timing Reports 1.5.4.3. Incremental Compilation Advisor
1.6. Specifying the Level of Results Preservation for Subsequent Compilations x
1.6.1. Netlist Type for Design Partitions 1.6.2. Fitter Preservation Level for Design Partitions 1.6.3. Where Are the Netlist Databases Saved? 1.6.4. Deleting Netlists 1.6.5. What Changes Initiate the Automatic Resynthesis of a Partition?
1.6.5. What Changes Initiate the Automatic Resynthesis of a Partition? x
1.6.5.1. Resynthesis Due to Source Code Changes 1.6.5.2. Forcing Use of the Compilation Netlist When a Partition has Changed
1.7. Exporting Design Partitions from Separate Quartus® Prime Projects x
1.7.1. Preparing the Top-Level Design 1.7.2. Project Management— Making the Top-Level Design Available to Other Designers 1.7.3. Exporting Partitions 1.7.4. Viewing the Contents of a Quartus® Prime Exported Partition File (.qxp) 1.7.5. Integrating Partitions into the Top-Level Design
1.7.1. Preparing the Top-Level Design x
1.7.1.1. Empty Partitions
1.7.2. Project Management— Making the Top-Level Design Available to Other Designers x
1.7.2.1. Distributing the Top-Level Quartus® Prime Project 1.7.2.2. Generating Design Partition Scripts
1.7.5. Integrating Partitions into the Top-Level Design x
1.7.5.1. Integrating Assignments from the .qxp 1.7.5.2. Integrating Encrypted IP Cores from .qxp Files 1.7.5.3. Advanced Importing Options
1.7.5.1. Integrating Assignments from the .qxp x
1.7.5.1.1. Design Partition Assignments Within the Exported Partition 1.7.5.1.2. Synopsys Design Constraint Files for the Quartus® Prime Timing Analyzer 1.7.5.1.3. Global Assignments 1.7.5.1.4. LogicLock Region Assignments
1.7.5.3. Advanced Importing Options x
1.7.5.3.1. Importing LogicLock Assignments 1.7.5.3.2. Advanced Import Settings
1.8. Team-Based Design Optimization and Third-Party IP Delivery Scenarios x
1.8.1. Using an Exported Partition to Send to a Design Without Including Source Files Creating Precompiled Design Blocks (or Hard-Wired Macros) for Reuse Designing in a Team-Based Environment 1.8.4. Enabling Designers on a Team to Optimize Independently 1.8.5. Performing Design Iterations With Lower-Level Partitions
1.8.4. Enabling Designers on a Team to Optimize Independently x
1.8.4.1. Preparing Your Top-level Design Exporting Your Design Importing Your Design 1.8.4.4. Resolving Assignment Conflicts During Integration 1.8.4.5. Importing a Partition to be Instantiated Multiple Times
1.8.5. Performing Design Iterations With Lower-Level Partitions x
1.8.5.1. Providing the Complete Top-Level Project Framework 1.8.5.2. Providing Information About the Top-Level Framework
1.9. Creating a Design Floorplan With LogicLock Regions x
1.9.1. Creating and Manipulating LogicLock Regions 1.9.2. Changing Partition Placement with LogicLock Changes
1.10. Incremental Compilation Restrictions x
1.10.1. When Timing Performance May Not Be Preserved Exactly 1.10.2. When Placement and Routing May Not Be Preserved Exactly 1.10.3. Using Incremental Compilation With Quartus® Prime Archive Files 1.10.4. Formal Verification Support 1.10.5. Signal Probe Pins and Engineering Change Orders 1.10.6. Signal Tap Logic Analyzer in Exported Partitions 1.10.7. External Logic Analyzer Interface in Exported Partitions 1.10.8. Assignments Made in HDL Source Code in Exported Partitions 1.10.9. Design Partition Script Limitations 1.10.10. Restrictions on IP Core Partitions 1.10.11. Restrictions on Arria® 10 Transceiver 1.10.12. Register Packing and Partition Boundaries 1.10.13. I/O Register Packing
1.10.9. Design Partition Script Limitations x
1.10.9.1. Warnings About Extra Clocks Due to Design Partition Scripts 1.10.9.2. Synopsys Design Constraint Files for the Timing Analyzer in Design Partition Scripts 1.10.9.3. Wildcard Support in Design Partition Scripts 1.10.9.4. Derived Clocks and PLLs in Design Partition Scripts 1.10.9.5. Pin Assignments for GXB and LVDS Blocks in Design Partition Scripts 1.10.9.6. Virtual Pin Timing Assignments in Design Partition Scripts 1.10.9.7. Top-Level Ports that Feed Multiple Lower-Level Pins in Design Partition Scripts
1.11. Scripting Support x
1.11.1. Tcl Scripting and Command-Line Examples
1.11.1. Tcl Scripting and Command-Line Examples x
1.11.1.1. Creating Design Partitions 1.11.1.2. Enabling or Disabling Design Partition Assignments During Compilation 1.11.1.3. Setting the Netlist Type 1.11.1.4. Setting the Fitter Preservation Level for a Post-fit or Imported Netlist 1.11.1.5. Preserving High-Speed Optimization 1.11.1.6. Specifying the Software Should Use the Specified Netlist and Ignore Source File Changes 1.11.1.7. Reducing Opening a Project, Creating Design Partitions, andPerforming an Initial Compilation 1.11.1.8. Optimizing the Placement for a Timing-Critical Partition 1.11.1.9. Generating Design Partition Scripts 1.11.1.10. Exporting a Partition 1.11.1.11. Importing a Partition into the Top-Level Design 1.11.1.12. Makefiles
2. Best Practices for Incremental Compilation Partitions and Floorplan Assignments x
2.1. About Incremental Compilation and Floorplan Assignments 2.2. Incremental Compilation Overview 2.3. Design Flows Using Incremental Compilation 2.4. Why Plan Partitions and Floorplan Assignments? 2.5. Guidelines for Incremental Compilation 2.6. Checking Partition Quality 2.7. Including SDC Constraints from Lower-Level Partitions for
Third-Party IP Delivery 2.8. Introduction to Design Floorplans 2.9. Design Floorplan Placement Guidelines 2.10. Checking Floorplan Quality 2.11. Recommended Design Flows and Application Examples 2.12. Document Revision History
2.2. Incremental Compilation Overview x
2.2.1. Recommendations for the Netlist Type
2.3. Design Flows Using Incremental Compilation x
2.3.1. Using Standard Flow 2.3.2. Using Team-Based Flow 2.3.3. Combining Design Flows 2.3.4. Project Management in Team-Based Design Flows
2.3.2. Using Team-Based Flow x
2.3.2.1. Using Third-Party IP Delivery Flow
2.3.4. Project Management in Team-Based Design Flows x
2.3.4.1. Using a Source Control System 2.3.4.2. Using a Copy of the Top-Level Project 2.3.4.3. Using a Separate Project 2.3.4.4. Using Scripts 2.3.4.5. Using Constraints
2.4. Why Plan Partitions and Floorplan Assignments? x
2.4.1. Partition Boundaries and Optimization
2.4.1. Partition Boundaries and Optimization x
2.4.1.1. Merging Partitions 2.4.1.2. Resource Utilization 2.4.1.3. Turning On Supported Cross-Boundary Optimizations
2.5. Guidelines for Incremental Compilation x
2.5.1. General Partitioning Guidelines 2.5.2. Design Partition Guidelines 2.5.3. Consider a Cascaded Reset Structure 2.5.4. Design Partition Guidelines for Third-Party IP Delivery
2.5.1. General Partitioning Guidelines x
2.5.1.1. Plan Design Hierarchy and Design Files 2.5.1.2. Using Partitions with Third-Party Synthesis Tools 2.5.1.3. Partition Design by Functionality and Block Size 2.5.1.4. Partition Design by Clock Domain and Timing Criticality 2.5.1.5. Consider What Is Changing
2.5.2. Design Partition Guidelines x
2.5.2.1. Register Partition Inputs and Outputs 2.5.2.2. Minimize Cross-Partition-Boundary I/O 2.5.2.3. Examine the Need for Logic Optimization Across Partitions 2.5.2.4. Keep Constants in the Same Partition as Logic 2.5.2.5. Avoid Signals That Drive Multiple Partition I/O or Connect I/O Together 2.5.2.6. Invert Clocks in Destination Partitions 2.5.2.7. Connect I/O Pin Directly to I/O Register for Packing Across Partition Boundaries 2.5.2.8. Do Not Use Internal Tri-States 2.5.2.9. Include All Tri-State and Enable Logic in the Same Partition 2.5.2.10. Summary of Guidelines Related to Logic Optimization Across Partitions
2.5.2.3. Examine the Need for Logic Optimization Across Partitions x
2.5.2.3.1. Keep Logic in the Same Partition for Optimization and Merging 2.5.2.3.2. Merging PLLs and Transceivers (GXB)
2.5.2.4. Keep Constants in the Same Partition as Logic x
2.5.2.4.1. Example—Constants in Merged Partitions
2.5.2.5. Avoid Signals That Drive Multiple Partition I/O or Connect I/O Together x
2.5.2.5.1. Example—Single Signal Driving More Than One Port
2.5.2.6. Invert Clocks in Destination Partitions x
2.5.2.6.1. Example—Clock Signal Inversion
2.5.2.7. Connect I/O Pin Directly to I/O Register for Packing Across Partition Boundaries x
2.5.2.7.1. Example 1—Output Register in Partition Feeding Multiple Output Pins 2.5.2.7.2. Example 2—Input Register in Partition Fed by an Inverted Input Pin or Output Register in Partition Feeding an Inverted Output Pin
2.5.4. Design Partition Guidelines for Third-Party IP Delivery x
2.5.4.1. Allocate Logic Resources 2.5.4.2. Allocate Global Routing Signals and Clock Networks if Required 2.5.4.3. Assign Virtual Pins 2.5.4.4. Perform Timing Budgeting if Required 2.5.4.5. Drive Clocks Directly 2.5.4.6. Recreate PLLs for Lower-Level Partitions if Required
2.6. Checking Partition Quality x
2.6.1. Incremental Compilation Advisor 2.6.2. Design Partition Planner 2.6.3. Viewing Design Partition Planner and Floorplan Side-by-Side 2.6.4. Partition Statistics Report 2.6.5. Report Partition Timing in the Timing Analyzer 2.6.6. Check if Partition Assignments Impact the Quality of Results
2.7. Including SDC Constraints from Lower-Level Partitions for
Third-Party IP Delivery x
2.7.1. Creating an .sdc File with Project-Wide Constraints 2.7.2. Creating an .sdc with Partition-Specific Constraints 2.7.3. Consolidating the .sdc in the Top-Level Design
2.7.1. Creating an .sdc File with Project-Wide Constraints x
2.7.1.1. Example Step 1—Project Lead Produces .sdc with Project-Wide Constraints for Lower-Level Partitions
2.7.2. Creating an .sdc with Partition-Specific Constraints x
2.7.2.1. Example Step 2—Partition Designer Creates .sdc with Partition-Specific Constraints
2.7.3. Consolidating the .sdc in the Top-Level Design x
2.7.3.1. Example Step 3—Project Lead Performs Final Timing Analysis and Sign-off
2.8. Introduction to Design Floorplans x
2.8.1. The Difference between Logical Partitions and Physical Regions 2.8.2. Why Create a Floorplan? 2.8.3. When to Create a Floorplan
2.8.3. When to Create a Floorplan x
2.8.3.1. Early Floorplan 2.8.3.2. Late Floorplan
2.9. Design Floorplan Placement Guidelines x
2.9.1. Flow for Creating a Floorplan 2.9.2. Assigning Partitions to LogicLock Regions 2.9.3. How to Size and Place Regions 2.9.4. Modifying Region Size and Origin 2.9.5. I/O Connections 2.9.6. LogicLock Resource Exclusions 2.9.7. Creating Non-Rectangular Regions
2.9.6. LogicLock Resource Exclusions x
2.9.6.1. Creating Floorplan Location Assignments With Tcl Commands—Excluding or Filtering Certain Device Elements (Such as RAM or DSP Blocks)
2.10. Checking Floorplan Quality x
2.10.1. Incremental Compilation Advisor 2.10.2. LogicLock Region Resource Estimates 2.10.3. LogicLock Region Properties Statistics Report 2.10.4. Locate the Quartus® Prime Timing Analyzer Path in the Chip Planner 2.10.5. Inter-Region Connection Bundles 2.10.6. Routing Utilization 2.10.7. Ensure Floorplan Assignments Do Not Significantly Impact Quality of Results
2.11. Recommended Design Flows and Application Examples x
2.11.1. Create a Floorplan for Major Design Blocks 2.11.2. Create a Floorplan Assignment for One Design Block with Difficult Timing 2.11.3. Create a Floorplan as the Project Lead in a Team-Based Flow
3. Quartus® Prime Integrated Synthesis x
3.1. Design Flow 3.2. Language Support 3.3. Incremental Compilation 3.4. Quartus® Prime Synthesis Options 3.5. Inferring Multiplier, DSP, and Memory Functions from HDL Code 3.6. Analyzing Synthesis Results 3.7. Analyzing and Controlling Synthesis Messages 3.8. Node-Naming Conventions in Quartus® Prime Integrated Synthesis 3.9. Scripting Support 3.10. Document Revision History
3.1. Design Flow x
3.1.1. Quartus® Prime Integrated Synthesis Design and Compilation Flow
3.1.1. Quartus® Prime Integrated Synthesis Design and Compilation Flow x
3.1.1.1. Factors Affecting Compilation Results
3.2. Language Support x
3.2.1. Verilog and SystemVerilog Synthesis Support 3.2.2. VHDL Synthesis Support 3.2.3. AHDL Support 3.2.4. Schematic Design Entry Support 3.2.5. State Machine Editor 3.2.6. Design Libraries 3.2.7. Using Parameters/Generics
3.2.1. Verilog and SystemVerilog Synthesis Support x
3.2.1.1. Verilog HDL Configuration 3.2.1.2. SystemVerilog Support 3.2.1.3. Initial Constructs and Memory System Tasks 3.2.1.4. Verilog HDL Macros
3.2.1.1. Verilog HDL Configuration x
3.2.1.1.1. Configuration Syntax 3.2.1.1.2. Hierarchical Design Configurations 3.2.1.1.3. Suffix :config
3.2.1.4. Verilog HDL Macros x
3.2.1.4.1. Setting a Verilog HDL Macro Default Value in the Quartus® Prime Software 3.2.1.4.2. Setting a Verilog HDL Macro Default Value on the Command Line
3.2.2. VHDL Synthesis Support x
3.2.2.1. Quartus® Prime Support for VHDL 2008 3.2.2.2. VHDL Standard Libraries and Packages 3.2.2.3. VHDL wait Constructs
3.2.6. Design Libraries x
3.2.6.1. Specifying a Destination Library Name in the Settings Dialog Box 3.2.6.2. Specifying a Destination Library Name in the Quartus® Prime Settings File or with Tcl 3.2.6.3. Specifying a Destination Library Name in a VHDL File 3.2.6.4. Mapping a VHDL Instance to an Entity in a Specific Library
3.2.6.4. Mapping a VHDL Instance to an Entity in a Specific Library x
3.2.6.4.1. Direct Entity Instantiation 3.2.6.4.2. Component Instantiation—Explicit Binding Instantiation 3.2.6.4.3. Component Instantiation—Default Binding
3.2.7. Using Parameters/Generics x
3.2.7.1. Setting Default Parameter Values and BDF Instance Parameter Values 3.2.7.2. Passing Parameters Between Two Design Languages
3.3. Incremental Compilation x
3.3.1. Partitions for Preserving Hierarchical Boundaries 3.3.2. Parallel Synthesis 3.3.3. Quartus® Prime Exported Partition File as Source
3.4. Quartus® Prime Synthesis Options x
3.4.1. Setting Synthesis Options 3.4.2. Optimization Technique 3.4.3. Auto Gated Clock Conversion 3.4.4. Enabling Timing-Driven Synthesis 3.4.5. SDC Constraint Protection 3.4.6. PowerPlay Power Optimization 3.4.7. Limiting Resource Usage in Partitions 3.4.8. Restructure Multiplexers 3.4.9. Synthesis Effort 3.4.10. Fitter Intial Placement Seed 3.4.11. State Machine Processing 3.4.12. Safe State Machine 3.4.13. Power-Up Level 3.4.14. Power-Up Don’t Care 3.4.15. Remove Duplicate Registers 3.4.16. Preserve Registers 3.4.17. Disable Register Merging/Don’t Merge Register 3.4.18. Noprune Synthesis Attribute/Preserve Fan-out Free Register Node 3.4.19. Keep Combinational Node/Implement as Output of Logic Cell 3.4.20. Disabling Synthesis Netlist Optimizations with dont_retime Attribute 3.4.21. Disabling Synthesis Netlist Optimizations with dont_replicate Attribute 3.4.22. Maximum Fan-Out 3.4.23. Controlling Clock Enable Signals with Auto Clock Enable Replacement and direct_enable
3.4.1. Setting Synthesis Options x
3.4.1.1. Quartus® Prime Logic Options 3.4.1.2. Synthesis Attributes 3.4.1.3. Synthesis Directives
3.4.1.2. Synthesis Attributes x
3.4.1.2.1. Synthesis Attributes in Verilog-1995 3.4.1.2.2. Synthesis Attributes in Verilog-2001 3.4.1.2.3. Synthesis Attributes in VHDL
3.4.7. Limiting Resource Usage in Partitions x
3.4.7.1. Creating LogicLock Regions 3.4.7.2. Using Assignments to Limit the Number of RAM and DSP Blocks
3.4.11. State Machine Processing x
3.4.11.1. Manually Specifying State Assignments Using the syn_encoding Attribute 3.4.11.2. Manually Specifying Enumerated Types Using the enum_encoding Attribute
3.4.13. Power-Up Level x
3.4.13.1. Inferred Power-Up Levels
3.5. Inferring Multiplier, DSP, and Memory Functions from HDL Code x
3.5.1. Multiply-Accumulators and Multiply-Adders 3.5.2. Shift Registers 3.5.3. RAM and ROM 3.5.4. Resource Aware RAM, ROM, and Shift-Register Inference 3.5.5. Auto RAM to Logic Cell Conversion 3.5.6. RAM Style and ROM Style—for Inferred Memory 3.5.7. RAM Style Attribute—For Shift Registers Inference 3.5.8. Disabling Add Pass-Through Logic to Inferred RAMs no_rw_check Attribute 3.5.9. RAM Initialization File—for Inferred Memory 3.5.10. Multiplier Style—for Inferred Multipliers 3.5.11. Full Case Attribute 3.5.12. Parallel Case 3.5.13. Translate Off and On / Synthesis Off and On 3.5.14. Ignore translate_off and synthesis_off Directives 3.5.15. Read Comments as HDL 3.5.16. Use I/O Flipflops 3.5.17. Specifying Pin Locations with chip_pin 3.5.18. Using altera_attribute to Set Quartus® Prime Logic Options
3.6. Analyzing Synthesis Results x
3.6.1. Analysis & Synthesis Section of the Compilation Report 3.6.2. Project Navigator
3.6.2. Project Navigator x
3.6.2.1. Upgrade IP Components Dialog Box
3.7. Analyzing and Controlling Synthesis Messages x
3.7.1. Quartus® Prime Messages 3.7.2. VHDL and Verilog HDL Messages
3.7.2. VHDL and Verilog HDL Messages x
3.7.2.1. Setting the HDL Message Level 3.7.2.2. Enabling or Disabling Specific HDL Messages by Module/Entity
3.8. Node-Naming Conventions in Quartus® Prime Integrated Synthesis x
3.8.1. Hierarchical Node-Naming Conventions 3.8.2. Node-Naming Conventions for Registers (DFF or D Flipflop Atoms) 3.8.3. Register Changes During Synthesis 3.8.4. Preserving Register Names 3.8.5. Node-Naming Conventions for Combinational Logic Cells 3.8.6. Preserving Combinational Logic Names
3.8.3. Register Changes During Synthesis x
3.8.3.1. Synthesis and Fitting Optimizations 3.8.3.2. State Machines 3.8.3.3. Inferred Adder-Subtractors, Shift Registers, Memory, and DSP Functions 3.8.3.4. Packed Input and Output Registers of RAM and DSP Blocks
3.9. Scripting Support x
3.9.1. Adding an HDL File to a Project and Setting the HDL Version 3.9.2. Assigning a Pin 3.9.3. Creating Design Partitions for Incremental Compilation
4. Reducing Compilation Time x
4.1. Strategies to Reduce the Overall Compilation Time 4.2. Reducing Synthesis Time and Synthesis Netlist Optimization Time 4.3. Reducing Placement Time 4.4. Reducing Routing Time 4.5. Reducing Static Timing Analysis Time 4.6. Setting Process Priority 4.7. Reducing Compilation Time Revision History
4.1. Strategies to Reduce the Overall Compilation Time x
4.1.1. Running Rapid Recompile 4.1.2. Enabling Multi-Processor Compilation 4.1.3. Using Incremental Compilation 4.1.4. Using Block-Based Compilation
4.1.2. Enabling Multi-Processor Compilation x
4.1.2.1. Processor Base Clock Frequency 4.1.2.2. Random Access Memory (RAM) 4.1.2.3. Storage
4.2. Reducing Synthesis Time and Synthesis Netlist Optimization Time x
4.2.1. Settings to Reduce Synthesis Time and Synthesis Netlist Optimization Time 4.2.2. Use Appropriate Coding Style to Reduce Synthesis Time
4.3. Reducing Placement Time x
4.3.1. Fitter Effort Setting 4.3.2. Placement Effort Multiplier Settings 4.3.3. Physical Synthesis Effort Settings 4.3.4. Preserving Placement with Incremental Compilation
4.4. Reducing Routing Time x
4.4.1. Identifying Routing Congestion with the Chip Planner
4.4.1. Identifying Routing Congestion with the Chip Planner x
4.4.1.1. Areas with Routing Congestion 4.4.1.2. Congestion due to HDL Coding style 4.4.1.3. Preserving Routing with Incremental Compilation
1. Quartus® Prime Incremental Compilation for Hierarchical and Team-Based Design
2. Best Practices for Incremental Compilation Partitions and Floorplan Assignments
3. Quartus® Prime Integrated Synthesis
4. Reducing Compilation Time
A. Quartus® Prime Standard Edition User Guides

4.1.2. Enabling Multi-Processor Compilation

The compiler can detect and use multiple processors to reduce total compilation time. By default, the compiler uses the setting specified under Parallel Compilation in the Processing page of the Options dialog box. To reserve some processors for other tasks, specify the maximum number of processors the software must use.

Using multiple processor cores provides several benefits for improving software performance as follows:

  • Faster execution: The Quartus® Prime software can support up to 24 processors, which means the software can run algorithms in parallel. This technique reduces the compilation time by up to 10% on systems with two processing cores and up to 20% on systems with four processors. When running timing analysis independently, two processors reduce the timing analysis time by an average of 10%. This reduction reaches an average of 15% when using four processors.
  • Increased throughput: With more processing cores, systems can execute multiple tasks simultaneously, which means the software can handle more requests simultaneously. The Quartus® Prime software may not necessarily utilize all the processors specified during compilation. The software has the flexibility to scale its usage to use up to the maximum number of processors specified. To achieve the highest possible throughput, Intel recommends using a system equipped with at least four processing cores, allowing the software to take full advantage of the available computing resources.
  • Reduced latency: With multiple processing cores, the software responds more quickly to your requests, improving the overall experience. The software never uses more than the specified number of processors, so you can work on other tasks in parallel without slowing down your computer.
  • More efficient resource utilization: By distributing tasks across multiple processor cores, the Quartus® Prime software can use available resources more efficiently, reducing the overall cost of running the software.

The use of multiple processors does not affect the quality of the fit. The fit is the same and deterministic for a given Fitter seed and given Maximum processors allowed setting on a specific design. This remains true regardless of the target system and the number of available processors. Different Maximum processors allowed specifications produces different results of the same quality. The impact is similar to changing the Fitter seed setting.

To enable multiprocessor compilation, follow these steps:

  1. Open or create an Quartus® Prime project.
  2. Click Assignments > Settings > Compilation Process Settings.
  3. Under Parallel compilation, specify options for the number of processors the compiler uses.

    View the number of processors detected on your system in the Parallel Compilation report after compilation ends.

    Figure 38. Parallel Compilation Report

    The following is the QSF setting that controls the maximum number of processors. If this line is in your project's QSF file, do not specify it again. 

    set_global_assignment -name NUM_PARALLEL_PROCESSORS <value>

    In this case, <value> is an integer from 1 to 24.

    If you want the Quartus® Prime software to detect the number of processors and use all the processors for the compilation, include the following Tcl command in your script: 

    set_global_assignment -name NUM_PARALLEL_PROCESSORS ALL

    The actual reduction in compilation time when using incremental compilation partitions depends on your design and on the specific compilation settings. For example, compilations with multi-corner optimization enabled benefit more from using multiple processors than compilations without multi-corner optimization. The Fitter (quartus_fit) and the Quartus® Prime Timing Analyzer (quartus_sta) stages in the compilation can, in certain cases, benefit from the use of multiple processors. The Flow Elapsed Time report shows the average number of processors for these stages. The Parallel Compilation report shows a more detailed breakdown of processor usage. This report displays only if you enable parallel compilation.

    For designs with partitions, once you partition your design and enable partial compilation, the Quartus® Prime software can use different processors to compile those partitions simultaneously during Analysis & Synthesis. This can cause higher peak memory usage during Analysis & Synthesis.

    Note:
    • Using multiple processor cores can help the Quartus® Prime software run faster, handle more tasks, and provide a better user experience. However, other factors, such as memory bandwidth or I/O bottlenecks, may limit performance. So, you must consider specific requirements and constraints of each project when deciding how many processor cores to use.
    • The compiler detects Intel® Hyper-Threading® Technology (Intel® HT Technology) as a single processor. If your system includes a single processor with Intel HT Technology, set the number of processors to one. Set the number of processors according to the number of physical processors in your system,

    The following are other factors that affect performance in the Quartus® Prime software:


Section Content
Processor Base Clock Frequency
Random Access Memory (RAM)
Storage

Level Two Title