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

3.5.6. 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, or specify the use of standard logic cells (LEs or ALMs). The Quartus® Prime software supports the attributes only for device families with TriMatrix embedded memory blocks.

The ramstyle and romstyle attributes take a single string value. The M512, M4K, M-RAM, MLAB, M9K, M144K, M20K, and M10K values (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 logic value indicates that the Quartus® Prime software implements the RAM or ROM 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 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.

Note: If you specify a logic value, the memory appears as a RAM or ROM block in the RTL Viewer, but Integrated Synthesis converts the memory to regular logic during synthesis.

In addition to ramstyle and romstyle, the Quartus® Prime software supports the syn_ramstyle attribute name for compatibility with other synthesis tools.

These tables specify that you must implement all memory in the module or the my_memory_blocks entity with a specific type of block.

Table 31.   Applying a romstyle Attribute to a Module Declaration
HDL Code
Verilog-1995 
module my_memory_blocks (...) /* synthesis romstyle = "M4K" */;
Table 32.   Applying a ramstyle Attribute to a Module Declaration
HDL Code
Verilog-2001 and SystemVerilog 
 (* ramstyle = "M512" *) module my_memory_blocks (...);
Table 33.   Applying a romstyle Attribute to an Architecture
HDL Code
VHDL 
architecture rtl of my_ my_memory_blocks is
attribute romstyle : string;
attribute romstyle of rtl : architecture is "M-RAM";
begin

These tables specify that you must implement the inferred my_ram or my_rom memory with regular logic instead of a TriMatrix memory block.

Table 34.  Applying a syn_ramstyle Attribute to a Variable Declaration
HDL Code
Verilog-1995 
reg [0:7] my_ram[0:63] /* synthesis syn_ramstyle = "logic" */;
Table 35.  Applying a romstyle Attribute to a Variable Declaration
HDL Code
Verilog-2001 and SystemVerilog 
(* romstyle = "logic" *) reg [0:7] my_rom[0:63];
Table 36.   Applying a ramstyle Attribute to a Signal Declaration
HDL Code
VHDL 
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";

You can control the depth of an inferred memory block and optimize its usage with the max_depth attribute. You can also optimize the usage of the memory block with this attribute.

These tables specify the depth of the inferred memory mem using the max_depth synthesis attribute.

Table 37.  Applying a max_depth Attribute to a Variable Declaration
HDL Code
Verilog-1995 
reg [7:0] mem [127:0] /* synthesis max_depth = 2048 */
Table 38.   Applying a max_depth Attribute to a Variable Declaration
HDL Code
 Verilog-2001 and SystemVerilog 
(* max_depth = 2048*) reg [7:0] mem [127:0];
Table 39.   Applying a max_depth Attribute to a Variable Declaration
HDL Code
VHDL 
type ram_block is array (0 to 31) of std_logic_vector (2 downto 0);
signal mem : ram_block;
attribute max_depth : natural;
attribute max_depth OF mem : signal is 2048;

The syntax for setting these attributes in HDL is the same as the syntax for other synthesis attributes, as shown in Synthesis Attributes.

Related Information
Level Two Title