Intel Quartus Prime Pro Edition User Guide: Design Compilation

RSS

UG-20132 | 2020.09.28

Version Information

Updated for:
Intel® Quartus® Prime Design Suite 20.3

1. Design Compilation

The Intel^® Quartus^® Prime Compiler synthesizes, places, and routes your design before generating device programming files. The Compiler supports a variety of high-level, HDL, and schematic design entry methods. The modules of the Compiler include IP Generation, Analysis & Synthesis, Fitter, Timing Analyzer, and Assembler.

Compilation Dashboard

The Intel^® Quartus^® Prime Pro Edition version of the Compiler supports these advanced features:

Supports Intel^® Arria^® 10, Intel^® Cyclone^® 10 GX, Intel^® Stratix^® 10, and Intel^® Agilex™ devices.
Incremental Fitter optimization—analyze and optimize after each Fitter stage to maximize performance and shorten total compilation time.
Hyper-Aware Design Flow—use Hyper-Retiming and Fast Forward compilation for the highest performance in Intel^® Stratix^® 10 and Intel^® Agilex™ devices.
Partial Reconfiguration—dynamic reconfiguration of a portion of the FPGA, while the remaining FPGA continues to function.
Block-Based Design Flows—preservation and reuse of design blocks.

1.1. Compilation Overview

The Compiler is modular, allowing you to run only the process that you need. Each Compiler module performs a specific function in the full compilation process. When you run any module, the Compiler runs any prerequisite modules automatically and generates detailed reports at each stage. The Compiler can preserve a "snapshot" of the compilation results after each stage.

Table 1. Compilation Modules
Compilation Process	Description
IP Generation	Identifies the status and version of IP components in the project. Reports outdated IP that require upgrade.
Analysis & Synthesis	Synthesizes, optimizes, minimizes, and maps design logic to device resources. The "synthesized" snapshot preserves the results of this stage. Analysis & Elaboration is a stage of Analysis & Synthesis. This stage checks for design file and project errors.
Fitter (Place & Route)	Assigns the placement and routing of the design to specific device resources, while honoring timing and placement constraints. The Fitter includes the following stages: Plan—places all periphery elements (such as I/Os and PLLs) and determines a legal clock plan, without core placement or routing. The "planned" snapshot preserves the stage results. Place—places all core elements in a legal location. The "placed" snapshot preserves the stage results. Route—creates all routing between the elements in the design. The "routed" snapshot preserves the stage results. Retime—moves (retimes) existing registers into Hyper-Registers for fine-grained performance improvement. The "retimed" snapshot preserves the stage results. ¹ Fitter (Finalize)—for Intel^® Arria^® 10 and Intel^® Cyclone^® 10 GX devices, converts unnecessary tiles to High-Speed or Low-Power. For Intel^® Stratix^® 10 and Intel^® Agilex™ devices, performs post-Route fix-up. The "final" snapshot preserves the stage results.
Fast Forward Timing Closure Recommendations	Generates detailed reports that estimate performance gains achievable by making specific RTL modifications.
Timing Analysis	Analyzes and validates the timing performance of all design logic with the Timing Analyzer.
Power Analysis	Optional module that estimates device power consumption. Specify the electrical standard on each I/O cell and the board trace model on each I/O standard in your design.
Assembler	Converts the Fitter's placement and routing assignments into a programming image for the FPGA device.
EDA Netlist Writer	Generates output files for use in other EDA tools.

Note: Each successive release of the Intel^® Quartus^® Prime software typically includes:

Added support for new features in supported FPGA devices.
Added support for new devices.
Efficiency and performance improvements.
Improvements to compilation time and resource use of the design software.

Due to these improvements, different versions of the Intel^® Quartus^® Prime Pro Edition, Intel^® Quartus^® Prime Standard Edition, and Intel^® Quartus^® Prime Lite Edition software can produce different programming files from release to release.

¹ Retiming and Fast Forward compilation available only for Intel^® Stratix^® 10 and Intel^® Agilex™ devices.

1.1.1. Compilation Flows

The Intel^® Quartus^® Prime Pro Edition Compiler supports a variety of flows to help you maximize performance and minimize compilation processing time. The modular Compiler is flexible and efficient, allowing you to run all modules in sequence with a single command, or to run and optimize each stage of compilation separately.

As you develop and optimize your design, run only the Compiler stages that you need, rather than waiting for full compilation. Run full compilation only when your design is complete and you are ready to run all Compiler modules and generate a device programming image.

Table 2. Compilation Flows
Compiler Flow	Function
ECO Compilation Flow	The Intel^® Quartus^® Prime Pro Edition software supports last-minute, targeted design changes (also known as engineering change orders (ECOs)), even after you fully compile the design. ECOs typically occur during the design verification stage. Refer to the Intel^® Quartus^® Prime Pro Edition User Guide: Design Optimization.
Incremental Optimization Flow	Incremental optimization allows you to stop processing after each Fitter stage, analyze the results, and adjust settings or RTL before proceeding to the next compilation stage. This iterative flow optimizes at each stage, without waiting for full compilation results.
Hyper-Aware Design Flow	Combines automated register retiming (Hyper-Retiming), with implementation of targeted timing closure recommendations (Fast Forward Compilation), to maximize use of Hyper-Registers and drive the highest performance in Intel^® Stratix^® 10 and Intel^® Agilex™ devices.
Full Compilation Flow	Launches all Compiler modules in sequence to synthesize, fit, analyze final timing, and generate a device programming file. By default, the Compiler generates and preserves only the synthesized and final snapshots during a full compilation. You can optionally Enable Intermediate Fitter Snapshots to preserve the planned, placed, routed, and retimed snapshots.
Partial Reconfiguration	Reconfigures a portion of the FPGA dynamically, while the remaining FPGA design continues to function.
Block-Based Design Flows	Supports preservation and reuse of design blocks in one or more projects. You can reuse synthesized or final design blocks in other projects. Reusable design blocks can include device core or periphery resources.

1.1.2. Compilation Hierarchy

The Intel^® Quartus^® Prime Pro Edition Compiler generates a hierarchical project structure that isolates results of each compilation stage, for each design entity. For example, the synthesized directory contains a snapshot of the Analysis & Synthesis stage.

If you use design partitions, such as in block-based design, the Compiler also isolates the results for each design partition. The Compiler fully preserves routing and placement within a partition. Changes to other portions of the design hierarchy do not impact the partition. This hierarchical structure allows you to optimize specific design elements without impacting placement and routing in other partitions. The hierarchical project structure also supports distributed work groups and compilation processing across multiple machines.

Figure 1. Hierarchical Project Structure ( Intel^® Stratix^® 10 Design)

1.2. Design Synthesis

Design synthesis is the process that translates design source files into an atom netlist for mapping to device resources. You can specify various settings that affect synthesis processing. The Intel^® Quartus^® Prime Compiler's Analysis and Synthesis module synthesizes standards-compliant Verilog HDL (.v), VHDL (.vhd), and SystemVerilog (.sv). The Compiler can also synthesize Block Design File (.bdf) schematic files, and the Verilog Quartus Mapping (.vqm) files generated by other EDA tools.

Synthesis examines the logical completeness and consistency of the design, and checks for boundary connectivity and syntax errors. Synthesis also minimizes and optimizes design logic. For example, synthesis infers D flip flops, latches, and state machines from "behavioral" languages, such as Verilog HDL, VHDL, and SystemVerilog. Synthesis may replace operators, such as + or –, with modules from the Intel^® Quartus^® Prime IP library, when advantageous. During synthesis, the Compiler may change or remove user logic and design nodes. Intel^® Quartus^® Prime synthesis minimizes gate count, removes redundant logic, and ensures efficient use of device resources.

At the end of synthesis, the Compiler generates an atom netlist. Atom refers to the most basic hardware resource in the FPGA device. Atoms include logic cells organized into look-up tables, D flip flops, I/O pins, block memory resources, DSP blocks, and the connections between the atoms. The atom netlist is a database of the atom elements that design synthesis requires to implement the design in silicon.

Figure 2. Design Synthesis

1.2.1. Running Synthesis

Run design synthesis as part of a full compilation, or as an independent process. Before running synthesis, specify settings that control synthesis processing. The Messages window dynamically displays processing information, warnings, or errors. Following Analysis & Synthesis processing, the Synthesis report provides detailed information about the synthesis of your project. To run synthesis, perform the following steps.

Create or open an Intel^® Quartus^® Prime project with valid design files for compilation.
Before running synthesis, specify any of the following settings and constraints that impact synthesis:
- To specify options for the synthesis of Verilog HDL input files, click Assignments > Settings > Verilog HDL Input.
- To specify options for the synthesis of VHDL input files, click Assignments > Settings > VHDL Input.
- To specify options that affect compilation processing time, click Assignments > Settings > Compilation Process Settings.
- To specify the Compiler's high-level optimization strategy and other options, click Assignments > Settings > Compiler Settings. Specify the optimization goal, according to Optimization Modes.
- On the Compiler Settings page enable or disable the Enable Intermediate Fitter Snapshots option to preserve snapshots for the Plan, Place, Route, and Retime stages any time you run full compilation. The Compiler does not generate intermediate snapshots by default.
- To specify advanced synthesis settings, click Assignments > Settings > Compiler Settings, and then click Advanced Settings (Synthesis).
- Consider enabling fractal synthesis for arithmetic-intensive designs that exhaust all DSP resources, according to the guidelines in Fractal Synthesis Optimization.
To run synthesis, click Synthesis on the Compilation Dashboard.

1.2.1.1. Preserving Registers During Synthesis

Intel^® Quartus^® Prime synthesis minimizes gate count, merges redundant logic, and ensures efficient use of device resources. If you need to preserve specific registers through synthesis processing, you can specify any of the following entity-level assignments.

Assign the Preserve Registers in Synthesis or Preserve Fan-Out Free Register Node options to allow Fitter optimization of the preserved registers. Preserve Registers restricts Fitter optimization of the preserved registers. Specify synthesis preservation assignments by clicking Assignments > Assignment Editor, by modifying the .qsf file, or by specifying synthesis attributes in your RTL.

Table 3. Synthesis Preserve Options
Assignment	Description	Allows Fitter Optimization?	Assignment Syntax
Preserve Registers in Synthesis	Prevents removal of registers during synthesis. This settings does not affect retiming or other optimizations in the Fitter.	Yes	`PRESERVE_REGISTER_SYN_ONLY ON\|Off -to <entity>` .qsf `preserve_syn_only` or `syn_preservesyn_only` (synthesis attributes)
Preserve Fan-Out Free Register Node	Prevents removal of assigned registers without fan-out during synthesis. The `PRESERVE_FANOUT_FREE_NODE` assignment cannot preserve a fanout-free register that has no fanout inside the Verilog HDL or VHDL module in which you define it. To preserve these fanout-free registers, implement the `noprune` pragma in the source file: (noprune)reg r; If there are multiple instances of this module, with only some instances requiring preservation of the fanout-free register, set a dummy pragma on the register in the HDL and also set the `PRESERVE_FANOUT_FREE_NODE` assignment. This dummy pragma allows the register synthesis to implement the assignment. For example, set the following dummy pragma for a register `r` in Verilog HDL: (dummy)reg r;	Yes	`PRESERVE_REGISTER_FANOUT_FREE_NODE ON\|Off -to <entity>` .qsf `no_prune on` (synthesis attribute)
Preserve Registers	Prevents removal and sequential optimization of assigned registers during synthesis. Sequential netlist optimizations can eliminate redundant registers and registers with constant drivers.	No	`PRESERVE_REGISTER ON\|Off -to <entity>` .qsf `preserve`, `syn_preserve`, or `keep on` (synthesis attributes)

1.2.2. Synthesis Reports

The Compilation Report window opens automatically during compilation processing. The Report window displays detailed synthesis results for each partition in the current project revision.

1.3. Design Place and Route

The Compiler's Fitter module (quartus_fit) performs design placement and routing. During place and route, the Fitter determines the best placement and routing of logic in the target FPGA device, while respecting any Fitter settings or constraints that you specify.

By default, the Fitter selects appropriate resources, interconnection paths, and pin locations. If you assign logic to specific device resources, the Fitter attempts to match those requirements, and then fits and optimizes any remaining unconstrained design logic. If the Fitter cannot fit the design in the current target device, the Fitter terminates compilation and issues an error message.

The Intel^® Quartus^® Prime Pro Edition Fitter introduces a hybrid placement technique that combines analytical and annealing placement techniques. Analytical placement determines an initial mathematical starting placement. The annealing technique then fine-tunes logic block placement in high resource utilization scenarios.

1.3.1. Using the Compilation Dashboard

The Compilation Dashboard provides immediate access to settings, controls, and reporting for each stage of the compilation flow.

The Compilation Dashboard appears by default when you open a project, or you can click Compilation Dashboard in the Tasks window to re-open it.

Figure 3. Compilation Dashboard

Click the Pencil icon to edit settings for that stage of the compilation flow.
Click any Compiler stage to run one or more Compiler stage.
Click the Report, RTL Viewer, Technology Map Viewer, Timing Analyzer, or Snapshot Viewer icons for analysis of stage results.

As the Compiler progresses through the flow, the dashboard updates the status of each module, and enables icons that you can click for reports and analysis.

1.3.2. Running the Fitter

The Compiler's Fitter module performs all stages of design place and route, including the Plan, Early Place, Place, Route, and Retime stages.

The Intel^® Quartus^® Prime Pro Edition Compiler allows control and optimization of each individual Fitter stage, including the Plan, Early Place, Place, and Route stages. Run all stages of the Fitter as part of a full design compilation, or run any Fitter stage independently after design synthesis. Before running the Fitter, you specify settings that impact Fitter processing.

After running a Fitter stage, view detailed report data and analyze the timing of that stage. The Compiler preserves Fitter results of the final snapshot by default.

Specify initial Fitter constraints:
1. To assign device I/O pins, click Assignments > Pin Planner.
2. To assign device periphery, clocks, and I/O interfaces, click Tools > Interface Planner .
3. To constrain logic placement regions, click Tools > Chip Planner.
4. To specify Fitter optimization goals, click Assignments > Settings > Compiler Settings. Optimization Modes describes these options in detail
5. To fine-tune place and route with advanced Fitter options, click Assignments > Settings > Compiler Settings > Advanced Settings (Fitter)
To run one or more stages of the Fitter, click any of the following commands on the Compilation Dashboard:
- To run all Fitter stages in sequence, click Fitter.
- To run only device periphery placement and routing, click Plan.
- To run only early placement, click Early Place.
- To run only logic placement, click Place.
- To run only logic routing, click Route.
- To run only retiming of ALM registers into Hyper-Registers, click Retime.²
- To run the Implement flow (runs Plan, Place, Route, and Retime stages), click Fitter (Implement).
- To run the Finalize flow (runs Plan, Early Place, Place, Route, Retime, and Finalize stages), click Fitter (Finalize).

² Retime available for Intel^® Hyperflex™ architecture devices only.

1.3.2.1. Fitter Commands

Launch Fitter processes from the Processing menu or Compilation Dashboard with Fitter commands.

Table 4. Start Fitter Commands
Command	Description
Start Fitter (Plan)	Loads synthesized periphery placement data and constraints, and assigns periphery elements to device I/O resources. This command creates the planned snapshot.
Start Fitter (Place)	Places all core elements in a legal location. This command creates the placed snapshot.
Start Fitter (Route)	Creates all routing between the elements in the design. This command creates the routed snapshot.
Start Fitter (Retime)	Performs register retiming and moves existing registers into Hyper-Registers to increase performance by removing retiming restrictions and eliminating critical paths. The Compiler may report hold violations for short paths following the Retime stage. This command creates the retimed snapshot.
Start Fitter (Finalize)	Performs post-routing optimization on the design. The Fitter identifies and corrects the short paths with hold violations during the Fitter (Finalize) stage by adding routing wire along the paths. This stage converts unneeded tiles from High Speed to Low Power. This command creates the final snapshot. For Intel^® Stratix^® 10 and Intel^® Agilex™ designs, the Fitter also runs post-route fix-up to correct any short path hold violations remaining from retiming.

Note: The Compiler reports any hold violations for short paths following the Retime stage. The Fitter identifies and corrects the short paths with hold violations during the Fitter (Finalize) stage by adding routing wire along the paths.

1.3.2.2. Enabling Physical Synthesis Optimization

Physical synthesis optimization improves circuit performance by performing combinational and sequential optimization and register duplication.

To enable physical synthesis options:

Click Assignments > Settings > Compiler Settings.
To enable retiming, combinational optimization, and register duplication, click Advanced Settings (Fitter). Next, enable Physical Synthesis.
View physical synthesis results in the Netlist Optimizations report.

1.3.3. Viewing Fitter Reports

The Fitter generates detailed reports and messages for each stage of place and route. The Fitter Summary reports basic information about the Fitter run, such as date, software version, device family, timing model, and logic utilization.

1.3.3.1. Plan Stage Reports

The Plan stage reports describe the I/O, interface, and control signals discovered during the periphery planning stage of the Fitter.

Figure 4. Plan Stage Reports ( Intel^® Arria^® 10 and Intel^® Cyclone^® 10 GX Designs)

For Intel^® Arria^® 10 and Intel^® Cyclone^® 10 GX designs, the Plan stage includes the Global & Other Fast Signals Summary report that allows you to verify which clocks the Compiler promotes to global clocks. Clock planning occurs after the Early Place stage for Intel^® Stratix^® 10 and Intel^® Agilex™ designs.

1.3.3.2. Place Stage Reports

The Place stage reports describe all device resources the Fitter allocates during logic placement, as well as use of Logic Lock regions and global and other fast signals.

Figure 5. Place Stage Reports

1.3.3.2.1. Global Signal Visualization Report

For Intel^® Stratix^® 10 and Intel^® Agilex™ designs, you can access the Global Signal Visualization report to view global signal routing and clock sector utilization in an interactive heat-map.

This report allows you to track the routing and placement of each individual clock. You can use this data to analyze global signal routing congestion issues, and to debug global signal placement and routing failures.

View global clock tree implementation details and assess capacity to add more global signals to the design. In cases of clock tree synthesis errors, the report can also show targeted regions for failing signals, and competing signals that are contributing to routing congestion.

The interactive heatmap uses color gradients to show clock sector congestion of clock signals terminating inside that sector. Hovering the cursor over a clock signal in the table highlights the sectors and routing elements that the clock signal uses. Selecting a clock signal in the table dims all irrelevant sectors and routing elements, while highlighting only the sectors and routing elements that the signal uses. The routings of the global clock signals on different layers display in the report using a stacked layer view.

Figure 6. Global Routing Wire Utilization (Single Layer)

Figure 7. Heat Map Sector and Routing Wire Utilization (All Layers)

Filter the display to Show Routing Utilization and Show Sector Utilization. The content of the table changes based on the selections you make in the heatmap. You can search for Signal Names, and then select the signal names to display its properties in the lower pane. Select any signal to Locate in other tools.

Figure 8. Signals Names and Property Details

1.3.3.3. Route Stage Reports

The Route stage reports describe all device resources that the Fitter allocates during routing. Details include the type, number, and overall percentage of each resource type. The Route stage also reports delay chain summary information.

Figure 9. Route Stage Reports

1.3.3.3.1. Global Router Wire Utilization Map Report

The Global Router Wire Utilization Map report displays global signal routing in an interactive heat-map. This report shows routing utilization rate of long and short routing wires. You can also use this report to obtain a detailed view of all the nets in the design. The report's heatmap grid shows the available device LABs. The color of the grid ranges from blue to red as the utilization rate changes from 0% to 100%. The color becomes pink if the utilization rate is greater than 100%.

Figure 10. Global Router Wire Utilization Heat Map (Multiple Layers)

Filter the Global Router Wire table to show short or long Wirelengths in all Directions. The content of the table changes based on the selections you make in the heatmap. You can search for Signal Names, and then single- or multi-select the signal names to display properties in the lower pane. Select one or more node in the table to Locate in various editors.

Figure 11. Global Router Wire Utilization Details

1.3.3.4. Retime Stage Reports

For Intel^® Stratix^® 10 and Intel^® Agilex™ designs, the Fitter generates detailed reports showing the results of the Retime stage, including the Retiming Limit Details report. This report lists the limiting reason, along with the critical chain and recommendations for the critical chain for each clock transfer.

Figure 12. Retiming Limit Details

1.3.3.5. Finalize Stage Reports

The Finalize stage reports describe final placement and routing operations, including:

HSLP Summary. For Intel^® Arria^® 10 and Intel^® Cyclone^® 10 GX designs, the Compiler converts unnecessary tiles to High-Speed or Low-Power (HSLP) tiles.
Post-route hold fix-up data. For Intel^® Stratix^® 10 and Intel^® Agilex™ designs, the Compiler reports hold violations for short paths following the Retime stage. The Fitter identifies and corrects the short paths with hold violations during the Fitter (Finalize) stage by adding routing wire along the paths.

Figure 13. Finalize Stage Reports ( Intel^® Stratix^® 10 Design)

1.4. Incremental Optimization Flow

Intel^® Quartus^® Prime Pro Edition supports incremental optimization at each stage of design compilation. In incremental optimization, you run and optimize each compilation stage independently before running the next compilation module in sequence. The Compiler preserves the results of each stage as a snapshot for analysis. When you make changes to your design or constraints, the Compiler only runs stages impacted by the change. Following synthesis or any Fitter stage, you can view results and perform timing analysis. Modify design RTL or Compiler settings, as needed. Then, re-run synthesis or the Fitter and evaluate the results of these changes. Repeat this process until the module performance meets requirements. This flow maximizes the results at each stage, without waiting for full compilation results.

Figure 14. Incremental Optimization Flow

Table 5. Incremental Optimization at Fitter Stages
Fitter Stage	Incremental Optimization
Plan	After this stage, you can run post-Plan timing analysis to verify timing constraints, and validate cross-clock timing windows. View the placement and properties of periphery (I/O).
Place	After this stage, validate resource and logic utilization in the Compilation Reports, and review placement of design elements in the Chip Planner.
Route	After this stage, perform detailed setup and hold timing closure in the Timing Analyzer, and view routing congestion via the Chip Planner.
Retime	After this stage, review the Retiming results in the Fitter report and correct any restrictions limiting further retiming optimization.

Note: The Compiler saves the planned, placed, routed, and retimed snapshots by default during full compilation only if you turn on Enable Intermediate Fitter Snapshots (Assignments > Settings > Compiler Settings). You can also run any intermediate Fitter stage independently to generate the snapshot for that stage.

1.4.1. Concurrent Analysis During Synthesis or Fitting

If you run Analysis & Synthesis, or the Fitter, you can access results while downstream Fitter stages are still running. Once the Concurrent Analysis icons become active in the dashboard, you can view the analysis without interrupting compilation.

During Analysis & Synthesis, you can click the Concurrent Analysis icons on the Dashboard to view reports, the RTL Viewer, or the Technology Map Viewer. While the Fitter is processing, you can analyze timing during the stages displaying the Timing Analyzer icon, and view Technology Map Viewer snapshots during Fitter stages. You should not modify timing constraints during concurrent analysis, because it affects the results of the underlying compile. However, you can halt a compile at any time, modify the .sdc constraints in your source file, and then click the Timing Analyzer icon to restart analysis with the modified constraints.

Figure 15. Concurrent Analysis Options

1.4.2. Analyzing Compiler Snapshots

You can analyze the results of a compilation snapshot to evaluate your design before running the next stage, or before running a full compilation. Analyze Compiler snapshots to isolate potential problems and reduce the overall time you spend running design compilation.

1.4.2.1. Running Snapshot Viewer

You can run the Snapshot Viewer to assist with timing closure and design analysis after running the Plan, Place, or Route stages of the Fitter. The Snapshot Viewer allows you to run various analysis tasks from the Flow Navigator to achieve faster timing closure and maximize design performance.

Figure 16. Snapshot Viewer Flow Navigator

Table 6. Snapshot Viewer Tasks and Commands
Design Task	Available at Snapshot	Snapshot Viewer Commands
Timing Closure—Analyze Failing Paths	Planned, Placed, Routed	List Top Failing Paths—lists all top failing paths in Snapshot Selections. Select a path to locate in RTL Viewer or Chip Planner. Show Full Timing Path in the Schematic—highlights the path in RTL Viewer for further analysis. Show Full Timing Path in the Chip View—highlights the path in Chip Planner for further analysis. View Path Characteristics—The path loads in the Timing Analyzer for further analysis.
Timing Closure—Analyze Clocking	Placed	Show Global Clock Visualization—loads the Global Signal Visualization report for the snapshot that allows you to visualize clock sector utilization.
Timing Closure—Analyze High Fanout Nets	Placed, Routed	List High Fanout Nets—lists high fan-out nets in Snapshot Selections. Select a path to locate in RTL Viewer or Chip Planner. Show High Fanout Nets in the Schematic—highlights the paths in RTL Viewer for further analysis. Show High Fanout Nets in the Chip View—highlights the paths in Chip Planner for further analysis.
Timing Closure—Validate Constraints	Planned, Placed	Timing Exceptions— the Tcl Console reports analysis of the project .sdc file.
Timing Closure—Analyze Congestion	Placed, Routed	Show Logic Lock Regions with Congestion Heat Map—the Chip Planner displays the Logic Lock regions in a congestion heat map for further analysis.

The following sections describe each analysis task in detail.

1.4.2.1.1. Analyzing Failing Paths with Snapshot Viewer

To run the Plan, Place, or Route stage of the Fitter, double-click the stage in the Compilation Dashboard.
After the stage completes, click the Snapshot Viewer icon for that stage in the Compilation Dashboard. The Snapshot Viewer opens.

Figure 17. Snapshot Viewer Icon
Under Analyze Failing Paths, click List Top Failing Paths.

Figure 18. List Top Failing Paths
In Snapshot Selections, select the failing path for analysis.

Figure 19. Snapshot Selections
Under Select Failing Path to Analyze, click Show Full Timing Path in the Chip View. The path displays and highlights in the Chip Planner for further analysis.
Under Select Failing Path to Analyze, click Show Full Timing Path in Schematic. The path displays and highlights in RTL Viewer for further analysis.

Figure 20. Show Full Timing Path in Schematic
Under Select Failing Path to Analyze, click View Path Characteristics. The path loads in the Timing Analyzer for further analysis.

Figure 21. View Path Characteristics in Timing Analyzer

1.4.2.1.2. Analyzing Clocking with Snapshot Viewer

Run the Place stage, and then click the Snapshot Viewer icon for the stage in the Compilation Dashboard. The Snapshot Viewer opens.
Under Analyze Clocking, double-click Show Global Clock Visualization. The Global Signal Visualization report displays in Snapshot Viewer for analysis of clock sector and routing utilization.

Figure 22. Global Clock Visualization Report

1.4.2.1.3. Analyzing High Fan-out Nets with Snapshot Viewer

To run the Place or Route stage of the Fitter, double-click the stage in the Compilation Dashboard.
After the stage completes, click the Snapshot Viewer icon for that stage in the Compilation Dashboard. The Snapshot Viewer opens.
Under Analyze High Fanout Nets, click Show High Fanout Nets in the Schematic. The path displays and highlights in Tech Map Viewer for further analysis.
Under Analyze High Fanout Nets, click Show High Fanout Nets in the Chip View. The path displays and highlights in the Chip Planner for further analysis.

Figure 23. Non-Global High Fan-Out Signal in Chip Planner

1.4.2.1.4. Validating Timing Constraints with Snapshot Viewer

To run the Plan or Place stage of the Fitter, double-click the stage in the Compilation Dashboard.
After the stage completes, click the Snapshot Viewer icon for that stage in the Compilation Dashboard. The Snapshot Viewer opens.
Under Validate Constraints, double-click Timing Exceptions. The Timing Exception Results report open, allowing additional analysis and locating to other tools.

Figure 24. Validate Constraints—Timing Exceptions Report

1.4.2.1.5. Analyzing Congestion with Snapshot Viewer

To run the Place or Route stage of the Fitter, double-click the stage in the Compilation Dashboard.
After the stage completes, click the Snapshot Viewer icon for that stage in the Compilation Dashboard. The Snapshot Viewer opens.
Under Analyze Congestion, double-click Show Logic Lock Regions with Congestion Heat Map. The Chip Planner displays the Logic Lock regions in a congestion heat map for further analysis.

Figure 25. Show Logic Lock Regions with Congestion Heat Map

1.4.3. Validating Periphery (I/O) after the Plan Stage

The Compiler begins periphery placement during the Plan stage, and reports data about periphery elements, such as I/O pins and PLLs. After the Plan stage, view the Compilation Report to evaluate the placement of periphery elements before proceeding to the next compilation stage.

Figure 26. Plan Stage Periphery Placement Message

In the Compilation Dashboard, click the Plan stage.
In the Compilation Report, under the Plan Stage folder, click the Input Pins, Output Pins, I/O Bank Usage, PLL Usage Summary, or other reports. Verify attributes of the I/O pins, such as the physical pin location, I/O standards, and PLL placement.

Figure 27. Input Pins Report
For Intel^® Arria^® 10 and Intel^® Cyclone^® 10 GX designs, click Global & Other Fast Signals Summary report to verify which clocks the Compiler promotes to global clocks. Clock planning occurs after the Early Place stage for Intel^® Stratix^® 10 and Intel^® Agilex™ designs.

Figure 28. Global & Other Fast Signals Report Shows Clock Promotion ( Intel^® Arria^® 10 and Intel^® Cyclone^® 10 GX FPGAs)

1.5. Fast Forward Compilation Flow

The Intel^® Hyperflex™ architecture includes multiple Hyper-Registers in every routing segment and block input. Maximizing the use of Hyper-Registers improves the balance of time delays between registers, and mitigates critical path delays. Fast Forward compilation generates design recommendations to help you to break performance bottlenecks and maximize use of Hyper-Registers to drive the highest performance in Intel^® Stratix^® 10 and Intel^® Agilex™ designs.

Figure 29. Hyper-Registers in Intel^® Hyperflex™ Architecture

The Fast Forward compilation reports show precisely where to make the most impact with RTL changes, and the performance benefits you can expect from each change after removing retiming restrictions. The Fast Forward compilation flow includes the following high-level steps:

Figure 30. Fast Forward Compile Flow

1.5.1. Step 1: Run Register Retiming

Register retiming improves design performance by moving registers out of ALMs and retimes them into Hyper-Registers in the Intel^® Stratix^® 10 and Intel^® Agilex™ device interconnect.

The Fitter runs the Retime stage automatically following place and route when you target an Intel^® Stratix^® 10 or Intel^® Agilex™ device. Alternatively, start or stop the individual Retime stage in the Compilation Dashboard. After running register retiming, view the Fitter reports to optimize remaining critical paths.

To run register retiming:

Click Retime on the Compilation Dashboard. The Compiler runs prerequisite stages automatically before running Retime stage.

Figure 31. Retiming Stage in Compilation Dashboard
Review the results of the register retiming stage, as Step 2: Review Retiming Results describes.

1.5.2. Step 2: Review Retiming Results

Follow these steps to review the results of register retiming. Use the results to determine if additional performance improvements are necessary and possible by removing retiming limits.

To open the Retiming Limit Details report, click the Report icon for the Retime stage in the Compilation Dashboard. The Retiming Limit Details lists the number of registers moved, their paths, and the limiting reason preventing further retiming.

Figure 32. Retiming Limit Details

To further optimize, resolve any Limiting Reason in your design, and then rerun the Retime stage, as necessary.

Table 7. Retiming Limit Details Report Data
Report Data	Description
Clock Transfer	Lists each clock domain in your design. Click the domain to display data about each entry.
Limiting Reason	Specifies any design condition that prevent further register retiming improvement, such as any of the following conditions: Insufficient Registers—indicates insufficient quantity of registers at either end of the chain for retiming. Adding more registers can improve performance. Short Path/Long Path—indicates that the critical chain has dependent paths with conflicting characteristics. For example, one path improves performance with more registers, and another path has no place for additional hyper-registers. Path Limit—indicates that there are no further Hyper-Register locations available on the critical path, or the design reached a performance limit of the current place and route. Loops—indicates a feedback path in a circuit. When the critical chain includes a feedback loop, retiming cannot change the number of registers in the loop without changing functionality. The Compiler can retime around the loop without changing functionality. However, the Compiler cannot place additional registers in the loop.
Critical Chain Details	Lists register timing path associated with the retiming limitations. Right-click any path to Locate Critical Chain in Technology Map Viewer.

If register retiming achieves all performance goals for your design, proceed to Fitter (Finalize) and Timing Analysis stages of compilation.
If your design requires further optimization, run Fast Forward Timing Closure Recommendations as Step 3: Run Fast Forward Compile describes.

1.5.2.1. Locate Critical Chains

The Retiming Limit Details reports the design paths that limit further register retiming. Right-click any path to locate to the path in the Technology Map Viewer - Post-fitting view. This viewer displays a schematic representation of the complete design after place, route, and register retiming. To view the retimed netlist in the Technology Map Viewer, follow these steps:

To open the Retiming Limit Details report, click the Report icon next to the Retime stage in the Compilation Dashboard.
Right-click any path in the Retiming Limit Details report and click Locate Critical Chain in Technology Map Viewer. The netlist displays as a schematic in the Technology Map Viewer.

Figure 33. Technology Map Viewer

Figure 34. Post-Fit Viewer After RetimingIn the post-fit viewer, bypassed ALM registers are gray. Hyper-Registers are pink with the word "HYPER" below them. Used ALMs are pink without the word "HYPER" below them

1.5.3. Step 3: Run Fast Forward Compile

Fast Forward compilation generates design-specific timing closure recommendations, and predicts the maximum performance after the removal of all timing restrictions.

You can review the Fast Forward recommendations and implement the changes in your RTL that remove timing restrictions and enable mobility within the netlist for register Hyper-Retiming.

You can run Fast Forward compilation for the entire design hierarchy, or for only specific instances in the hierarchy, as Fast Forward Compile By Hierarchy describes.

To generate Fast Forward timing closure recommendations, follow these steps:

Optionally, specify any of the following any of the following options if you want to automate or refine Fast Forward analysis:
- If you want to run Fast Forward compilation during each full compilation, click Assignments > Settings > Compiler Settings > HyperFlex and enable Run Fast Forward Timing Closure Recommendations during compilation.
- If you want to modify how Fast Forward compilation interprets specific I/O and block types, click Assignments > Settings > Compiler Settings > HyperFlex > Advanced Settings.
On the Compilation Dashboard, click Fast Forward Timing Closure Recommendations. The Compiler runs prerequisite synthesis or Fitter stages automatically, as needed, and generates timing closure recommendations in the Compilation Report.

Figure 35. Running Fast Forward Compilation
View timing closure recommendations in the Compilation Report to evaluate design performance and implement key RTL performance improvements, as Step 4: Review Fast Forward Results describes.

1.5.3.1. Fast Forward Compile By Hierarchy

When enabled, Fast Forward compile runs on the entire design hierarchy by default. Optionally, you can specify the Enable Hyper-Retimer Fast Forward Hierarchy analysis during compilation assignment to include or exclude specific design subhierarchies and instances during Fast Forward compile. This technique allows you to focus Fast Forward reporting and optimization efforts on only specific areas of the design. Fast Forward compilation by hierarchy generates the same reports as Fast Forward compilation of the entire hierarchy.

Follow these steps to include or exclude specific design subhierarchies and instances during Fast Forward compilation:

To enable the optional Fast Forward Compilation stage during full compilation, turn on Fast Forward Timing Closure Recommendations on the Compilation Dashboard, or add the following assignment to the project .qsf:
```
set_global_assignment -name FLOW_ENABLE_HYPER_RETIMER_FAST_FORWARD ON
```
Figure 36. Enable Fast Forward Timing Closure Recommendations
To exclude a specific hierarchy or entity from Fast Forward Compilation, set the Enable Hyper-Retimer Fast Forward Hierarchy analysis during compilation assignment to Off in the Assignment Editor, or add the following assignment to the project .qsf for each hierarchy or entity that you want to exclude:
```
set_global_assignment -name HYPER_RETIMER_FAST_FORWARD_ON_HIERARCHY OFF \
    <INSTANCE MODULE NAME>
```
To include a specific hierarchy or entity from Fast Forward Compilation, set the Enable Hyper-Retimer Fast Forward Hierarchy analysis during compilation assignment to On in the Assignment Editor, or add the following assignment to the project .qsf for each hierarchy or entity that you want to include:
```
set_global_assignment -name HYPER_RETIMER_FAST_FORWARD_ON_HIERARCHY ON \
     <INSTANCE MODULE NAME>
```
Click the Fast Forward Timing Closure Recommendations stage on the Compilation Dashboard, or click Processing > Start Compilation to run a full compilation that includes Fast Forward Compile.

You can mix ON and OFF assignments for the same instance within a single .qsf. If you assign mixed ON and OFF assignments to the same instance, the last assignment that appears in the .qsf takes precedence.

If you want to perform Fast Forward analysis for a subset of the hierarchies in your design, turn off Fast Forward analysis for all hierarchies that you want to omit from analysis. Otherwise, turn off Fast Forward analysis at the root hierarchy, and turn on Fast Forward analysis for the hierarchies that you want to analyze. The following examples show some of these assignment combinations, with respect to the Example Design Hierarchy.

Figure 37. Example Design Hierarchy

# This runs Fast Forward Compile on the entire hierarchy: A,B,C,D,E,F
# This produces the same result as if FAST_FORWARD_HIERARCHY was not set in the QSF

set_global_assignment -name FLOW_ENABLE_HYPER_RETIMER_FAST_FORWARD ON
set_instance_assignment -name HYPER_RETIMER_FAST_FORWARD_ON_HIERARCHY ON -to |

# Runs Fast Forward Compile on B and E only, ignores A,C,D,F

set_global_assignment -name FLOW_ENABLE_HYPER_RETIMER_FAST_FORWARD ON
set_instance_assignment -name HYPER_RETIMER_FAST_FORWARD_ON_HIERARCHY OFF -to |
set_instance_assignment -name HYPER_RETIMER_FAST_FORWARD_ON_HIERARCHY ON -to B

# Runs  Fast Forward Compile on C only, ignores A,B,D,E,F

set_global_assignment -name FLOW_ENABLE_HYPER_RETIMER_FAST_FORWARD ON
set_instance_assignment -name HYPER_RETIMER_FAST_FORWARD_ON_HIERARCHY OFF -to |
set_instance_assignment -name HYPER_RETIMER_FAST_FORWARD_ON_HIERARCHY ON -to C
set_instance_assignment -name HYPER_RETIMER_FAST_FORWARD_ON_HIERARCHY OFF -to F

# ON instance HYPER_RETIMER_FAST_FORWARD_ON_HIERARCHY takes precedence
# Fast Forward Compile runs on only C and F
# If the assignments were reversed then FFC would not run

set_global_assignment -name FLOW_ENABLE_HYPER_RETIMER_FAST_FORWARD ON
set_instance_assignment -name HYPER_RETIMER_FAST_FORWARD_ON_HIERARCHY OFF -to |
set_instance_assignment -name HYPER_RETIMER_FAST_FORWARD_ON_HIERARCHY OFF -to C
set_instance_assignment -name HYPER_RETIMER_FAST_FORWARD_ON_HIERARCHY ON -to C

# This runs on A,B,C,F

set_global_assignment -name FLOW_ENABLE_HYPER_RETIMER_FAST_FORWARD ON
set_instance_assignment -name HYPER_RETIMER_FAST_FORWARD_ON_HIERARCHY OFF -to D
set_instance_assignment -name HYPER_RETIMER_FAST_FORWARD_ON_HIERARCHY OFF -to E

Note: Instance assignments apply to the post-fit netlist. Therefore, you may need to define design partitions. Otherwise, instance names can change during synthesis, leading to unexpected assignment results. Refer to Creating a Design Partition.

1.5.3.2. HyperFlex Settings

The HyperFlex settings page controls whether Fast Forward Compilation analyzes and reports results for specific logical structures in the Intel^® Hyperflex™ architecture. You access this page by clicking Assignments > Settings > HyperFlex. Turn on Run Fast Forward Timing Closure Recommendations during compilation to enable Fast Forward analysis during the compilation flow by default. To access the following additional settings, click Advanced Settings.

Table 8. Advanced HyperFlex Settings
Option	Description
Fast Forward Compile Asynchronous Clears	Specifies how Fast Forward analysis accounts for registers with asynchronous clear signals. The options are: Auto—the Compiler identifies asynchronous clears as asynchronous until they limit timing performance during Fast Forward Compilation, at which point the Compiler identifies the asynchronous clears as removed. Preserve—the Compiler never assumes removal or conversion of asynchronous clears for Fast Forward analysis.
Fast Forward Compile Cut All Clock Transfers	Cuts all clock transfers in Fast Forward Compilation analysis.
Fast Forward Compile Fully Registered DSP Blocks	Specifies how Fast Forward analysis accounts for DSP blocks that limit performance. Enable this option to generate results as if all DSP blocks are fully registered.
Fast Forward Compile Fully Registered RAM Blocks	Specifies how Fast Forward analysis accounts for RAM blocks that limit performance. Enable this option to analyze the blocks as fully registered.
Fast Forward Compile Maximum Additional Pipeline Stages	Specifies the maximum number of pipeline stages that Fast Forward compilation explores.
Fast Forward Compile User Preserve Directives	Specifies how Fast Forward compilation accounts for restrictions from user-preserve directives.

1.5.4. Step 4: Review Fast Forward Results

After running Fast Forward Compilation, review the reports in the Fast Forward Timing Closure Recommendations folder of the Compilation Report to determine which recommendations are appropriate and practical for your design functionality and performance goals. The following section describes these reports.

1.5.4.1. Clock Fmax Summary Report

The Clock Fmax Summary in the Fast Forward Timing Closure Recommendations report folder reports the current f_max and potential performance achievable for each clock domain after Hyper-Retiming, Hyper-Pipelining, and Hyper-Optimization steps. Review the Clock Fmax Summary data to determine whether each potential performance improvement warrants further investigation and potential optimization of design RTL.

Figure 38. Current and Potential Performance in Clock Fmax Summary

1.5.4.2. Fast Forward Details Report

The Fast Forward Details report recommends the design modifications necessary to achieve Fast Forward compilation performance levels. Some recommendations may be functionally impossible or impractical for your design. Consider which recommendations you can implement in RTL to achieve similar performance improvement.

Click any optimization Step in the report to view the implementation details and performance calculations for that step.

Figure 39. Fast-Forward Details Report

Figure 40. Recommendations for Critical Chain

Right-click any path to locate to the critical chain in the Fast Forward Viewer. The Fast Forward Viewer displays a predictive representation of the complete design, after implementation of all Fast Forward recommendations.

Figure 41. Locate Critical Chain in Fast Forward Viewer

Figure 42. Fast Forward Viewer Shows Predictive Results

Table 9. Fast Forward Details Report Data
Report Field	Description
Step	Displays the pre-optimized Base Performance f_MAX, the recommended Fast Forward optimization steps, and the Fast Forward Limit critical path that prevents further optimization.
Fast Forward Optimizations Analyzed	Summarizes the optimizations necessary to implement each optimization step.
Estimated Fmax	Specifies the potential f_MAX performance if you implement all Fast Forward optimization steps.
Optimizations Analyzed For Fast Forward Step	Lists design recommendations hierarchically for the selected Step. Click the text to expand the report and view the clock domain, the affected module, and the bus and bits that require modification.
Optimizations Analyzed (Cumulative)	Accumulated list of all design changes necessary to reach the selected Step.
Critical Chain at Fast Forward Limit	Displays information about any path that continues to limit Hyper-Retiming even after application of all Fast Forward steps. The critical chain is any path that limits further Hyper-Retiming. Click the Fast Forward Limit step to display this field.
Recommendations for Critical Chain	Lists register timing path associated with the retiming limitations. Right-click any path to Locate Critical Chain in Fast Forward Viewer.

1.5.5. Step 5: Implement Fast Forward Recommendations

Implement the Fast Forward timing closure recommendations in your design RTL and rerun synthesis and the Retime stage to perform Hyper-Retiming and realize the predictive performance gains. The amount and type of changes that you implement depends on your performance goals. For example, if you can achieve the target f_MAX with simple asynchronous clear removal or conversion, you can stop design optimization after making those changes. For more information, refer to Retiming Restrictions and Workarounds.

Implement one or more Fast Forward recommendations in your design RTL, such as any of the following techniques:
- Remove limitations of control logic, such as long feedback loops and state machines.
- Restructure logic to use functionally equivalent feed-forward or pre-compute paths, rather than long combinatorial feedback path.
- Reduce the delay of ‘Long Paths’ in the chain. Use standard timing closure techniques to reduce delay. Excessive combinational logic, sub-optimal placement, and routing congestion cause delay on paths.
- Insert more pipeline stages in ‘Long Paths’ in the chain. Long paths have the most delay between registers in the critical chain.
- Increase the delay (or add pipeline stages to ‘Short Paths’ in the chain).
- Explore performance and implement the RTL changes to your code until you reach the desired performance target.
Implement your RTL changes and perform Hyper-Retiming by re-running the Retime stage on the Compilation Dashboard (which also reruns prerequisite synthesis and fitting stages).

1.5.6. Retiming Restrictions and Workarounds

The Compiler identifies the register chains in your design that limit further optimization through Hyper-Retiming. The Compiler refers to these related register-to-register paths as a critical chain. The f_MAXof the critical chain and its associated clock domain is limited by the average delay of a register-to-register path, and quantization delays of indivisible circuit elements like routing wires. There are a variety of situations that cause retiming restrictions. Retiming restrictions exist because of hardware characteristics, software behavior, or are inherent to the design. The Retiming Limit Details report the limiting reasons preventing further retiming, and the registers and combinational nodes that comprise the chain. The Fast Forward recommendations list the steps you can take to remove critical chains and enable additional register retiming.

In Figure 43, the red line represents the same critical chain. Timing restrictions prevent register A from retiming forward. Timing restrictions also prevent register B from retiming backwards. A loop occurs when register A and register B are the same register.

Figure 43. Sample Critical Chain

Fast Forward recommendations for the critical chain include:

Reduce the delay of ‘Long Paths’ in the chain. Use standard timing closure techniques to reduce delay. Combinational logic, sub-optimal placement, and routing congestion, are among the reasons for path delay.
Insert more pipeline stages in ‘Long Paths’ in the chain. Long paths are the parts of the critical chain that have the most delay between registers.
Increase the delay (or add pipeline stages to ‘Short Paths’ in the chain).

Particular registers in critical chains can limit performance for many other reasons. The Compiler classifies the following types of reasons that limit further optimization by retiming:

Insufficient Registers
Loop
Short path/long path
Path limit

After understanding why a particular critical chain limits your design’s performance, you can then make RTL changes to eliminate that bottleneck and increase performance.

Table 10. Hyper-Register Support for Various Design Conditions
Design Condition	Hyper-Register Support
Initial conditions that cannot be preserved	Hyper-Registers do have initial condition support. However, you cannot perform some retiming operations while preserving the initial condition stage of all registers (that is, the merging and duplicating of Hyper-Registers). If this condition occurs in the design, the Fitter does not retime those registers. This retiming limit ensures that the register retiming does not affect design functionality.
Register has an asynchronous clear	Hyper-Registers support only data and clock inputs. Hyper-Registers do not have control signals such as asynchronous clears, presets, or enables. The Fitter cannot retime any register that has an asynchronous clear. Use asynchronous clears only when necessary, such as state machines or control logic. Often, you can avoid or remove asynchronous clears from large parts of a datapath.
Register drives an asynchronous signal	This design condition is inherent to any design that uses asynchronous resets. Focus on reducing the number of registers that are reset with an asynchronous clear.
Register has don’t touch or preserve attributes	The Compiler does not retime registers with these attributes. If you use the `preserve` attribute to manage register duplication for high fan-out signals, try removing the `preserve` attribute. The Compiler may be able to retime the high fan-out register along each of the routing paths to its destinations. Alternatively, use the `dont_merge` attribute. The Compiler retimes registers in ALMs, DDIOs, single port RAMs, and DSP blocks.
Register is a clock source	This design condition is uncommon, especially for performance-critical parts of a design. If this retiming restriction prevents you from achieving the required performance, consider whether a PLL can generate the clock, rather than a register.
Register is a partition boundary	This condition is inherent to any design that uses design partitions. If this retiming restriction prevents you from achieving the required performance, add additional registers inside the partition boundary for Hyper-Retiming.
Register is a block type modified by an ECO operation	This restriction is uncommon. Avoid the restriction by making the functional change in the design source and recompiling, rather than performing an ECO.
Register location is an unknown block	This restriction is uncommon. You can often work around this condition by adding extra registers adjacent to the specified block type.
Register is described in the RTL as a latch	Hyper-Registers cannot implement latches. The Compiler infers latches because of RTL coding issues, such as incomplete assignments. If you do not intend to implement a latch, change the RTL.
Register location is at an I/O boundary	All designs contain I/O, but you can add additional pipeline stages next to the I/O boundary for Hyper-Retiming.
Combinational node is fed by a special source	This condition is uncommon, especially for performance-critical parts of a design.
Register is driven by a locally routed clock	Only the dedicated clock network clocks Hyper-Registers. Using the routing fabric to distribute clock signals is uncommon, especially for performance-critical parts of a design. Consider implementing a small clock region instead.
Register is a timing exception end-point	The Compiler does not retime registers that are sources or destinations of .sdc constraints.
Register with inverted input or output	This condition is uncommon.
Register is part of a synchronizer chain	The Fitter optimizes synchronizer chains to increase the mean time between failure (MTBF), and the Compiler does not retime registers that are detected or marked as part of a synchronizer chain. Add more pipeline stages at the clock domain boundary adjacent to the synchronizer chain to provide flexibility for the retiming. Alternatively, you can reduce the detection number for that particular synchronizer chain Synchronization Register Chain Length (default is 3). In some cases a synchronizer chain isn't necessary, and shouldn't be inferred.
Register with multiple period requirements for paths that start or end at the register (cross-clock boundary)	This situation occurs at any cross-clock boundary, where a register latches data on a clock at one frequency, and fans out to registers running at another frequency. The Compiler does not retime registers at cross-clock boundaries. Consider adding additional pipeline stages at one side of the clock domain boundary, or the other, to provide flexibility for retiming.

1.6. Full Compilation Flow

Use these steps to run a full compilation of an Intel^® Quartus^® Prime project. A full compilation includes IP Generation, Analysis & Synthesis, Fitter, Timing Analyzer, and any optional Compiler modules you enable.

Before running a full compilation, specify any of the following project settings:
- To specify the target FPGA device or development kit, click Assignments > Device.
- To specify device and pin options for the target FPGA device, click Assignments > Device > Device and Pin Options.
- To specify options that affect compilation processing time and netlist preservation, click Assignments > Settings > Compilation Process Settings.
- To specify the Compiler's high-level optimization strategy, click Assignments > Settings > Compiler Settings. Specify a Balanced strategy, or optimize for Performance, Area, Routability, Power, or Compile Time. The Compiler targets the optimization goal you specify. Optimization Modes describes these options in detail.
- To specify synthesis algorithm and other Advanced Settings for synthesis and fitting, click Assignments > Settings > Compiler Settings. Turn on Enable Intermediate Fitter Snapshots to preserve the planned, placed, routed, and retimed snapshots by default during full compilation.
- To specify required timing conditions for proper operation of your design, click Tools > Timing Analyzer.
To run full compilation, click Processing > Start Compilation.
Note:
- To save processing time, the Compiler only preserves the planned, placed, routed, and retimed snapshots by default during full compilation if you turn on Enable Intermediate Fitter Snapshots (Assignments > Settings > Compiler Settings).
- Early Place does not run during full compilation by default. To enable Early Place during full compilation, click Assignments > Settings > Compiler Settings > Advanced Settings (Fitter) to modify the Run Early Place during compilation option.

1.7. Exporting Compilation Results

When you run compilation, the Compiler preserves a database of results in a Quartus Database File (.qdb). The .qdb contains the data to reproduce similar results in another project, or in a later software version. You can export your project's compilation results database for import to another project or migration to a later Intel^® Quartus^® Prime software version.

You can export the .qdb for your entire project or for a design partition that you define in your project. When migrating the database for an entire project, you can export the compilation database in a version-compatible format to ensure compatibility for import to a later software version. Although you cannot directly read the contents of the .qdb file after export, you can view attributes of the database file in the Quartus Database File Viewer.

Table 11. Exporting Compilation Results
To Export Compilation Results For	Method	Description
Complete Design	Click Project > Export Design	Saves compilation results for the entire project in a version-compatible Quartus database file (.qdb) that you can import to another project or migrate to a later version of the Intel^® Quartus^® Prime software. You can export the results for the synthesized or final compilation snapshot.
Design Partition	Click Project > Export Design Partition	Saves compilation results for a design partition as a Partition Database File (.qdb) that you can import to another project using the same version of the Intel^® Quartus^® Prime software. You can export the results for the synthesized or final compilation snapshot.

1.7.1. Exporting a Version-Compatible Compilation Database

To export a project compilation database to a format that ensures version-compatibility with a later version of the Intel^® Quartus^® Prime software:

In the Intel^® Quartus^® Prime software, open the project that you want to export.
Generate synthesis or final compilation results by running one of the following commands:
- Click Processing > Start > Start Analysis & Synthesis to generate synthesized compilation results.
- Click Processing > Start Compilation to generate final compilation results.
Click Project > Export Design. Select the synthesized or final Snapshot.

Figure 44. Export Design Dialog Box
Specify a name for the Quartus Database File to contain the exported results, and click OK.
To include the exported design's settings and constraint files, copy the .qsf and .sdc files to the import project directory.

1.7.2. Importing a Version-Compatible Compilation Database

Follow these steps to import a project compilation database into a newer version of the Intel^® Quartus^® Prime software:

Export a version-compatible compilation database for a complete design, as Exporting a Version-Compatible Compilation Database describes.
In a newer version of the Intel^® Quartus^® Prime software, open the original project. Click Yes if prompted to open a project created with a different software version.
Click Project > Import Design and specify the Quartus Database File. To remove previous results, turn on Overwrite existing project's databases

Figure 45. Import Design Dialog Box
Click OK.
When you compile the imported design, run only Compiler stages that occur after the stage the .qdb preserves, rather than running a full compilation. For example, if you import a version-compatible database that contains the synthesis snapshot, start compilation with the Fitter (Processing > Start > Start Fitter). If you import a version-compatible database the contains the final snapshot, start compilation with Timing Analysis (Signoff) (Processing > Start > Start Timing Analysis (Signoff)).

1.7.3. Creating a Design Partition

A design partition is a logical, named, hierarchical boundary that you can assign to an instance in your design. Defining a design partition allows you to optimize and lock down the compilation results for individual blocks. You can then optionally export the compilation results of a design partition for reuse in another context, such as reuse in another project.

Figure 46. Design Partitions in Design Hierarchy

Follow these steps to create and modify design partitions:

In the Intel^® Quartus^® Prime software, open the project that you want to partition.
Generate synthesis or final compilation results by running one of the following commands:
- Click Processing > Start > Start Analysis & Synthesis to generate synthesized compilation results.
- Click Processing > Start Compilation to generate final compilation results.
In the Project Navigator, right-click an instance in the Hierarchy tab, click Design Partition > Set as Design Partition.

Figure 47. Creating a Design Partition from the Project Hierarchy
To view and edit all design partitions in the project, click Assignments > Design Partitions Window.

Figure 48. Design Partitions Window

Specify the properties of the design partition in the Design Partitions Window. The following settings are available:

Table 12. Design Partition Settings
Option	Description
Partition Name	Specifies the partition name. Each partition name must be unique and consist of only alphanumeric characters. The Intel^® Quartus^® Prime software automatically creates a top-level (`\|`) "root_partition" for each project revision.
Hierarchy Path	Specifies the hierarchy path of the entity instance that you assign to the partition. You specify this value in the Create New Partition dialog box. The root partition hierarchy path is `\|`.
Type	Double-click to specify one of the following partition types that control how the Compiler processes and implements the partition: Default—Identifies a standard partition. The Compiler processes the partition using the associated design source files. Reconfigurable—Identifies a reconfigurable partition in a partial reconfiguration flow. Specify the Reconfigurable type to preserve synthesis results, while allowing refit of the partition in the PR flow. Reserved Core—Identifies a partition in a block-based design flow that is reserved for core development by a Consumer reusing the device periphery.
Preservation Level	Specifies one of the following preservation levels for the partition: Not Set—specifies no preservation level. The partition compiles from source files. synthesized—the partition compiles using the synthesized snapshot. final—the partition compiles using the final snapshot. With Preservation Level of synthesized or final, changes to the source code do not appear in the synthesis.
Empty	Specifies an empty partition that the Compiler skips. This setting is incompatible with the Reserved Core and Partition Database File settings for the same partition. The Preservation Level must be Not Set. An empty partition cannot have any child partitions.
Partition Database File	Specifies a Partition Database File (.qdb) that the Compiler uses during compilation of the partition. You export the .qdb for the stage of compilation that you want to reuse (synthesized or final). Assign the .qdb to a partition to reuse those results in another context.
Entity Re-binding	PR Flow—specifies the entity that replaces the default persona in each implementation revision. Root Partition Reuse Flow —specifies the entity that replaces the reserved core logic in the consumer project.
Color	Specifies the color-coding of the partition in the Chip Planner and Design Partition Planner displays.
Post Synthesis Export File	Automatically exports post-synthesis compilation results for the partition to the .qdb that you specify, each time Analysis & Synthesis runs. You can automatically export any design partition that does not have a preserved parent partition, including the root_partition.
Post Final Export File	Automatically exports post-final compilation results for the partition to the .qdb that you specify, each time the final stage of the Fitter runs. You can automatically export any design partition that does not have a preserved parent partition, including the root_partition.

1.7.4. Exporting a Design Partition

The following steps describe export of design partitions that you create in your project.

When you compile a design containing design partitions, the Compiler can preserve a synthesis or final snapshot of results for each partition. You can export the synthesized or final compilation results for individual design partitions with the Export Design Partition dialog box.

If the partition includes any entity-bound .sdc files, you can include those constraints in the .qdb. In addition, you can automate export of one or more partitions in the Design Partitions Window.

Manual Design Partition Export

Follow these steps to manually export a design partition with the Export Design Partition dialog box:

Open a project and create one or more design partitions. Creating a Design Partition describes this process.
Run synthesis (Processing > Start > Start Analysis & Synthesis) or full compilation (Processing > Start Compilation), depending on which compilation results that you want to export.
Click Project > Export Design Partition, and specify one or more options in the Export Design Partition dialog box:
Figure 49. Export Design Partition Dialog Box
- Select the Partition name and the compilation Snapshot for export.
- To include any entity-bound .sdc files in the exported .qdb, turn on Include entity-bound SDC files for the selected partition.
Click OK. The compilation results for the design partition exports to the file that you specify.

Automated Design Partition Export

Follow these steps to automatically export one or more design partitions following each compilation:

Open a project containing one or more design partitions. Creating a Design Partition describes this process.
To open the Design Partitions Window, click Assignments > Design Partitions Window.
To automatically export a partition with synthesis results after each time you run synthesis, specify the a .qdb export path and file name for the Post Synthesis Export File option for that partition. If you specify only a file name without path, the file exports to the output_files directory after compilation.
To automatically export a partition with final snapshot results each time you run the Fitter, specify a .qdb file name for the Post Final Export File option for that partition. If you specify only a file name without path, the file exports to the output_files directory after compilation.

Figure 50. Specifying Export File in Design Partitions Window

.qsf Equivalent Assignment:

set_instance_assignment -name EXPORT_PARTITION_SNAPSHOT_<FINAL|SYNTHESIZED> \
     <hpath> -to <file_name>.qdb

1.7.5. Reusing a Design Partition

You can reuse the compilation results of a design partition exported from another Intel^® Quartus^® Prime project. Reuse of a design partition allows you to share a synthesized or final design block with another designer. Refer to Intel Quartus Prime Pro Edition User Guide: Block-Based Design for more information about reuse of design partitions.

To reuse an exported design partition in another project, you assign the exported partition .qdb to an appropriately configured design partition in the target project via the Design Partition Window:

Export a design partition with the appropriate snapshot, as Exporting a Design Partition describes.
Open the target Intel^® Quartus^® Prime project that you want to reuse the exported partition.
Click Processing > Start > Start Analysis & Elaboration.
Click Assignments > Design Partitions Window, and then create an appropriately sized design partition to contain the logic and compilation results of the exported .qdb.
Click the Partition Database File option for the new partition and select the exported .qdb file.

Figure 51. Partition Database File Setting in Design Partitions Window
Specify any other properties of the design partition in the Design Partitions Window. The Compiler uses the partition's assigned .qdb as the source.

1.7.6. Viewing Quartus Database File Information

Although you cannot directly read a .qdb file, you can view helpful attributes about the file to quickly identify its contents and suitability for use.

The Intel^® Quartus^® Prime software automatically stores metadata about the project of origin when you export a Quartus Database File (.qdb). The Intel^® Quartus^® Prime software automatically stores metadata about the project of origin and resource utilization when you export a Partition Database File (.qdb) from your project. You can then use the Quartus Database File Viewer to display the attributes any of these .qdb files.

Figure 52. Quartus Database File Viewer

Follow these steps to view the attributes of a .qdb file:

In the Intel^® Quartus^® Prime software, click File > Open, select Design Files for Files of Type, and select a .qdb file.
Click Open. The Quartus Database File Viewer displays project and resource utilization attributes of the .qdb.
Alternatively, run the following command-line equivalent:
```
quartus_cdb --extract_metadata --file <archive_name.qdb> \
     --type quartus --dir <extraction_directory> \
     [--overwrite]
```

1.7.6.1. QDB File Attribute Types

The Quartus Database Viewer can display the following attributes of a .qdb file:

Table 13. QDB File Attributes
QDB Attribute Types	Attribute	Example
Project Information	Contents	`Partition`
	Date	`Thu Jan 23 10:56:23 2018`
	Device	`10AX016C3U19E2LG`
	Entity (if Partition)	`Counter`
	Family	`Arria 10`
	Partition Name	`root_partition`
	Revision Name	`Top`
	Revision Type	`PR_BASE`
	Snapshot	`synthesized`
	Version	`18.1.0 Pro Edition`
	Version-Compatible	`Yes`
Resource Utilization (exported for partition QDB only)	For synthesized snapshot partition lists data from the Synthesis Resource Usage Summary report.	`Average fan-out.16` `Dedicated logic registers:14` `Estimate of Logic utilization:1` `I/O pins:35` `Maximum fan-out:2` `Maximum fan-out node:counter[23]` `Total DSP Blocks:0` `Total fan-out:6` ...
Resource Utilization (exported for partition QDB only)	For the final snapshot partition, lists data from the Fitter Partition Statistics report.	`Average fan-out:.16` `Combinational ALUTs: 16` `I/O Registers` `M20Ks` ...

1.7.7. Clearing Compilation Results

You can clean the project database if you want to remove prior compilation results for all project revisions or for specific revisions. For example, you must clear previous compilation results before importing a version-compatible database to an existing project.

Click Project > Clean Project.
Select All revisions to clear the databases for all revisions of the current project, or specify a Revision name to clear only the revision’s database you specify.
Click OK. A message indicates when the database is clean.

Figure 53. Clean Project Dialog Box Cleans the Project Database

1.8. Synthesis Language Support

The Intel^® Quartus^® Prime software synthesizes standard Verilog HDL, VHDL, and SystemVerilog design files.

1.8.1. Verilog and SystemVerilog Synthesis Support

Intel^® Quartus^® Prime synthesis supports the following Verilog HDL language standards:

Verilog-1995 (IEEE Standard 1364-1995)
Verilog-2001 (IEEE Standard 1364-2001)
SystemVerilog-2005 (IEEE Standard 1800-2005)
SystemVerilog-2009 (IEEE Standard 1800-2009)
SystemVerilog-2012 (IEEE Standard 1800-2012)

The following important guidelines apply to Intel^® Quartus^® Prime synthesis of Verilog HDL and SystemVerilog:

The Compiler uses the Verilog-2001 standard by default for files with an extension of .v, and the SystemVerilog standard for files with the extension of .sv.
If you use scripts to add design files, you can use the -HDL_VERSION command to specify the HDL version for each design file.
Compiler support for Verilog HDL is case sensitive in accordance with the Verilog HDL standard.
The Compiler supports the compiler directive `define, in accordance with the Verilog HDL standard.
The Compiler supports the include compiler directive to include files with absolute paths (with either “/” or “\” as the separator), or relative paths.
When searching for a relative path, the Compiler initially searches relative to the project directory. If the Compiler cannot find the file, the Compiler next searches relative to all user libraries. Finally, the Compiler searches relative to the current file's directory location.
Intel^® Quartus^® Prime Pro Edition synthesis searches for all modules or entities earlier in the synthesis process than other Quartus software tools. This earlier search produces earlier syntax errors for undefined entities than other Quartus software tools.

1.8.1.1. Verilog HDL Input Settings (Settings Dialog Box)

Click Assignments > Settings > Verilog HDL Input to specify options for the synthesis of Verilog HDL input files.

Figure 54. Verilog HDL Input Settings Dialog Box

Table 14. Verilog HDL Input Settings
Setting	Description
Verilog Version	Directs synthesis to process Verilog HDL input design files using the specified standard. You can select any of the supported language standards to match your Verilog HDL files or SystemVerilog design files.
Library Mapping File	Allows you to optionally specify a provided Library Mapping File (.lmf) for use in synthesizing Verilog HDL files that contain non-Intel FPGA functions mapped to IP cores. You can specify the full path name of the LMF in the File name box.
Verilog HDL Macro	Verilog HDL macros are pre-compiler directives which can be added to Verilog HDL files to define constants, flags, or other features by Name and Setting. Macros that you add appear in the Existing Verilog HDL macro settings list.

1.8.1.2. Design Libraries

By default, the Compiler processes all design files into one or more libraries.

When compiling a design instance, the Compiler initially searches for the entity in the library associated with the instance (which is the work library if you do not specify any library).
If the Compiler cannot locate the entity definition, the Compiler searches for a unique entity definition in all design libraries.
If the Compiler finds more than one entity with the same name, the Compiler generates an error. If your design uses multiple entities with the same name, you must compile the entities into separate libraries.

1.8.1.3. Verilog HDL Configuration

Verilog HDL configuration is a set of rules that specify the source code for particular instances. Verilog HDL configuration allows you to perform the following tasks:

Specify a library search order for resolving cell instances (as does a library mapping file).
Specify overrides to the logical library search order for specified instances.
Specify overrides to the logical library search order for all instances of specified cells.

1.8.1.3.1. Hierarchical Design Configurations

A design can have more than one configuration. For example, you can define a configuration that specifies the source code you use in particular instances in a sub-hierarchy, and then define a configuration for a higher level of the design.

For example, suppose a subhierarchy of a design is an eight-bit adder, and the RTL Verilog code describes the adder in a logical library named rtllib. The gate-level code describes the adder in the gatelib logical library. If you want to use the gate-level code for the 0 (zero) bit of the adder and the RTL level code for the other seven bits, the configuration might appear as follows:

Gate-level code for the 0 (zero) bit of the adder

config cfg1;
design aLib.eight_adder;
default liblist rtllib;
instance adder.fulladd0 liblist gatelib;
endconfig

If you are instantiating this eight-bit adder eight times to create a 64-bit adder, use configuration cfg1 for the first instance of the eight-bit adder, but not in any other instance. A configuration that performs this function is shown below:

Use configuration `cfg1` for first instance of eight-bit adder

config cfg2;
design bLib.64_adder;
default liblist bLib;
instance top.64add0 use work.cfg1:config;
endconfig

Note: The name of the unbound module may be different from the name of the cell that is bounded to the instance.

1.8.1.4. Initial Constructs and Memory System Tasks

The Intel^® Quartus^® Prime software infers power-up conditions from the Verilog HDL initial constructs. The Intel^® Quartus^® Prime software also creates power-up settings for variables, including RAM blocks. If the Intel^® Quartus^® Prime 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. Synthesis of initial constructs enables the power-up state of the synthesized design to match the power-up state of the original HDL code in simulation.

Note: Initial blocks do not infer power-up conditions in some third-party EDA synthesis tools. If you convert between synthesis tools, you must set your power-up conditions correctly.

Intel^® Quartus^® Prime synthesis supports the $readmemb and $readmemh system tasks to initialize memories.

Verilog HDL Code: 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, and then specify the memory word such as 110101 or abcde on the next line.

The following example shows a portion of a Memory Initialization File (.mif) for the RAM.

Text File Format: Initializing RAM with the readmemb Command

1.8.1.5. Verilog HDL Macros

The Intel^® Quartus^® Prime 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 Intel^® Quartus^® Prime software or on the command line.

To set Verilog HDL macros at the command line for the Intel^® Quartus^® Prime Pro Edition synthesis (quartus_syn) executable, use the following format:

quartus_syn <PROJECT_NAME> --set=VERILOG_MACRO=a=2

This command adds the following new line to the project .qsf file:

set_global_assignment -name VERILOG_MACRO "a=2"

To avoid adding this line to the project .qsf, add this option to the quartus_syn command:

--write_settings_files=off

1.8.2. VHDL Synthesis Support

Intel^® Quartus^® Prime synthesis supports the following VHDL language standards.

VHDL 1987 (IEEE Standard 1076-1987)
VHDL 1993 (IEEE Standard 1076-1993)
VHDL 2008 (IEEE Standard 1076-2008)

The Intel^® Quartus^® Prime Compiler uses the VHDL 1993 standard by default for files that have the extension .vhdl or .vhd.

Note: The VHDL code samples follow the VHDL 1993 standard.

1.8.2.1. VHDL Input Settings (Settings Dialog Box)

Click Assignments > Settings > VHDL Input to specify options for the synthesis of VHDL input files.

Table 15. VHDL Input Settings
Setting	Description
VHDL Version	Specifies the VHDL standard for use during synthesis of VHDL input design files. Select the language standards that corresponds with the VHDL files.
Library Mapping File	Specifies a Library Mapping File (.lmf) for use in synthesizing VHDL files that contain IP cores. Specify the full path name of the LMF in the File name box.

Figure 55. VHDL Input Settings Dialog Box

1.8.2.2. VHDL Standard Libraries and Packages

The Intel^® Quartus^® Prime software includes the standard IEEE libraries and several vendor-specific VHDL libraries. 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 Intel^® Quartus^® Prime software also supports the following vendor-specific packages and libraries:

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.
Primitive packages altera_primitives_components (for primitives such as GLOBAL and DFFE) and maxplus2 in the ALTERA library.
IP core packages altera_mf_components in the ALTERA_MF library for specific IP cores including LCELL. In addition, lpm_components in the LPM library for library of parameterized modules (LPM) functions.

Note: Import component declarations for primitives such as GLOBAL and DFFE from the altera_primitives_components package and not the altera_mf_components package.

1.8.2.3. VHDL wait Constructs

The Intel^® Quartus^® Prime software supports one VHDL wait until statement per process block. However, the Intel^® Quartus^® Prime software does not support other VHDL wait constructs, such as wait for and wait on statements, or processes with multiple wait statements.

VHDL `wait until` construct example

architecture dff_arch of ls_dff is
begin
output: process begin
wait until (CLK'event and CLK='1');
Q <= D;
Qbar <= not D;
end process output;
end dff_arch;

1.9. Compiler Optimization Techniques

You can apply various optimization techniques via settings and entity assignments to achieve your design requirements during compilation. For example, you can specify options to preserve specific registers through synthesis processing, apply fractal synthesis, enable register retiming, and various other targeted Compiler optimizations.

1.9.1. Optimization Modes

The following options direct the focus of Compiler optimization efforts during synthesis. Specify a Balanced strategy, or optimize for Performance, Area, Routability, Power, or Compile Time. The Compiler targets the optimization goal you specify. The settings affect synthesis and fitting.

Table 16. Optimization Modes (Compiler Settings Page)
Optimization Mode	Description
Balanced (normal flow)	The Compiler optimizes synthesis for balanced implementation that respects timing constraints.
High Performance Effort	The Compiler increases the timing optimization effort during placement and routing, and enables timing-related Physical Synthesis optimizations (per register optimization settings). Each additional optimization can increase compilation time.
High Performance with Maximum Placement Effort	Enables the same Compiler optimizations as High Performance Effort, with additional placement optimization effort.
Superior Performance	Enables the same Compiler optimizations as High Performance Effort, and adds more optimizations during Analysis & Synthesis to maximize design performance with a potential increase to logic area. If design utilization is already very high, this option may lead to difficulty in fitting, which can also negatively affect overall optimization quality.
Superior Performance with Maximum Placement Effort	Enables the same Compiler optimizations as Superior Performance, with additional placement optimization effort.
Aggressive Area	The Compiler makes aggressive effort to reduce the device area required to implement the design at the potential expense of design performance.
High Placement Routability Effort	The Compiler makes high effort to route the design at the potential expense of design area, performance, and compilation time. The Compiler spends additional time reducing routing utilization, which can improve routability and also saves dynamic power.
High Packing Routability Effort	The Compiler makes high effort to route the design at the potential expense of design area, performance, and compilation time. The Compiler spends additional time packing registers, which can improve routability and also saves dynamic power.
Optimize Netlist for Routability	The Compiler implements netlist modifications to increase routability at the possible expense of performance.
High Power Effort	The Compiler makes high effort to optimize synthesis for low power. High Power Effort increases synthesis run time.
Aggressive Power	Makes aggressive effort to optimize synthesis for low power. The Compiler further reduces the routing usage of signals with the highest specified or estimated toggle rates, saving additional dynamic power but potentially affecting performance.
Aggressive Compile Time	Reduces the compile time required to implement the design with reduced effort and fewer performance optimizations. This option also disables some detailed reporting functions. Note: Turning on Aggressive Compile Time enables Intel^® Quartus^® Prime Settings File (.qsf) settings which cannot be overridden by other .qsf settings.

Note: If you enable extended optimization modes for Design Space Explorer II by use of .qsf assignments, and then subsequently open the Compiler Settings tab for that project revision, the Compiler Settings tab indicates that the extended optimization mode reverts to one of the Compiler Settings tab Optimization Modes.

1.9.2. Allow Register Retiming

The Allow Register Retiming option on the Register Optimization tab controls whether or not to globally disable retiming. When turned on, the Compiler automatically performs register retiming optimizations, moving registers through combinational logic. When turned off, the Compiler prevents any retiming optimizations on a global scale. Optionally, assign Allow Register Retiming to any design entity or instance for specific portions of the design. Click Assignments > Assignment Editor to specify entity- and instance-level assignments, or use the following syntax to make the assignment in the .qsf directly.

Disable register retiming for entity abc

set_global_assignment –name ALLOW_REGISTER_RETIMING ON

set_instance_assignment –name ALLOW_REGISTER_RETIMING OFF –to “abc|”

set_instance_assignment –name ALLOW_REGISTER_RETIMING ON –to “abc|def|”

Disable register retiming for the whole design, except for registers in entity abc

set_global_assignment –name ALLOW_REGISTER_RETIMING OFF

set_instance_assignment –name ALLOW_REGISTER_RETIMING ON –to “abc|”

set_instance_assignment –name ALLOW_REGISTER_RETIMING OFF –to “abc|def|”

1.9.3. Automatic Gated Clock Conversion

Clock gating saves power in ASIC designs by adding more logic to a circuit to prune the clock tree. Pruning the clock tree disables portions of the circuitry so that the flip-flops are not required to switch states. When using an Intel^® Quartus^® Prime FPGA to prototype ASIC designs, you must convert clock gates to clock enables in your design.

Gated Clock Conversion Example
ASIC Gated Clock Example	FPGA Clock Enable Example
module infer_enable (clk, reset, d, en, q); input d, en, clk, reset; output q; wire gated_clk; reg q; assign gated_clk = clk & en; always@(posedge gated_clk or reset) begin if (!reset) q <= 1’b0; else q <= d ; end end endmodule	module infer_enable (clk, reset, d, en, q); input d, en, clk, reset; output q; reg q; always@(posedge clk or reset) begin if (!reset) q <= 1’b0; else if (en) q <= d; else q <= q ; end end endmodule

Gated Clock Conversion Example

ASIC Gated Clock Example

FPGA Clock Enable Example

module infer_enable (clk, reset, d, en, q);

input d, en, clk, reset;
output q;

wire gated_clk;
reg q;

assign gated_clk = clk & en;
always@(posedge gated_clk or reset)
 begin
               if (!reset) 
                      q <= 1’b0;
              else 
                      q <= d ;
              end 
end 

endmodule

module infer_enable (clk, reset, d, en, q);

input d, en, clk, reset;
output q;

reg q;

always@(posedge clk or reset)
 begin
               if (!reset) 
                     q <= 1’b0;
              else if (en)
                     q <= d;
              else 
                      q <= q ;
              end 
end 

endmodule

Rather than manually converting gated clocks in your RTL, you can specify the Auto Gated Clock Conversion setting to automatically convert gated base clocks in the design to clock enables. You can apply this setting globally to all gated base clocks in the design, or to one or more specific clock signals.

Table 17. Gated Clock Conversion Settings
Setting Scope	Description
Global	Enable the Auto Gated Clock Conversion option at Assignments > Settings > Compiler Settings > Advanced Settings (Synthesis). Alternatively, add the global assignment to the project .qsf: set_global_assignment –name SYNTH_GATED_CLOCK_CONVERSION on
Instance-specific	Specify the Auto Gated Clock Conversion for one or more instances in the Assignment Editor (Assignments > Assignment Editor). Alternatively, add the instance assignment to the project .qsf: set_instance_assignment –name SYNTH_GATED_CLOCK_CONVERSION on –to clk_in

Following design synthesis, view the results of gated clock conversion in the Gated Clock Conversion Details report. The report lists all converted and unconverted gated clocks with their base clocks. For unconverted gated clocks, the report specifies the reason the clock is not converted.

Note: Automatic gated clock conversion supports explicit RAMs (such as WYSIWYG RAMs and Intel FPGA memory IP), but does not support inferred RAMs.

Figure 56. Gated Clock Conversion Details Report

1.9.4. Enable Intermediate Fitter Snapshots

To save compilation time, the Compiler does not save the planned, placed, routed, or retimed snapshots by default during full compilation.

However, you can turn on Enable Intermediate Fitter Snapshots (Assignments > Settings > Compiler Settings) to generate and preserve snapshots for the Plan, Place, Route, and Retime stages any time you run full compilation. You can also run any intermediate Fitter stage independently to generate the snapshot for that stage.

Note: You must enable Enable Intermediate Fitter Snapshots to subsequently use the Rapid Recompile feature.

1.9.5. Fast Preserve Option

Enabling the Fast Preserve option on the Incremental Compile tab specifies that the Compiler can simplify a preserved partition to only interface logic

Interface logic is logic at the partition boundary that interfaces with the rest of the design.

1.9.6. Fractal Synthesis Optimization

Fractal synthesis optimizations can be useful for deep-learning accelerators and other high-throughput, arithmetic-intensive designs that exceed all available DSP resources. For such designs, fractal synthesis optimization can achieve 20-45% area reduction.

Fractal synthesis is a set of synthesis optimizations that use FPGA resources in an optimal way for arithmetic-intensive designs. These synthesis optimizations consist of multiplier regularization and retiming, as well as continuous arithmetic packing. The optimizations target designs with large numbers of low-precision arithmetic operations (such as additions and multiplications). You can enable fractal synthesis globally or for specific multipliers, as Enabling or Disabling Fractal Synthesis describes.

Project-Wide Fractal Synthesis Considerations

Note: Fractal synthesis optimization is most suitable for designs with deep-learning accelerators or other high-throughput, arithmetic-intensive functions that exceed all DSP resources. Enabling fractal synthesis project-wide can cause unnecessary bloat on modules that are not suitable for fractal optimizations. Consider the following factors before enabling fractal synthesis optimization project wide:

Intel FPGA devices contain thousands of hard DSP blocks that are perfectly suited for arithmetic operations. If the total amount of arithmetic functions in your design is small, then there is no need to enable Fractal Synthesis. In such cases, all the arithmetic functions map directly into DSPs by default. Enable global Fractal Synthesis only if there are not enough DSP blocks available to implement all arithmetic components. Enable Fractal Synthesis only for modules that you do not want the Compiler to map into DSPs.
In the current version of the Intel^® Quartus^® Prime Pro Edition software, fractal synthesis optimizations target low-precision multiplication. Implement high-precision multipliers (where width of every operand exceeds 11 bits) using DSP blocks.
If you enable project-wide Fractal Synthesis, the following information message number 20193 may generate during compilation:
```
Applied dense packing to "<entity>". Area: 2 LABs. Logic density: 0.775.
```
This information indicates the effort the Compiler is packing computational logic into a smaller number of LABs. If the design is already highly utilized, the Compiler can skip this stage.
- Verify that the Area the message reports does not exceed 100 LABs. If the Area exceeds 100 LABs, divide fractal synthesis blocks to sub-blocks, and then assign the fractal synthesis optimizations to the sub-blocks independently.
- Verify that the Logic density the message reports is greater than 0.75. If the logic density is less than 0.75, disable Fractal Synthesis for this entity because standard synthesis typically achieves better density.

Table 18. Fractal Synthesis Area Improvement
		Area (LABs)
Device	Dot-product	Fractal Synthesis ON	Fractal Synthesis OFF
Intel^® Arria^® 10 and Intel^® Cyclone^® 10 GX	Sum of 16 4x4sm	12	19
	Sum of 16 5x5sm	19	32
	Sum of 16 6x6sm	25	36
	Sum of 16 7x7sm	34	44
	Sum of 16 8x8sm	45	60
Intel^® Stratix^® 10 and Intel^® Agilex™ Devices	Sum of 16 4x4sm	15	22
	Sum of 16 5x5sm	21	39
	Sum of 16 6x6sm	29	47
	Sum of 16 7x7sm	39	55
	Sum of 16 8x8sm	55	71

Multiplier Regularization and Retiming

Multiplier regularization and retiming performs inference of highly optimized soft multiplier implementations. The Compiler may apply backward retiming to two or more pipeline stages if required. When you enable fractal synthesis, the Compiler applies multiplier regularization and retiming to signed and unsigned multipliers.

Figure 57. Multiplier Retiming

Note:

Multiplier regularization uses only logic resources, and does not use DSP blocks.
Multiplier regularization and retiming is applied to both signed and unsigned multipliers in modules where the FRACTAL_SYNTHESIS QSF assignment is set.

Multiplier Regularization Example

The following simple, unsigned dot-product design example contains multiplication operators with 5-bit operands. These short multipliers are perfect candidates for multiplier regularization.

(* altera_attribute = "-name FRACTAL_SYNTHESIS ON" *)
module dot_product(
   input clk,
   input [4:0] a, b, c, d, e, f, g, h,
   output reg [11:0] out
);
reg [9:0] ab, cd, ef, gh;
reg [10:0] ab_cd, ef_gh;

always @(posedge clk)
begin
	ab <= a * b;
	cd <= c * d;
	ef <= e * f;
	gh <= g * h;
	ab_cd <= ab + cd;
	ef_gh <= ef + gh;
	out <= ab_cd + ef_gh;
end
endmodule

module top(
   input clk,
   input [4:0] a1, b1, c1, d1, e1, f1, g1, h1,
   input [4:0] a2, b2, c2, d2, e2, f2, g2, h2,
   output [11:0] out1, out2
);
dot_product core1(.clk(clk), .a(a1), .b(b1), .c(c1), .d(d1), 
    .e(e1), .f(f1), .g(g1), .h(h1), .out(out1));
dot_product core2(.clk(clk), .a(a2), .b(b2), .c(c2), .d(d2), 
	.e(e2), .f(f2), .g(g2), .h(h2), .out(out2));
endmodule

Intel^® Quartus^® Prime synthesis prints the following messages to the console:

Figure 58. Console Messages

In the Chip Planner, you can observe this design having two unsigned dot-product cores. These cores are independently optimized and placed. The LAB resources are nearly 100% optimized, as the following image shows:

Figure 59. Design Placement

Signed dot-products are common for deep-learning applications. The following demonstrates an example of a signed dot-product:

(* altera_attribute = "-name FRACTAL_SYNTHESIS ON" *)
module dot_product(
   input signed clk,
   input signed [4:0] a, b, c, d, e, f, g, h,
   output reg signed [11:0] out
);
reg signed [9:0] ab, cd, ef, gh;
reg signed [10:0] ab_cd, ef_gh;

always @(posedge clk)
begin
	ab <= a * b;
	cd <= c * d;
	ef <= e * f;
	gh <= g * h;
	ab_cd <= ab + cd;
	ef_gh <= ef + gh;
	out <= ab_cd + ef_gh;
end
endmodule

module top(
   input clk,
   input signed [4:0] a1, b1, c1, d1, e1, f1, g1, h1,
   input signed [4:0] a2, b2, c2, d2, e2, f2, g2, h2,
   output signed [11:0] out1, out2
);
dot_product core1(.clk(clk), .a(a1), .b(b1), .c(c1), .d(d1), 
    .e(e1), .f(f1), .g(g1), .h(h1), .out(out1));
dot_product core2(.clk(clk), .a(a2), .b(b2), .c(c2), .d(d2), 
	.e(e2), .f(f2), .g(g2), .h(h2), .out(out2));
endmodule

Intel^® Quartus^® Prime synthesis displays the following messages in the console:

Figure 60. Console Messages

In the Chip Planner, you can observe this design having two signed dot-product cores independently optimized and placed:

Figure 61. Design Placement

Continuous Arithmetic Packing

Continuous arithmetic packing re-synthesizes arithmetic gates into logic blocks optimally sized to fit into Intel^® FPGA LABs. This optimization allows up to 100% utilization of LAB resources for the arithmetic blocks.

When you enable fractal synthesis, the Compiler applies this optimization to all carry chains and two-input logic gates. This optimization can pack adder trees, multipliers, and any other arithmetic-related logic.

Figure 62. Continuous Arithmetic Packing

Note that continuous arithmetic packing works independently of multiplier regularization. So, if you are using a multiplier that is not regularized (such as writing your own multiplier) then continuous arithmetic packing can still operate.

1.9.6.1. Enabling or Disabling Fractal Synthesis

For Intel^® Stratix^® 10 and Intel^® Agilex™ devices, fractal synthesis optimization runs automatically for small multipliers (any A*B statement in Verilog HDL or VHDL where bit-width of the operands is 7 or less). You can also disable automatic fractal synthesis for small multipliers for these devices using either of the following methods:

In RTL, set the DSP multstyle, as "Multstyle Verilog HDL Synthesis Attribute" describes. For example:
```
(* multstyle = "dsp" *) module foo(...);
module foo(..) /* synthesis multstyle = "dsp" */;
```

In the .qsf file, add as an assignment as follows:

set_instance_assignment -name DSP_BLOCK_BALANCING_IMPLEMENTATION \
     DSP_BLOCKS -to r

In addition, for Intel^® Stratix^® 10, Intel^® Agilex™ , Intel^® Arria^® 10, and Intel^® Cyclone^® 10 GX devices, you can enable fractal synthesis globally or for specific multipliers with the Fractal Synthesis GUI option or the corresponding FRACTAL_SYNTHESIS .qsf assignment:

In RTL, use altera_attribute as follows:

(* altera_attribute = "-name FRACTAL_SYNTHESIS ON" *)

In the .qsf file, add as an assignment as follows:

set_global_assignment -name FRACTAL_SYNTHESIS ON -entity <module name>

In the user interface, follow these steps:

Click Assignments > Assignment Editor.
Select Fractal Synthesis for Assignment Name, On for the Value, the arithmetic-intensive entity name for Entity, and an instance name in the To column. You can enter a wildcard (*) for To to assign all instances of the entity.
Figure 63. Fractal Synthesis Assignment in Assignment Editor

1.10. Synthesis Settings Reference

This section provides a reference to all synthesis settings. Use these settings to customize synthesis processing for your design goals.

1.10.1. Advanced Synthesis Settings

The following section is a quick reference of all Advanced Synthesis Settings. Click Assignments > Settings > Compiler Settings > Advanced Settings (Synthesis) to modify these settings.

Table 19. Advanced Synthesis Settings (1 of 13)
Option	Description
Allow Any RAM Size for Recognition	Allows the Compiler to infer RAMs of any size, even if the RAMs do not meet the current minimum requirements.
Allow Any ROM Size for Recognition	Allows the Compiler to infer ROMs of any size even if the ROMs do not meet the design's current minimum size requirements.
Allow Any Shift Register Size for Recognition	Allows the Compiler to infer shift registers of any size even if they do not meet the design's current minimum size requirements.
Allow Register Duplication	Controls whether the Compiler duplicates registers to improve design performance. When enabled, the Compiler performs optimization that creates a second copy of a register and move a portion of its fan-out to this new node. This technique improves routability and reduces the total routing wire required to route a net with many fan-outs. If you disable this option, retiming of registers is also disabled. Note: Only available for Intel^® Arria^® 10 and Intel^® Cyclone^® 10 GX devices.
Allow Register Merging	Controls whether the Compiler removes (merges) identical registers. When enabled, in cases where two registers generate the same logic, the Compiler may delete one register and fan-out the remaining register to the deleted register's destinations. This option is useful if you want to prevent the Compiler from removing duplicate registers that you have used deliberately. When disabled, retiming optimizations are also disabled. Note: Only available for Intel^® Arria^® 10 and Intel^® Cyclone^® 10 GX devices.
Allow Shift Register Merging Across Hierarchies	Allows the Compiler to take shift registers from different hierarchies of the design and put the registers in the same RAM.
Allow Synchronous Control Signals	Allows the Compiler to utilize synchronous clear and synchronous load signals in normal mode logic cells. Turning on this option helps to reduce the total number of logic cells used in the design, but can negatively impact the fitting. This negative impact occurs because all the logic cells in a LAB share synchronous control signals.

Table 20. Advanced Synthesis Settings (2 of 13)
Option	Description
Analysis & Synthesis Message Level	Specifies the type of Analysis & Synthesis messages the Compiler display. Low displays only the most important Analysis & Synthesis messages. Medium displays most messages, but hides the detailed messages. High displays all messages.
Auto Clock Enable Replacement	Allows the Compiler to locate logic that feeds a register and move the logic to the register's clock enable input port.
Auto DSP Block Replacement	Allows the Compiler to find a multiply-accumulate function or a multiply-add function that can be replaced with a DSP block.
Auto Gated Clock Conversion	Automatically converts gated clocks to use clock enable pins. Clock gating logic can contain AND, OR, MUX, and NOT gates. Turning on this option may increase memory use and overall run time. You must use the Timing Analyzer for timing analysis, and you must define all base clocks in Synopsys Design Constraints (.sdc) format.

Table 21. Advanced Synthesis Settings (3 of 13)
Option	Description
Auto Open-Drain Pins	Allows the Compiler to automatically convert a tri-state buffer with a strong low data input into the equivalent open-drain buffer.
Auto RAM Replacement	Allows the Compiler to identify sets of registers and logic that it can replace with the altsyncram or the lpm_ram_dp IP core. Turning on this option may change the functionality of the design.
Auto ROM Replacement	Allows the Compiler to identify logic that it can replace with the altsyncram or the lpm_rom IP core. Turning on this option may change the power-up state of the design.
Auto Resource Sharing	Allows the Compiler to share hardware resources among many similar, but mutually exclusive, operations in your HDL source code. If you enable this option, the Compiler merges compatible addition, subtraction, and multiplication operations. Merging operations may reduce the area your design requires. Because resource sharing introduces extra muxing and control logic on each shared resource, it may negatively impact the final f_MAX of your design.
Auto Shift Register Placement	Allows the Compiler to find a group of shift registers of the same length that are replaceable with the altshift_taps IP core. The shift registers must all use the same clock and clock enable signals. The registers must not have any other secondary signals. The registers must have equally spaced taps that are at least three registers apart.
Automatic Parallel Synthesis	Option to enable/disable automatic parallel synthesis. Use this option to speed up synthesis compile time by using multiple processors when available.

Table 22. Advanced Synthesis Settings (4 of 13)
Option	Description
Block Design Naming	Specifies the naming scheme for the block design. The Compiler ignores the option if you assign the option to anything other than a design entity.
Clock MUX Protection	Causes the multiplexers in the clock network to decompose to 2-to-1 multiplexer trees. The Compiler protects these trees from merging with, or transferring to, other logic. This option helps the Timing Analyzer to analyze clock behavior.
DSP Block Balancing	Allows you to control the conversion of certain DSP block slices during DSP block balancing.

Table 23. Advanced Synthesis Settings (5 of 13)
Option	Description
Disable DSP Negate Inferencing	Allows you to specify whether to use the negate port on an inferred DSP block.
Disable Register Merging Across Hierarchies	Specifies whether the Compiler allows merging of registers that are in different hierarchies if their inputs are the same.
Enable Formal Verification Support	Enables the Compiler to write scripts for use with the OneSpin* formal verification tool.
Enable State Machines Inference	Allows the Compiler to infer state machines from VHDL or Verilog HDL design files. The Compiler optimizes state machines to reduce area and improve performance. If set to Off, the Compiler extracts and optimizes state machines in VHDL or Verilog HDL design files as regular logic.
Force Use of Synchronous Clear Signals	Forces the Compiler to utilize synchronous clear signals in normal mode logic cells. Enabling this option helps to reduce the total number of logic cells in the design, but can negatively impact the fitting. All the logic cells in a LAB share synchronous control signals.
Fractal Synthesis	Turning this option On directs the Compiler to apply dense packing to arithmetic blocks, minimizing the area of the design for arithmetic-intensive designs.
HDL Message Level	Specifies the type of HDL messages you want to view, including messages that display processing errors in the HDL source code. Level1 displays only the most important HDL messages. Level2 displays most HDL messages, including warning and information based messages. Level3 displays all HDL messages, including warning and information based messages and alerts about potential design problems or lint errors.

Table 24. Advanced Synthesis Settings (6 of 13)
Option	Description
Ignore GLOBAL Buffers	Ignores `GLOBAL` buffers in the design. The Compiler ignores this option if you apply the option to anything other than an individual `GLOBAL` buffer, or a design entity containing `GLOBAL` buffers.
Ignore LCELL Buffers	Ignores `LCELL` buffers in the design. The Compiler ignores this option if you apply the option to anything other than an individual `LCELL` buffer, or a design entity containing `LCELL` buffers.
Ignore Maximum Fan-Out Assignments	Directs the Compiler to ignore the Maximum Fan-Out Assignments on a node, an entity, or the whole design.
Ignore SOFT Buffers	Ignores `SOFT` buffers in the design. The Compiler ignores this option if you apply the option to anything other than an individual `SOFT` buffer or a design entity containing SOFT buffers.

Table 25. Advanced Synthesis Settings (7 of 13)
Option	Description
Ignore translate_off and synthesis_off Directives	Ignores all `translate_off/synthesis_off` synthesis directives in Verilog HDL and VHDL design files. Use this option to disable these synthesis directives and include previously ignored code during elaboration.
Infer RAMs from Raw Logic	Infers RAM from registers and multiplexers. The Compiler initially converts some HDL patterns differing from RAM templates into logic. However, these structures function as RAM. As a result, when you enable this option, the Compiler may substitute the altsyncram IP core instance for them at a later stage. When you enable this assignment, the Compiler may use more device RAM resources and fewer LABs.
Iteration Limit for Constant Verilog Loops	Defines the iteration limit for Verilog loops with loop conditions that evaluate to compile-time constants on each loop iteration. This limit exists primarily to identify potential infinite loops before they exhaust memory or trap the software in an actual infinite loop.
Iteration Limit for non-Constant Verilog Loops	Defines the iteration limit for Verilog HDL loops with loop conditions that do not evaluate to compile-time constants on each loop iteration. This limit exists primarily to identify potential infinite loops before they exhaust memory or trap the software in an actual infinite loop.

Table 26. Advanced Synthesis Settings (8 of 13)
Option	Description
Maximum DSP Block Usage	Specifies the maximum number of DSP blocks that the DSP block balancer assumes exist in the current device for each partition. This option overrides the usual method of using the maximum number of DSP blocks the current device supports.
Maximum Number of LABs	Specifies the maximum number of LABs that Analysis & Synthesis should try to utilize for a device. This option overrides the usual method of using the maximum number of LABs the current device supports, when the value is non-negative and is less than the maximum number of LABs available on the current device.
Maximum Number of M4K/M9K/M20K/M10K Memory Blocks	Specifies the maximum number of M4K, M9K, M20K, or M10K memory blocks that the Compiler may use for a device. This option overrides the usual method of using the maximum number of M4K, M9K, M20K, or M10K memory blocks the current device supports, when the value is non-negative and is less than the maximum number of M4K, M9K, M20K, or M10K memory blocks available on the current device.

Table 27. Advanced Synthesis Settings (9 of 13)
Option	Description
Maximum Number of Registers Created from Uninferred RAMs	Specifies the maximum number of registers that Analysis & Synthesis uses for conversion of uninferred RAMs. Use this option as a project-wide option or on a specific partition by setting the assignment on the instance name of the partition root. The assignment on a partition overrides the global assignment (if any) for that particular partition. This option prevents synthesis from causing long compilations and running out of memory when many registers are used for uninferred RAMs. Instead of continuing the compilation, the Intel^® Quartus^® Prime software issues an error and exits.
NOT Gate Push-Back	Allows the Compiler to push an inversion (that is, a NOT gate) back through a register and implement it on that register's data input if it is necessary to implement the design. When this option is on, a register may power-up to an active-high state, and may need explicit clear during initial operation of the device. The Compiler ignores this option if you apply it to anything other than an individual register or a design entity containing registers. When you apply this option to an output pin that is directly fed by a register, the assignment automatically transfers to that register.
Number of Inverted Registers Reported in Synthesis Report	Specifies the maximum number of inverted registers that the Synthesis report displays.
Number of Protected Registers Reported in Synthesis Report	Specifies the maximum number of protected registers that the Synthesis Report displays.
Number of Removed Registers Reported in Synthesis Migration Checks	Specifies the maximum number of rows that the Synthesis Migration Check report displays.
Number of Swept Nodes Reported in Synthesis Report	Specifies the maximum number of swept nodes that the Synthesis Report displays. A swept node is any node which was eliminated from your design because the Compiler found the node to be unnecessary.
Number of Rows Reported in Synthesis Report	Specifies the maximum number of rows that the Synthesis report displays. Note: Only available for Intel^® Arria^® 10 and Intel^® Cyclone^® 10 GX devices.
Optimization Technique	Specifies an overall optimization goal for Analysis & Synthesis. Specify a Balanced strategy, or optimize for Performance, Area, Routability, Power, or Compile Time. The Compiler targets the optimization goal you specify.

Table 28. Advanced Synthesis Settings (10 of 13)
Option	Description
Perform WYSIWYG Primitive Resynthesis	Specifies whether to perform WYSIWYG primitive resynthesis during synthesis. This option uses the setting specified in the Optimization Technique logic option.
Power-Up Don't Care	Causes registers that do not have a Power-Up Level logic option setting to power-up with a do not care logic level (`X`). When the Power-Up Don't Care option is on, the Compiler determines when it is beneficial to change the power-up level of a register to minimize the area of the design. The Compiler maintains a power-up state of zero, unless there is an immediate area advantage.
Power Optimization During Synthesis	Controls the power-driven compilation setting of Analysis & Synthesis. This option determines how aggressively Analysis & Synthesis optimizes the design for power. When this option is Off, the Compiler does not perform any power optimizations. Normal compilation performs power optimizations provided that they are not expected to reduce design performance. Extra effort performs additional power optimizations which may reduce design performance.

Table 29. Advanced Synthesis Settings (11 of 13)
Option	Description
Remove Duplicate Registers	Removes a register if it is identical to another register. If two registers generate the same logic, the Compiler deletes the duplicate. The first instance fans-out to the duplicates destinations. Also, if the deleted register contains different logic option assignments, the Compiler ignores the options. This option is useful if you want to prevent the Compiler from removing intentionally duplicate registers. The Compiler ignores this option if you apply it to anything other than an individual register or a design entity containing registers.
Remove Redundant Logic Cells	Removes redundant LCELL primitives or WYSIWYG primitives. Turning this option on optimizes a circuit for area and speed. The Compiler ignores this option if you apply it to anything other than a design entity.
Report Parameter Settings	Specifies whether the Synthesis report includes the reports in the Parameter Settings by Entity Instance folder.
Report PR Initial Values as Errors	Allows you to flag explicitly defined initial values found in PR partitions as Errors instead of Warnings.
Report Source Assignments	Specifies whether the Synthesis report includes reports in the Source Assignments folder.

Table 30. Advanced Synthesis Settings (12 of 13)
Option	Description
Resource Aware Inference for Block RAM	Specifies whether RAM, ROM, and shift-register inference should take the design and device resources into account.
Restructure Multiplexers	Reduces the number of logic elements synthesis requires to implement multiplexers in a design. This option is useful if your design contains buses of fragmented multiplexers. This option repacks multiplexers more efficiently for area, allowing the design to implement multiplexers with a reduced number of logic elements: On—minimizes your design area, but may negatively affect design clock speed (f_MAX). Off—disables multiplexer restructuring; it does not decrease logic element usage and does not affect design clock speed (f_MAX). Auto—allows the Intel^® Quartus^® Prime software to determine whether multiplexer restructuring should be enabled. The Auto setting decreases logic element usage, but may negatively affect design clock speed (f_MAX).
SDC Constraint Protection	Verifies.sdc constraints in register merging. This option helps to maintain the validity of .sdc constraints through compilation.
Safe State Machine	The Safe State Machine option implements state machines that can recover from an illegal state. The following settings are available: Auto—for Intel^® Stratix^® 10 or Intel^® Agilex™ designs, this default setting enables Safe State Machine whenever the Compiler determines this setting is advantageous in state machines of 6 or less states. The setting helps to allow for unexpected initial power-up conditions. For Intel^® Arria^® 10 and Intel^® Cyclone^® 10 GX, the Auto setting is the same as Never. On—directs the Compiler to always use Safe State Machine. Never—never uses Safe State Machine.
Shift Register Replacement – Allow Asynchronous Clear Signal	Allows the Compiler to find a group of shift registers of the same length that can be replaced with the altshift_taps IP core. The shift registers must all use the same `aclr` signals, must not have any other secondary signals, and must have equally spaced taps that are at least three registers apart. To use this option, you must turn on the Auto Shift Register Replacement logic option.
Size of the Latch Report	Allows you to specify the maximum number of latches that the Synthesis Report should display.
Size of the PR Initial Conditions Report	Allows you to specify the maximum number of registers that the PR Initial Conditions Report should display.

Table 31. Advanced Synthesis Settings (13 of 13)
Option	Description
State Machine Processing	Specifies the processing style the Compiler uses to process a state machine. You can use your own User-Encoded style, or select One-Hot, Minimal Bits, Gray, Johnson, Sequential, or Auto (Compiler-selected) encoding.
Strict RAM Replacement	When this option is On, the Compiler replace RAM only if the hardware matches the design exactly.
Synchronization Register Chain Length	Specifies the maximum number of registers in a row that the Compiler considers as a synchronization chain. Synchronization chains are sequences of registers with the same clock and no fan-out in between, such that the first register is fed by a pin, or by logic in another clock domain. The Compiler considers these registers for metastability analysis. The Compiler prevents optimizations of these registers, such as retiming. When gate-level retiming is enabled, the Compiler does not remove these registers. The default length is set to two.
Synthesis Effort	Controls the synthesis trade-off between compilation speed, performance, and area. The default is Auto. You can select Fast for faster compilation speed at the cost of performance and area.
Synthesis Migration Check for Stratix 10	Enables synthesis checks on Intel^® Arria^® 10 to Intel^® Stratix^® 10 design migration.
Timing-Driven Synthesis	For Intel^® Arria^® 10 and Intel^® Cyclone^® 10 GX designs, allows synthesis to use timing information to better optimize the design. The Timing-Driven Synthesis logic option impacts the following Optimization Technique options: Optimization Technique Speed—optimizes timing-critical portions of your design for performance at the cost of increasing area (logic and register utilization) Optimization Technique Balanced—also optimizes the timing-critical portions of your design for performance, but the option allows only limited area increase Optimization Technique Area—optimizes your design only for area

1.11. Fitter Settings Reference

Use Fitter settings to customize the place and route of your design. Click Assignments > Settings > Compiler Settings > Advanced Settings (Fitter) to access Fitter settings.

Table 32. Advanced Fitter Settings (1 of 8)
Option	Description
ALM Register Packing Effort	Guides aggressiveness of the Fitter in packing ALMs during register placement. Use this option to increase secondary register locations. Increasing ALM packing density may lower the number of ALMs needed to fit the design, but it may also reduce routing flexibility and timing performance. Low—the Fitter avoids ALM packing configurations that combine LUTs and registers which have no direct connectivity. Avoiding these configurations may improve timing performance but increases the number of ALMs to implement the design. Medium—the Fitter allows some configurations that combine unconnected LUTs and registers to be implemented in ALM locations. The Fitter makes more use of secondary register locations within the ALM. High—the Fitter enables all legal and desired ALM packing configurations. In dense designs, the Fitter automatically increases the ALM register packing effort as required to enable the design to fit.
Advanced Physical Synthesis	Enables the Physical Synthesis engine that includes combinational and sequential optimization during fitting to improve circuit performance.
Allow Delay Chains	Allows the Fitter to choose the optimal delay chain to meet t_SU and t_CO timing requirements for all I/O elements. Enabling this option may reduce the number of t_SU violations, while introducing a minimal number of t_H violations. Enabling this option does not override delay chain settings on individual nodes.
Allow DSP Retiming	Allow retiming through DSP blocks.
Allow Early Global Retiming in the Fitter	Allows the Compiler to run global retiming early in the Fitter.
Allow Hyper-Aware Register Chain Area Optimizations in the Fitter	Reduces ALM usage by automatically forcing some back-to-back registers into Hyper Registers. Turning on this area reduction technique may reduce performance and increase compile time.
Allow RAM Retiming	Allow retiming through RAM blocks.
Allow Register Duplication	Allows the Compiler to duplicate registers to improve design performance. When you enable this option, the Compiler copies registers and moves some fan-out to this new node. This optimization improves routability and can reduce the total routing wire in nets with many fan-outs. If you disable this option, this disables optimizations that retime registers. Note: Only available for Intel^® Arria^® 10 and Intel^® Cyclone^® 10 GX devices.
Allow Register Merging	Allows the Compiler to remove registers that are identical to other registers in the design. When you enable this option, in cases where two registers generate the same logic, the Compiler deletes one register, and the remaining registers fan-out to the deleted register's destinations. This option is useful if you want to prevent the Compiler from removing intentional use of duplicate registers. If you disable register merging, the Compiler disables optimizations that retime registers. Note: Only available for Intel^® Arria^® 10 and Intel^® Cyclone^® 10 GX devices.
Auto Delay Chains for High Fanout Input Pins	Allows the Fitter to choose how to optimize the delay chains for high fan-out input pins. You must enable Auto Delay Chains to enable this option. Enabling this option may reduce the number of t_SU violations, but the compile time increases significantly, as the Fitter tries to optimize the settings for all fan-outs.
Auto Fit Effort Desired Slack Margin	Specifies the default worst-case slack margin the Fitter maintains for. If the design is likely to have at least this much slack on every path, the Fitter reduces optimization effort to reduce compilation time. Note: Only available for Intel^® Arria^® 10 and Intel^® Cyclone^® 10 GX devices.

Table 33. Advanced Fitter Settings (2 of 8)
Option	Description
Auto Global Clock	Allows the Compiler to choose the global clock signal. The Compiler chooses the signal that feeds the most clock inputs to flip-flops. This signal is available throughout the device on the global routing paths. To prevent the Compiler from automatically selecting a particular signal as global clock, set the Global Signal option to Off on that signal.
Auto Global Register Control Signals	Allows the Compiler to choose global register control signals. The Compiler chooses signals that feed the most control signal inputs to flip-flops (excluding clock signals) as the global signals. These global signals are available throughout the device on the global routing paths. Depending on the target device family, these control signals can include asynchronous clear and load, synchronous clear and load, clock enable, and preset signals. If you want to prevent the Compiler from automatically selecting a particular signal as a global register control signal, set the Global Signal option to Off on that signal.
Auto Packed Registers	Allows the Compiler to combine a register and a combinational function, or to implement registers using I/O cells, RAM blocks, or DSP blocks instead of logic cells. This option controls how aggressively the Fitter combines registers with other function blocks to reduce the area of the design. Generally, the Auto or Sparse Auto settings are appropriate. The other settings limit the flexibility of the Fitter to combine registers with other function blocks and can result in no fits. Auto—the Fitter attempts to achieve the best performance with good area. If necessary, the Fitter combines additional logic to reduce the area of the design to within the current device. Sparse Auto—the Fitter attempts to achieve the highest performance, but may increase device usage without exceeding the device logic capacity. Off—the Fitter does not combine registers with other functions. The Off setting severely increases the area of the design and may cause a no fit. Sparse—the Fitter combines functions in a way which improves performance for many designs. Normal—the Fitter combines functions that are expected to maximize design performance and reduce area. Minimize Area—the Fitter aggressively combines unrelated functions to reduce the area required for placing the design, at the expense of performance. Minimize Area with Chains—the Fitter even more aggressively combines functions that are part of register cascade chains or can be converted to register cascade chains. If this option is set to any value but Off, registers combine with I/O cells to improve I/O timing. This remains true provided that the Optimize IOC Register Placement For Timing option is enabled.
Auto RAM to MLAB Conversion	Specifies whether the Fitter converts RAMs of Auto block type to use LAB locations. If this option is set to Off, only MLAB cells or RAM cells with a block type setting of MLAB use LAB locations to implement memory.
Auto Register Duplication	Allows the Fitter to automatically duplicate registers within a LAB that contains empty logic cells. This option does not alter the functionality of the design. The Compiler ignores the Auto Register Duplication option if you select OFF as the setting for the Logic Cell Insertion -- Logic Duplication logic option. Turning on this option allows the Logic Cell Insertion -- Logic Duplication logic option to improve a design's routability, but can make formal verification of a design more difficult. Note: Only available for Intel^® Arria^® 10 and Intel^® Cyclone^® 10 GX devices.

Table 34. Advanced Fitter Settings (3 of 8)
Option	Description
Enable Auto-Pipelining	Turns on the auto-pipelining and latency-insensitive false path feature. Use this setting in conjunction with the Maximum Additional Pipelining and optional Additional Pipelining Group assignments in the Assignment Editor to automatically add pipeline registers at the locations you specify. Note: Only available for Intel^® Stratix^® 10 and Intel^® Agilex™ devices.
Enable Bus-Hold Circuitry	Enables bus-hold circuitry during device operation. When this option is On, a pin retains its last logic level when it is not driven, and does not go to a high impedance logic level. Do not use this option at the same time as the Weak Pull-Up Resistor designs, enables location to the Critical Chain Viewer from the Fast option. The Compiler ignores this option if you apply it to anything other than a pin.
Enable Critical Chain Viewer	Enables critical chain visualization in the Fast Forward Timing Closure Recommendations report for Intel^® Stratix^® 10 and Intel^® Agilex™ devices.
Equivalent RAM and MLAB Paused Read Capabilities	Specifies whether RAMs implemented in MLAB cells must have equivalent paused read capabilities as RAMs implemented in block RAM. Pausing a read is the ability to keep around the last read value when reading is disabled. Allowing differences in paused read capabilities provides the Fitter more flexibility in implementing RAMs using MLAB cells. To allow the Fitter the most flexibility in deciding which RAMs are implemented using MLAB cells, set this option to Don't Care. The following options are available: Don't Care—the Fitter can convert RAMs to MLAB cells, even if they do not have equivalent paused read capabilities to a block RAM implementation. The Fitter generates an information message about RAMs with different paused read capabilities. Care—the Fitter does not convert RAMs to MLAB cells unless they have the equivalent paused read capabilities to a block RAM implementation.
Equivalent RAM and MLAB Power Up	Specifies whether RAMs implemented in MLAB cells must have equivalent power-up conditions as RAMs implemented in block RAM. Power-up conditions occur when the device powers-up or globally resets. Allowing non-equivalent power-up conditions provides the Fitter more flexibility in implementing RAMs using MLAB cells. To allow the Fitter the most flexibility in deciding which RAMs are implemented using MLAB cells, set this option to Auto or Don't Care. The following options are available: Auto—the Fitter may convert RAMs to MLAB cells, even if the MLAB cells lack equivalent power-up conditions to a block RAM implementation. The Fitter also outputs a warning message about RAMs with non-equivalent power up conditions. Don't Care—the same behavior as Auto applies, but the message is an information message. Care—the Fitter does not convert RAMs to MLAB cells unless they have equivalent power up conditions to a block RAM implementation.
Final Placement Optimizations	Specifies whether the Fitter performs final placement optimizations. Performing final placement optimizations may improve timing and routability, but may also require longer compilation time.
Fitter Aggressive Routability Optimizations	Specifies whether the Fitter aggressively optimizes for routability. Performing aggressive routability optimizations may decrease design speed, but may also reduce routing wire usage and routing time. The Automatically setting allows the Fitter to decide whether aggressive routability is beneficial.

Table 35. Advanced Fitter Settings (4 of 8)
Option	Description
Fitter Effort	Specifies the level of physical synthesis optimization during fitting: Auto—adjusts the Fitter optimization effort to minimize compilation time, while still achieving the design timing requirements. Use the Auto Fit Effort Desired Slack Margin option to apply sufficient optimization effort to achieve additional timing margin. Standard—uses maximum effort regardless of the design's requirements, leading to higher compilation time and more margin on easier designs. For difficult designs, Auto and Standard both use maximum effort. Note: Only available for Intel^® Arria^® 10 and Intel^® Cyclone^® 10 GX devices.
Fitter Initial Placement Seed	Specifies the seed for the current design. The value can be any non-negative integer value. By default, the Fitter uses a seed of 1. The Fitter uses the seed as the initial placement configuration when optimizing design placement to meet timing requirements f_MAX. Because each different seed value results in a somewhat different fit, you can try several different seeds to attempt to obtain superior fitting results. The seeds that lead to the best fits for a design may change if the design changes. Also, changing the seed may or may not result in a better fit. Therefore, specify a seed only if the Fitter is not meeting timing requirements by a small amount. Note: You can also use the Design Space Explorer II (DSEII) to sweep complex flow parameters, including the seed, in the Intel^® Quartus^® Prime software to optimize design performance.
Logic Cell Insertion	Allows the Fitter to automatically insert buffer logic cells between two nodes without altering the functionality of the design. The Compiler creates buffer logic cells from unused logic cells in the device. This option also allows the Fitter to duplicate a logic cell within a LAB when there are unused logic cells available in a LAB. Using this option can increase compilation time. The default setting of Auto allows these operations to run when the design requires them to fit the design. Note: Only available for Intel^® Arria^® 10 and Intel^® Cyclone^® 10 GX devices.
MLAB Add Timing Constraints for Mixed-Port Feed-Through Mode Setting Don't Care	Specifies whether the Timing Analyzer evaluates timing constraints between the write and the read operations of the MLAB memory block. Performing a write and read operation simultaneously at the same address might result in metastability issues because no timing constraints between those operations exist by default. Turning on this option introduces timing constraints between the write and read operations on the MLAB memory block and thereby avoids metastability issues. However, turning on this option degrades the performance of the MLAB memory blocks. If your design does not perform write and read operations simultaneously at the same address, you do not need to set this option.
Number of Example Nodes Reported in Fitter Messages	Allows you to specify the maximum number of example nodes Fitter messages should display.

Table 36. Advanced Fitter Settings (5 of 8)
Option	Description
Optimize Design for Metastability	This setting improves the reliability of the design by increasing its Mean Time Between Failures (MTBF). When you enable this setting, the Fitter increases the output setup slacks of synchronizer registers in the design. This slack can exponentially increase the design MTBF. This option only applies when using the Timing Analyzer for timing-driven compilation. Use the Timing Analyzer `report_metastability` command to review the synchronizers detected in your design and to produce MTBF estimates.
Optimize Hold Timing	Directs the Fitter to optimize hold time within a device to meet timing requirements and assignments. The following settings are available: I/O Paths and Minimum TPD Paths—directs the Fitter to meet the following timing requirements and assignments: t_H from I/O pins to registers. Minimum t_CO from registers to I/O pins. Minimum t_PD from I/O pins or registers to I/O pins or registers. All Paths—directs the Fitter to meet the following timing requirements and assignments: t_H from I/O pins to registers. Minimum t_CO from registers to I/O pins. Minimum t_PD from I/O pins or registers to I/O pins or registers. When you disable the Optimize Timing logic option, the Optimize Hold Timing option is not available.
Optimize IOC Register Placement for Timing	Specifies whether the Fitter optimizes I/O pin timing by automatically packing registers into I/Os to minimize delays. Normal—the Fitter opportunistically packs registers into I/Os that should improve I/O timing. Pack All I/O Registers— the Fitter aggressively packs any registers connected to input, output, or output enable pins into I/Os, unless prevented by your constraints or other legality restrictions. Off—performs no periphery to core optimization.
Optimize Multi-Corner Timing	Directs the Fitter to consider all timing corners during optimization to meet timing requirements. These timing delay corners include both fast-corner timing and slow-corner timing. By default, this option is On, and the Fitter optimizes designs considering multi-corner delays in addition to slow-corner delays. When this option is Off, the Fitter optimizes designs considering only slow-corner delays from the slow-corner timing model (slowest manufactured device for a given speed grade, operating in low-voltage conditions). Turning this option On typically creates a more robust design implementation across process, temperature, and voltage variations. When you turn Off the Optimize Timing option, the Optimize Multi-Corner Timing option is not available.
Optimize Timing	Specifies whether the Fitter optimizes to meet the maximum delay timing requirements (for example, clock cycle time). By default, this option is set to Normal compilation. Turning this option Off helps fit designs that with extremely high interconnect requirements. Turning this option Off can also reduce compilation time at the expense of timing performance (because the Fitter ignores the design's timing requirements). If this option is Off, other Fitter timing optimization options have no effect (such as Optimize Hold Timing).

Table 37. Advanced Fitter Settings (6 of 8)
Option	Description
Periphery to Core Placement and Routing Optimization	Specifies whether the Fitter should perform targeted placement and routing optimization on direct connections between periphery logic and registers in the FPGA core. The following options are available: Auto—the Fitter automatically identifies transfers with tight timing windows, places the core registers, and routes all connections to or from the periphery. The Fitter performs these placement and routing decisions before the rest of core placement and routing. This sequence ensures that these timing-critical connections meet timing, and also avoids routing congestion. On— the Fitter optimizes all transfers between the periphery and core registers, regardless of timing requirements. Do not set this option to On globally. Instead, use the Assignment Editor to assign optimization to a targeted set of nodes or entities. Off—the Fitter performs no periphery to core optimization. Note: Only available for Intel^® Arria^® 10 and Intel^® Cyclone^® 10 GX devices.
Physical Placement Effort	Controls how much effort the Fitter spends during advanced physical placement optimization. High and Maximum effort settings result in additional compile time to further optimization the placement solution.
Placement Effort Multiplier	Specifies the relative time the Fitter spends in placement. The default value is 1.0, and legal values must be greater than 0. Specifying a floating-point number allows you to control the placement effort. A higher value increases CPU time but may improve placement quality. For example, a value of '4' increases fitting time by approximately 2 to 4 times but may increase quality.
Power Optimization During Fitting	Directs the Fitter to perform optimizations targeted at reducing the total power devices consume. The available settings for power-optimized fitting are: Off—performs no power optimizations. Normal compilation—performs power optimizations that are unlikely to adversely affect compilation time or design performance. Extra effort—performs additional power optimizations that might affect design performance or result in longer compilation time.

Table 38. Advanced Fitter Settings (7 of 8)
Option	Description
Programmable Power Maximum High-Speed Fraction of Used LAB Tiles	Sets the upper limit on the fraction of the high-speed LAB tiles. Legal values must be between 0.0 and 1.0. The default value is 1.0. A value of 1.0 means that there is no restriction on the number of high-speed tiles, and the Fitter uses the minimum number needed to meet the timing requirements of your design. Specifying a value lower than 1.0 might degrade timing quality, because some timing critical resources might be forced into low-power mode.
Programmable Power Technology Optimization	Controls how the Fitter configures tiles to operate in high-speed mode or low-power mode. The following options are available: Automatic—specifies that the Fitter minimizes power without sacrificing timing performance. Minimize Power Only—specifies that the Fitter sets the maximum number of tiles to operate in low-power mode. Force All Used Tiles to High Speed—specifies that the Fitter sets all used tiles to operate in high-speed mode. Force All Tiles with Failing Timing Paths to High Speed—sets all failing paths to high-speed mode. For designs that meet timing, the behavior of this setting is similar to the Automatic setting. For designs that fail timing, all paths with negative slack are put in high-speed mode. This mode likely does not increase the speed of the design, and it may increase static power consumption. This mode may assist in determining which logic paths need to be re-designed to close timing. Note: Only available for Intel^® Arria^® 10 and Intel^® Cyclone^® 10 GX devices.
Router Timing Optimization Level	Controls how aggressively the router tries to meet timing requirements. Setting this option to Maximum can increase design speed slightly, at the cost of increased compile time. Setting this option to Minimum can reduce compile time, at the cost of slightly reduced design speed. The default value is Normal.
Run Early Place during compilation	Enables the Early Place Fitter stage during full compilation. Turning on this setting may increase Fitter processing time.

Table 39. Advanced Fitter Settings (8 of 8)
Option	Description
Synchronizer Identification	Specifies how the Compiler identifies synchronization register chain registers for metastability analysis. A synchronization register chain is a sequence of registers with the same clock with no fan-out in between, which is driven by a pin or logic from another clock domain. The following options are available: Off—the Timing Analyzer does not identify the specified registers, or the registers within the specified entity, as synchronization registers. Auto—the Timing Analyzer identifies valid synchronization registers that are part of a chain with more than one register that contains no combinational logic. Use the Auto setting to generate a report of possible synchronization chains in your design. Forced if Asynchronous—the Timing Analyzer identifies synchronization register chains if the software detects an asynchronous signal transfer, even if there is combinational logic or only one register in the chain. Forced—the Timing Analyzer identifies the specified register, or all registers within the specified entity, as synchronizers. Only apply the Forced option to the entire design. Otherwise, all registers in the design identify as synchronizers. The Fitter optimizes the registers that it identifies as synchronizers for improved Mean Time Between Failure (MTBF), provided that you enable Optimize Design for Metastability. If a synchronization register chain is identified with the Forced or Forced if Asynchronous option, then the Timing Analyzer reports the metastability MTBF for the chain when it meets the design timing requirements.
Treat Bidirectional Pin as Output Pin	Specifies that the Fitter treats the bidirectional pin as an output pin, meaning that the input path feeds back from the output path.
Use Checkered Pattern as uninitialized RAM Content	Loads a checkered pattern as initial RAM content into all RAM blocks without specified RAM content that supports content initialization. Turning on this option does not affect simulation, which may cause on-chip behavior to differ from simulation results.
Weak Pull-Up Resistor	Enables the weak pull-up resistor when the device is operating in user mode. This option pulls a high-impedance bus signal to VCC. Do not enable this option simultaneously with the Enable Bus-Hold Circuitry option. The Fitter ignores this option if you apply to anything other than a pin.

Other Assignments

set_global_assignment –name ERROR_ON_INVALID_ENTITY_NAME:

The software ignores .qsf and .qip assignments where the entity field is not a name that exists in the design and generates a warning. If you set ERROR_ON_INVALID_ENTITY_NAME to ON, the software generates these warnings as errors.

1.12. Design Compilation Revision History

This document has the following revision history.

Document Version	Intel^® Quartus^® Prime Version	Changes
2020.09.28	20.3	Added references to ECO Compilation Flow. Removed references to deprecated Early Place Compiler flow.
2020.05.08	20.1	Added note about programming file differences between versions to "Compilation Overview" topic.
2020.04.13	20.1	Added new "Fast Forward Compile by Hierarchy" topic. Added new assignment to Fitter Settings Reference. Updated "Verilog and SystemVerilog Synthesis Support" topic for SystemVerilog 2012 support. Added programming file generation support for Intel^® Agilex™ devices. Added "Analyzing with the Snapshot Viewer" topic. Added "Running the Snapshot Viewer" topic. Added "Analyzing Failing Paths with Snapshot Viewer" topic. Added "Analyzing Clocking with Snapshot Viewer" topic. Added "Analyzing High Fan-Out Nets with Snapshot Viewer" topic. Added "Analyzing Constraints with Snapshot Viewer" topic. Added "Analyzing Congestion with Snapshot Viewer" topic. Removed Early Place Flow Removed Synthesis Reports figure and table. Removed Heat-Map in Global Signal Visualization Report figure Changed sentence in Fast Forward Compilation to The Fitter automatically retimes registers across RAM and DSP blocks from The Fitter does not automatically retime registers across RAM and DSP blocks. Added more Preservation Level information to Design Partition table.
2019.10.20	19.3	Added "Automatic Gated Clock Conversion" topic. Updated "Fractal Synthesis Optimization" and "Enabling or Disabling Fractal Synthesis" topics for automated fractal synthesis for small multipliers.
2019.09.30	19.3	Added support for Intel^® Agilex™ devices throughout. Added "Global Signal Visualization Report" topic. Added "Global Router Wire Utilization Map" topic. Added "Fast Preserve Option" topic. Reordering of some topics to match design flow.
2019.07.02	19.1	Made minor changes in "Fractal Synthesis Optimization" topic. Added a note in step 3a of "Running Synthesis" about enabling fractal synthesis project-wide. Added details about synthesis of `PRESERVE_FANOUT_FREE_NODE` to "Partial Reconfiguration Design Guidelines." Corrected typo in "Step 3: Run Fast Forward Compile and Hyper-Retiming." Removed "Enabling Timing-Driven Synthesis" topic.
2019.04.01	19.1	In "Running Synthesis", removed a step about enabling fractal synthesis project-wide. Updated the "Fractal Synthesis Optimization" topic to describe signed multiplication feature that is now supported by multiplier regularization and arithmetic packing algorithms.
2019.01.03	18.1.0	Added snapshot description to "Compilation Overview" and linked to content from "Exporting a Design Partition" and "Exporting a Version-Compatible Compilation Database."
2018.10.19	18.1	Described dependency of Rapid Recompile on Enable Intermediate Fitter Snapshots option.
2018.09.24	18.1	Described option to enable or disable intermediate Fitter snapshots and updated descriptions of compilation flows and dashboard accordingly. Added "Exporting Compilation Results section and subtopics." Described migration of full chip database in "Exporting a Version-Compatible Compilation Database" topic. Described automated .qdb partition export in "Exporting a Design Partition" topic. Described viewing QDB file metadata in "Viewing Quartus Database File Information." Added "Fractal Synthesis Optimization" topic and updated "Running Synthesis" topic steps for new option. Described new Compiler Optimization Modes and described notice that appears for extended optimization modes added via .qsf. Described new Global Signal Visualization Report. Added "Factors Affecting Compilation Results" topic. Added "Using the Compilation Dashboard" topic. Added description of Enable Auto-Pipelining setting. Added description of Enable Formal Verification Support to "Advanced Synthesis Settings." Added description of Report PR Initial Values as Errors option to "Advanced Synthesis Settings." Added description of Size of the Latch Report option to "Advanced Synthesis Settings." Added description of Size of the PR Initial Conditions Report option to "Advanced Synthesis Settings." Added description of Advanced Physical Synthesis option to "Fitter Settings Reference." Added description of Allow DSP Retiming option to "Fitter Settings Reference." Added description of Allow Early Global Retiming in the Fitter option to "Fitter Settings Reference." Added description of Allow Hyper-Aware Register Chain Area Optimizations in the Fitter option to "Fitter Settings Reference." Added description of Allow RAM Retiming option to "Fitter Settings Reference." Added description of Number of Example Nodes Reported in Fitter Messages option to "Fitter Settings Reference." Added description of Physical Placement Effort option to "Fitter Settings Reference." Added description of Use Checkered Pattern as uninitialized RAM Content option to "Fitter Settings Reference." Updated description of Safe State Machine option for Auto setting. Removed support for Ignore ROW GLOBAL Buffers option. Removed support for Ignore CARRY Buffers option. Removed support for Ignore CASCADE Buffers option.
2018.05.07	18.0	Updated Optimization Modes topic to add Compile Time (Aggressive). Relocated concurrent analysis content from the Early Place Flow topic to a new Concurrent Analysis During Synthesis or Fitting topic. Rapid Recompile now supports Intel^® Stratix^® 10 devices. Enhanced description of Retime Stage Reports. Enhanced description of Retime Stage to include classic register retiming.

Table 40. Document Revision History
Date	Version	Changes
2017.11.06	17.1.0	Added support for Intel^® Stratix^® 10 Hyper-Aware design flow, Hyper-Retiming, Fast Forward compilation, and Fast Forward Viewer. Added Advanced HyperFlex Settings topic. Added Retiming Restrictions and Workarounds topic. Added statement about Fast Forward compilation support for retiming across RAM and DSP blocks. Added Concurrent Analysis topic. Added Analyzing Fitter Snapshots topic. Added Compilation Dashboard Early Place stage control image. Added Running late_place After Early Place topic. Updated for latest Intel^® naming conventions.
2017.05.08	17.0.0	Added reference to initial compilation support for Cyclone^® 10 GX devices. Described concurrent analysis following Early Place. Updated Compilation Dashboard images for Timing Analyzer, Report, Setting, and Concurrent Analysis controls. Updated description for Auto DSP Block Replacement in Advanced Synthesis Settings. Updated Advanced Fitter Settings for Allow Register Retiming, and for removal of obsolete SSN Optimization option. Added Prevent Register Retiming topic. Added Preserve Registers During Synthesis topic. Removed limitation for Safe State Machine logic option. Added references to Partial Reconfiguration and Block-Based Design Flows.
2016.10.31	16.1.0	Implemented Intel re-branding. Described Compiler snapshots and added Analyzing Snapshot Timing topic. Updated project directory structure diagram. Described new Fitter stage menu commands and reports. Added description of Early Place Flow, Implement Flow, and Finalize Flow. Added description of Incremental Optimization in the Fitter. Reorganized order of topics in chapter. Removed deprecated Per-Stage Compilation (Beta) Compilation Flow.
2016.05.03	16.0.0	Added description of Fitter Plan, Place and Route stages, reporting, and optimization. Added Per-Stage Compilation (Beta) Compilation Flow Added Compilation Dashboard information. Removed support for Safe State Machine logic option. Encode safe states in RTL. Added Generating Dynamic Synthesis Reports topic. Updated Quartus project directory structure.
2015.11.02	15.1.0	First version of document.

2. Reducing Compilation Time

You can employ various techniques to reduce to time required for synthesis and fitting in the Intel^® Quartus^® Prime Compiler.

2.1. Factors Affecting Compilation Results

Almost any change to the following project settings, hardware, or software can impact the results from one compilation to the next.

Project Files—changes to project settings (.qsf, quartus2.ini), design files, and timing constraints (.sdc) can change the results.
Any setting that changes the number of processors during compilation can impact compilation results.
Hardware—CPU architecture, not including hard disk or memory size differences. Windows XP x32 results are not identical to Windows XP x64 results. Linux x86 results is not identical to Linux x86_64.
Intel^® Quartus^® Prime Software Version—including build number and installed interim updates. Click Help > About to obtain this information.
Operating System—Windows or Linux operating system, excluding version updates. For example, Windows XP, Windows Vista, and Windows 7 results are identical. Similarly, Linux RHEL, CentOS 4, and CentOS 5 results are identical.

2.2. Compilation Time Advisor

A Compilation Time Advisor is available in the Intel^® Quartus^® Prime GUI by clicking Tools > Advisors > Compilation Time Advisor. This chapter describes all the compilation time optimizing techniques available in the Compilation Time Advisor.

2.3. Strategies to Reduce the Overall Compilation Time

You can use the following strategies to reduce the overall time required to compile your design:

Parallel compilation (for systems with multiple processor cores)
Rapid Recompile and Smart Compilation reuse results from a previous compilation to reduce overall compilation time

2.3.1. Running the ECO Compilation Flow

The Intel^® Quartus^® Prime Pro Edition software supports last-minute, targeted design changes (also known as engineering change orders (ECOs)), even after you fully compile the design. ECOs typically occur during the design verification stage. Refer to the Intel^® Quartus^® Prime Pro Edition User Guide: Design Optimization for details.

2.3.2. Running Rapid Recompile

During Rapid Recompile the Compiler reuses previous synthesis and fitting results whenever possible, and does not reprocess unchanged design blocks. Use Rapid Recompile to reduce timing variations and the total recompilation time after making small design changes.

Figure 64. Rapid Recompile

To run Rapid Recompile, follow these steps:

Prior to initial compilation, click Assignments > Settings > Compiler Settings and turn on Enable Intermediate Fitter Snapshots. This option must be enabled to subsequently use the Rapid Recompile feature.
To start Rapid Recompile following an initial compilation (or after running the Route stage of the Fitter), click Processing > Start > Start Rapid Recompile. Rapid Recompile implements the following types of design changes without full recompilation:
- Changes to nodes tapped by the Signal Tap Logic Analyzer
- Changes to combinational logic functions
- Changes to state machine logic (for example, new states, state transition changes)
- Changes to signal or bus latency or addition of pipeline registers
- Changes to coefficients of an adder or multiplier
- Changes register packing behavior of DSP, RAM, or I/O
- Removal of unnecessary logic
- Changes to synthesis directives
Click the Rapid Recompile Preservation Summary report to view detailed information about the percentage of preserved compilation results.

Figure 65. Rapid Recompile Preservation Summary

2.3.3. Enabling Multi-Processor Compilation

The Compiler can detect and use multiple processors to reduce total compilation time. You specify the number of processors the Compiler uses. The Intel^® Quartus^® Prime software can use up to 16 processors to run algorithms in parallel. The Compiler uses parallel compilation by default. To reserve some processors for other tasks, specify a maximum number of processors that the software uses.

This technique reduces the compilation time by up to 10% on systems with two processing cores, and by up to 20% on systems with four cores. 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.

The Intel^® Quartus^® Prime software does not necessarily use all the processors that you specify during a given compilation. Additionally, the software never uses more than the specified number of processors. This fact enables you to work on other tasks without slowing down your computer. The use of multiple processors does not affect the quality of the fit. For a given Fitter seed, and given Maximum processors allowed setting on a specific design, the fit is exactly the same and deterministic. This remains true, regardless of the target machine, and the number of available processors. Different Maximum processors allowed specifications produce different results of the same quality. The impact is similar to changing the Fitter seed setting.

To enable multiprocessor compilation, follow these steps:

Open or create an Intel^® Quartus^® Prime project.
Click Assignments > Settings > Compilation Process Settings.
Under Parallel compilation, specify options for the number of processors the Compiler uses.
View detailed information about processor use in the Parallel Compilation report following compilation.
To specify the number of processors for compilation at the command line, use the following Tcl command in your script:
```
set_global_assignment -name NUM_PARALLEL_PROCESSORS <value>
```
In this case, <value> is an integer from 1 to 16.

If you want the Intel^® 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
```
Note: 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. Do not use the Intel^® HT Technology for Intel^® Quartus^® Prime compilations.

2.3.4. Using Block-Based Compilation

During the design process, you can isolate functional blocks that meet placement and timing requirements from others still undergoing change and optimization. By isolating functional blocks into partitions, you can apply optimization techniques to selected areas only compile those areas.

When using block-based compilation, you can enable the Fast Preserve option to reduce the logic of preserved partitions to only interface logic during compilation, thereby reducing the time the Compiler requires to synthesize, place, and route the partition. Interface logic is logic at the partition boundary that interfaces with the rest of the design.

To create partitions dividing functional blocks:

In the Design Partition Planner, identify blocks of a size suitable for partitioning.
In general, a partition represents roughly 15 to 20 percent of the total design size. Use the information area below the bar at the top of each entity.
Figure 66. Entity representation in the Design Partition Planner
Extract and collapse entities as necessary to achieve stand-alone blocks
For each entity of the desired size containing related blocks of logic, right-click the entity and click Create Design Partition to place that entity in its own partition.
The goal is to achieve partitions containing related blocks of logic.
To enable the Fast Preserve option that simplifies the logic of the preserved partition to only interface logic during compilation, click Assignments > Settings > Compiler Settings > Incremental Compile > Fast Preserve.

2.3.5. Disabling the Register Power-up Initialization

By disabling the register power-up initialization, you can speed up the bitstream initialization process, reduce the bitstream size (allowing you to select smaller configuration device), and reduce the configuration time.

Important:

This option is available only for Intel^® Stratix^® 10 and Intel^® Agilex™ devices.
Optimizations that rely on power-up states are disabled.
Bitstream assembler creates bitstreams without the register power-up initialization.

To disable the initialization, enable the Disable Register Power-up Initialization option through the Device and Pin Options dialog.

Figure 67. Device and Pin Options

When you enable the Disable Register Power-up Initialization option, Synthesis prints a warning for registers with power-up care, as shown in the following image:

Figure 68. Warning for Registers

To view registers with defined power-up states that the Compiler cannot preserve, refer to the Registers with Explicit Power-up Settings report,

Figure 69. Registers with Explicit Power-up Settings Report

For more information about the reset strategy required when you no longer can rely on registers' power-up states to reset the designs, refer to Partial Reconfiguration Design Flow in Intel^® Quartus^® Prime Pro Edition User Guide: Partial Reconfiguration.

2.4. Reducing Synthesis Time and Synthesis Netlist Optimization Time

You can reduce synthesis time without affecting the Fitter time by reducing your use of netlist optimizations. For tips on reducing synthesis time when using third-party EDA synthesis tools, refer to your synthesis software’s documentation.

2.4.1. Settings to Reduce Synthesis Time and Synthesis Netlist Optimization Time

Synthesis netlist and physical synthesis optimization settings can significantly increase the overall compilation time for large designs. Refer to Analysis and Synthesis messages to determine the length of optimization time.

If your design already meets performance requirements without synthesis netlist or physical synthesis optimizations, turn off these options to reduce compilation time. If you require synthesis netlist optimizations to meet performance, optimize partitions of your design hierarchy separately to reduce the overall time spent in Analysis and Synthesis.

2.4.2. Use Appropriate Coding Style to Reduce Synthesis Time

Your HDL coding style can also affect the synthesis time. For example, if you want to infer RAM blocks from your code, you must follow the guidelines for inferring RAMs. If RAM blocks are not inferred properly, the software implements those blocks as registers.

If you are trying to infer a large memory block, the software consumes more resources in the FPGA. This can cause routing congestion and increasing compilation time significantly. If you see high routing utilizations in certain blocks, it is a good idea to review the code for such blocks.

2.5. Reducing Placement Time

The time required to place a design depends on two factors: the number of ways the logic in your design can be placed in the device, and the settings that control the amount of effort required to find a good placement.

You can reduce the placement time by changing the settings for the placement algorithm.

Sometimes there is a trade-off between placement time and routing time. Routing time can increase if the placer does not run long enough to find a good placement. When you reduce placement time, ensure that it does not increase routing time and negate the overall time reduction.

2.5.1. Placement Effort Multiplier Settings

You can control the amount of time the Fitter spends in placement by reducing with the Placement Effort Multiplier option.

Click Assignments > Settings > Compiler Settings > Advanced Settings (Fitter) and specify a value for Placement Effort Multiplier. The default is 1.0. Legal values must be greater than 0 and can be non-integer values. Numbers between 0 and 1 can reduce fitting time, but also can reduce placement quality and design performance.

2.6. Reducing Routing Time

The routing time is usually not a significant amount of the compilation time. The time required to route a design depends on three factors: the device architecture, the placement of your design in the device, and the connectivity between different parts of your design.

If your design requires a long time to route, perform one or more of the following actions:

Check for routing congestion.
Turn off Fitter Aggressive Routability Optimization.

2.6.1. Identifying Routing Congestion with the Chip Planner

To identify areas of routing congestion in your design:

Click Tools > Chip Planner.
To view the routing congestion in the Chip Planner, double-click the Report Routing Utilization command in the Tasks list.
Click Preview in the Report Routing Utilization dialog box to preview the default congestion display.
Change the Routing utilization type to display congestion for specific resources. The default display uses dark blue for 0% congestion and red for 100%.
Adjust the slider for Threshold percentage to change the congestion threshold level.

The Intel^® Quartus^® Prime compilation messages contain information about average and peak interconnect usage. Peak interconnect usage over 75%, or average interconnect usage over 60% indicate possible difficulties fitting your design. Similarly, peak interconnect usage over 90%, or average interconnect usage over 75%, indicate a high chance of not getting a valid fit.

2.6.1.1. Areas with Routing Congestion

Even if average congestion is not high, the design may have areas where congestion is high in a specific type of routing. You can use the Chip Planner to identify areas of high congestion for specific interconnect types.

You can change the connections in your design to reduce routing congestion
If the area with routing congestion is in a Logic Lock (Standard) region or between Logic Lock (Standard) regions, change or remove the Logic Lock (Standard) regions and recompile your design.
- If the routing time remains the same, the time is a characteristic of your design and the placement
- If the routing time decreases, consider changing the size, location, or contents of Logic Lock (Standard) regions to reduce congestion and decrease routing time.

2.6.1.2. Congestion due to HDL Coding style

Sometimes, routing congestion may be a result of the HDL coding style used in your design. After identifying congested areas using the Chip Planner, review the HDL code for the blocks placed in those areas to determine whether you can reduce interconnect usage by code changes.

2.7. Reducing Static Timing Analysis Time

If you are performing timing-driven synthesis, the Intel^® Quartus^® Prime software runs the Timing Analyzer during Analysis and Synthesis.

The Intel^® Quartus^® Prime Fitter also runs the Timing Analyzer during placement and routing. If there are incorrect constraints in the Synopsys* Design Constraints File (.sdc), the Intel^® Quartus^® Prime software may spend unnecessary time processing constraints several times.

If you do not specify false paths and multicycle paths in your design, the Timing Analyzer may analyze paths that are not relevant to your design.
If you redefine constraints in the .sdc files, the Timing Analyzer may spend additional time processing them. To avoid this situation, look for indications that Synopsis design constraints are being redefined in the compilation messages, and update the .sdc file.
Ensure that you provide the correct timing constraints to your design, because the software cannot assume design intent, such as which paths to consider as false paths or multicycle paths. When you specify these assignments correctly, the Timing Analyzer skips analysis for those paths, and the Fitter does not spend additional time optimizing those paths.

2.8. Setting Process Priority

It might be necessary to reduce the computing resources allocated to the compilation at the expense of increased compilation time. It can be convenient to reduce the resource allocation to the compilation with single processor machines if you must run other tasks at the same time.

2.9. Reducing Compilation Time Revision History

Document Version	Intel^® Quartus^® Prime Version	Changes
2020.09.28	20.3	Added reference to ECO Compilation flow.
2019.11.11	19.3	Added support for Fast Preserve option to "Using Block-Based Compilation" topic.
2019.09.30	19.3	Added support for Intel^® Agilex™ devices throughout.
2019.07.02	19.1	Added the Using the No-Register Initialization Flow topic.
2018.10.19	18.1	Described dependency of Rapid Recompile on Enable Intermediate Fitter Snapshots option.
2017.11.06	17.1	Added topic: Using Block-Based Compilation.

Date	Version	Changes
2017.05.08	17.0.0	Clarified impact of multiprocessor compilation on fit quality. Removed reference to deprecated Fitter Effort Logic Option. Removed section: Preserving Routing with Incremental Compilation.
2016.10.31	16.1.0	Implemented Intel rebranding.
2016.05.02	16.0.0	Corrected typo in Using Parallel Compilation with Multiple Processors. Removed information about deprecated physical synthesis options.
2015.11.02	15.1.0	Changed instances of Quartus II to Intel^® Quartus^® Prime .
2014.12.15	14.1.0	Updated location of Fitter Settings, Analysis & Synthesis Settings, and Physical Synthesis Optimizations to Compiler Settings. Added information about Rapid Recompile feature.
2014.08.18	14.0a10.0	Added restriction about smart compilation in Arria 10 devices.
June 2014	14.0.0	Updated format.
May 2013	13.0.0	Removed the “Limit to One Fitting Attempt”, “Using Early Timing Estimation”, “Final Placement Optimizations”, and “Using Rapid Recompile” sections. Updated “Placement Effort Multiplier Settings” section. Updated “Identifying Routing Congestion in the Chip Planner” section. General editorial changes throughout the chapter.
June 2012	12.0.0	Removed survey link.
November 2011	11.0.1	Template update.
May 2011	11.0.0	Updated “Using Parallel Compilation with Multiple Processors”. Updated “Identifying Routing Congestion in the Chip Planner”. General editorial changes throughout the chapter.
December 2010	10.1.0	Template update. Added details about peak and average interconnect usage. Added new section “Reducing Static Timing Analysis Time”. Minor changes throughout chapter.
July 2010	10.0.0	Initial release.

3. Intel Quartus Prime Pro Edition User Guide Design Compilation Archives

If the table does not list a software version, the user guide for the previous software version applies.

Intel^® Quartus^® Prime Version	User Guide
19.4	Intel^® Quartus^® Prime Pro Edition User Guide Design Compilation
19.3	Intel^® Quartus^® Prime Pro Edition User Guide Design Compilation
19.1	Intel^® Quartus^® Prime Pro Edition User Guide Design Compilation
18.1	Intel^® Quartus^® Prime Pro Edition User Guide Design Compilation
18.0	Compiler User Guide Intel^® Quartus^® Prime Pro Edition

A. Intel Quartus Prime Pro Edition User Guides

Refer to the following user guides for comprehensive information on all phases of the Intel^® Quartus^® Prime Pro Edition FPGA design flow.