Visible to Intel only — GUID: mwh1409959709096
Ixiasoft
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.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.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.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.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.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.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.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.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.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
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.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.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
Visible to Intel only — GUID: mwh1409959709096
Ixiasoft
2.5.1.5. Consider What Is Changing
When assigning partitions, you should consider what is changing in the design. Is there intellectual property (IP) or reused logic for which the source code will not change during future design iterations? If so, define the logic in its own partition so that you can compile one time and immediately preserve the results and not have to compile that part of the design again. Is logic being tuned or optimized, or are specifications changing for part of the design? If so, define changing logic in its own partition so that you can recompile only the changing part while the rest of the design remains unchanged.
As a general rule, create partitions to isolate logic that will change from logic that will not change. Partitioning a design in this way maximizes the preservation of unchanged logic and minimizes compilation time.