Intel Quartus Prime Pro Edition User Guide: Design Compilation

RSS

UG-20132 | 2019.07.02

Design Compilation

The Intel^® Quartus^® Prime Compiler synthesizes, places, and routes your design before ultimately generating a device programming file. 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.

Figure 1. Compilation Dashboard

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

Supports Intel^® Arria^® 10, Intel^® Cyclone^® 10 GX, and Intel^® Stratix^® 10 devices.
Hyper-Aware Design Flow—use Hyper-Retiming and Fast Forward compilation for the highest performance in Intel^® Stratix^® 10 devices.
Partial Reconfiguration—supports dynamic reconfiguration of a portion of the FPGA, while the remaining FPGA continues to function.
Block-Based Design Flows—enables preservation of design blocks within a project, and reuse of those design blocks in other projects.

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. Early Place—places all core elements in an approximate location to facilitate design planning. Finalizes clock planning for Intel^® Stratix^® 10 designs. The "early placed" 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 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.

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

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.

Click the pencil icon to edit settings for that stage of the compilation flow.
Click Compile Design to run all modules of the Compiler in sequence, or click any individual Compiler module to run compilation through that stage.
Click the report icon to view reports for that compilation stage.

Figure 2. Compilation Dashboard

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.

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
Early Place Flow	Places all core elements in an approximate location to facilitate design planning. Run Early Place to review initial high-level placement of design elements in the Chip Planner or to debug and fine-tune timing constraints. This information is useful to guide your floorplanning decisions.
Fitter (Implement) Flow	Runs the Plan, Early Place, Place, Route, and Retime stages. Run this flow when you are ready to implement placement, routing, and retiming. If successful, you can now perform the Finalize, Timing Analysis, and Assembler stages. ²
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 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.

² Retiming and Hyper-Aware design flow only for Intel^® Stratix^® 10 devices.

Design Synthesis

Design synthesis is the process that translates design source files into an atom netlist for mapping to device resources. The Intel^® Quartus^® Prime Compiler synthesizes standards-compliant Verilog HDL (.v), VHDL (.vhd), and SystemVerilog (.sv). The Compiler also synthesizes 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.

Figure 3. Design Synthesis

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.

The Analysis & Synthesis module of the Compiler synthesizes design files and creates one or more project databases for each design partition. You can specify various settings that affect synthesis processing.

The Compiler preserves the results of Analysis & Synthesis in the synthesis snapshot.

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.

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. 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.

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 4. Hierarchical Project Structure ( Intel^® Stratix^® 10 Design)

Note: 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)

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:

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 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.
- On the Compiler Settings page enable or disable the Enable Intermediate Fitter Snapshots option to to generate and preserve snapshots for the Plan, Place, Route, and Retime stages any time you run full compilation. To save compilation time, the Compiler does not generate or preserve these intermediate snapshots by default. However, you must enable this option to use Rapid Recompile.
- To specify advanced synthesis settings, click Assignments > Settings > Compiler Settings, and then click Advanced Settings (Synthesis). Optionally, enable Timing-Driven Synthesis to account for timing constraints during synthesis.
To enable optional fractal synthesis optimizations for arithmetic-intensive designs that exhaust all DSP resources, follow these steps:
1. Review the guidelines in Fractal Synthesis Optimization.
  
  CAUTION:
  Enabling fractal synthesis project-wide causes unnecessary bloat on modules that are not suitable for fractal optimizations.
2. Click Assignments > Assignment Editor.
3. 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 5. Fractal Synthesis Assignment in Assignment Editor
To run synthesis, click Synthesis on the Compilation Dashboard.

Preserve 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)

Enabling Timing-Driven Synthesis

Timing-driven synthesis directs the Compiler to account for your timing constraints during synthesis. Timing-driven synthesis runs initial timing analysis to obtain netlist timing information. Synthesis then focuses performance efforts on timing-critical design elements, while optimizing non-timing-critical portions for area.

Timing-driven synthesis preserves timing constraints, and does not perform optimizations that conflict with timing constraints. Timing-driven synthesis may increase the number of required device resources. Specifically, the number of adaptive look-up tables (ALUTs) and registers may increase. The overall area can increase or decrease. Runtime and peak memory use increases slightly.

Intel^® Quartus^® Prime Pro Edition runs timing-driven synthesis by default. To enable or disable this option manually, click Assignments > Settings > Compiler Settings > Advanced Settings (Synthesis).

Fractal Synthesis Optimization

You can enable optional fractal synthesis optimizations that are 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.

CAUTION:

Enabling fractal synthesis project-wide causes unnecessary bloat on modules that are not suitable for fractal optimizations.

Table 4. Fractal Synthesis Area Improvement
		Area (LABs)
Device	Dot-product	Fractal Synthesis ON	Fractal Synthesis OFF
Intel^® Arria^® 10	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	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

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).

To use Fractal Synthesis optimizations, identify the basic arithmetic building block that the Fractal Synthesis engine will focus on and mark it using the FRACTAL_SYNTHESIS attribute. You can specify the attribute in one of the following ways:

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>

Note: Fractal synthesis optimization is not recommended for designs without deep-learning accelerators or other high-throughput, arithmetic-intensive functions that exceed all DSP resources. Consider the following factors before enabling fractal synthesis optimization:

Fractal Synthesis Considerations

Intel^® Arria^® 10 and Intel^® Stratix^® 10 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 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 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 compiler is making to pack computational logic into smaller number of LABs. If the design is already highly utilized, this effort might be skipped.
- 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.

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 6. 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

Simple Unsigned Dot-Product Design

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

Quartus Synthesis prints the following messages on the console:

Figure 7. Console Messages

In the Chip Planner, this design can be observed having two unsigned dot-product cores independently optimized and placed, and LAB resources almost 100% optimized, as illustrated in the following image:

Figure 8. Design Placement

Signed Dot-Product Design

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

Quartus Synthesis prints the following messages on the console:

Figure 9. Console Messages

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

Figure 10. 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 11. 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.

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.

Figure 12. Synthesis Reports

Table 5. Synthesis Reports (Design Dependent)
Generated Report	Description
Summary	Shows summary information about synthesis, such as the status, date, software version, entity name, device family, timing model status, and various types of logic utilization.
Synthesis Settings	Lists the values of all synthesis settings during design processing.
Parallel Compilation	Lists specifications for any use of parallel processing during synthesis.
Resource Utilization By Entity	Lists the quantity of all types of logic usage for each entity in design synthesis.
Multiplexer Restructuring Statistics	Provides statistics for the amount of multiplexer restructuring that synthesis performs.
IP Cores Summary	Lists details about each IP core instance in design synthesis. Details include IP core name, vendor, version, license type, entity instance, and IP include file.
Synthesis Source Files Read	Lists details about all source files in design synthesis. Details include file path, file type, and any library information.
Resource Usage Summary for Partition	Lists the quantity of all types of logic usage for each design partition in design synthesis.
RAM Summary for Partition	Lists RAM usage details for each design partition in design synthesis. Details include the name, type, mode, and density.
Register Statistics	Lists the number of registers using various types of global signals.
Synthesis Messages	Lists all information, warning, and error messages that report conditions observed during the Analysis & Synthesis process.

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 13. Concurrent Analysis Options

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. 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.

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^® Stratix^® 10 devices only.

Fitter Stage Commands

Launch Fitter processes from the Processing menu or Compilation Dashboard.

Table 6. Fitter Stage Commands
Command	Description
Fitter (Implement)	Runs the Plan, Early Place, Place, Route, and Retime stages.
Start Fitter (Plan)	Loads synthesized periphery placement data and constraints, and assigns periphery elements to device I/O resources. 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) and perform clock planning for Intel^® Arria^® 10 and Intel^® Cyclone^® 10 GX designs. This command creates the planned snapshot.
Start Fitter (Early Place)	Places all core elements in an approximate location to facilitate design planning. After this stage, the Chip Planner displays initial high-level placement of design elements. The Compilation reports identifies high fan-out signals that increase placement complexity. Use this information to guide your floorplanning decisions. For Intel^® Stratix^® 10 designs, you can also do early clock planning after this stage. This command creates the early placed snapshot. Early Place does not run during the full compilation flow by default, but you can enable by default or run directly from the Compilation Dashboard.
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. After this stage, validate delay chain settings and analyze routing resources. Perform detailed setup and hold timing closure in the Timing Analyzer and view routing congestion via the Chip Planner. 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. The Fitter identifies and corrects the short paths with hold violations during the Fitter (Finalize) stage by adding routing wire along the paths. This command creates the retimed snapshot.
Start Fitter (Finalize)	Performs post-routing optimization on the design. This stage converts unneeded tiles from High Speed to Low Power. This command creates the final snapshot. For Intel^® Stratix^® 10 designs, the Fitter also runs post-route fix-up to correct any short path hold violations remaining from retiming.

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, 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 7. 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) and perform clock planning for Intel^® Arria^® 10 and Intel^® Cyclone^® 10 GX designs.
Early Place	After this stage, the Chip Planner can display initial high-level placement of design elements. Use this information to guide your floorplanning decisions. For Intel^® Stratix^® 10 designs, you can also review and modify clock assignments after performing this stage.
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.⁴

⁴ Retiming available only for Intel^® Stratix^® 10 devices.

Early Place Flow

Early Place begins assigning core logic to device resources. Run Early Place to quickly view the effect of iterative floorplanning changes, without waiting for full placement or full compilation. The Compiler preserves a snapshot of the Early Place results. Following Early Place, click the Timing Analyzer icon to validate your .sdc constraints. Do not use the Early Place timing results to compare with Final timing results, as timing between early snapshots and the final snapshot are not well correlated.

Early Place runs automatically during Fitter processing if you enable the Early Place stage on the compilation dashboard, or by enabling Settings > Compiler Settings > Fitter Settings (Advanced) > Run Early Place During Compilation.

Running late_place After Early Place

After running the Early Place stage, you can run late_place, rather than the full Place stage, to reduce total compilation time. late_place skips the placements that Early Place makes. The Place stage includes the Early Place and late_place stages.

The Intel^® Quartus^® Prime GUI does not support the late_place option. The late_place option is only available at the command line, after running the Early Place stage from the GUI or from the command line. Running late_place generates the placed snapshot. Access command-line help to display details about the late_place argument.

Note: Type quartus_fit –help=late_place for command-line help on this argument.

To run late_place after Early Place:

To run the Early Place stage and generate the Early Place snapshot, perform one of the following:
- To run Early Place in the GUI, click Early Place on the Compilation Dashboard. The Compiler runs any required prerequisite stages.
- To run Early Place (and prerequisite stages) at the command-line, run the following commands. The "-" character equals double hyphens:
```
quartus_ipgenerate <design_name>
quartus_syn <design name> 
quartus_fit -plan <design name>
quartus_fit -early_place <design name>
```
Note: You must generate the early placed snapshot before running late_place, or the Fitter reports an error.
View Early Place results in the Early Placed Fitter reports of the Compilation Report, and in the Chip Planner (Tools > Chip Planner).

When satisfied with the Early Place results, type one of the following commands to continue to the late_place stage and beyond. View late_place results and processing messages in the <design name> .fit.place.rpt file.

quartus_fit –late_place <design name> 
(runs late_place)

quartus_fit –late_place –route <design name>
(runs late_place and route)

quartus_fit –late_place –route –finalize <design name>
(runs late_place and finalize)

Analyzing Fitter Snapshots

Analyze the results of Fitter stages to evaluate your design before running the next stage, or before running a full compilation. Use this technique to isolate potential problems and reduce the overall time you spend running design compilation. The following topics describe typical use cases for analyzing Fitter snapshots.

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.

Validating SDC Constraints after the Plan Stage

The Fitter's Plan stage performs initial validation of your project's .sdc constraints. The Compiler generates messages during the plan stage that warn you about any possible invalid .sdc constraints. Stop compilation following the Plan stage to validate and make any necessary changes to .sdc constraints, before moving on to the next Fitter stage. To validate .sdc constraints after the Plan stage, follow these steps:

To run the Fitter's Plan stage, click Plan on the Compilation Dashboard. The Compiler automatically runs prerequisite compilation stages, if necessary.
On the Compilation Dashboard, click the Timing Analyzer icon adjacent to the Fitter stage. The Create Timing Netlist dialog box appears and loads the corresponding stage snapshot.

Figure 15. Plan Stage Timing Analyzer Icon in Compilation Dashboard
In the Create Timing Netlist dialog box, click OK. The planned database loads in the Timing Analyzer.

Figure 16. Planned Snapshot in Create Timing Netlist Dialog Box
On the Tasks pane, click Read SDC File. The Timing Analyzer reads and processes any .sdc files. For multiple .sdc files, the report also includes the .sdc processing sequence.

Figure 17. Read SDC File Command
To report the .sdc constraints that apply to the project, click Report SDC under the Diagnostic folder, in the Tasks pane.

Figure 18. SDC File List Report
Conversely, to report the constraints in the .sdc files that the Timing Analyzer ignores, click Report Ignored Constraints under the Diagnostic folder, in the Tasks pane.
To report all paths in your design that have no constraints, click Report Unconstrained Paths under the Diagnostic folder, in the Tasks pane.

Figure 19. Unconstrained Paths Summary

The Compilation Report displays the Timing Analysis that you run for each stage.

Figure 20. Plan and Retime Stage Timing Analysis Reports in Compilation Report

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 21. 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 22. 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 designs.

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

Clock Planning after Early Place ( Intel Stratix 10 only)

Intel^® Stratix^® 10 devices support clock planning after the Early Place stage, rather than after the Plan stage. After running Early Place, view the Global & Other Fast Signals report to view details and plan the clocks in your project. To view clock details after Early Place, follow these steps:

In the Compilation Dashboard, click the Early Place stage.
In the Compilation Report, under the Early Place Stage folder, click the Global & Other Fast Signals Details or Global & Other Fast Signals Summary report.

Figure 24. Global & Other Fast Signal Details Report

The report provides clock tree path length and depth. The shortest path length from clock source to clock tree, and the smallest clock tree depth, results in the best clock performance.
To visualize the clock path length and clock tree depth, click Tools > Chip Planner.
In the Chip Planner Tasks pane, click Report Clock Details under the Clock Reports folder.
In the Report Clock Details dialog box, click OK. The Report pane lists all the clocks in the design.
In the Report pane, select one or more clocks to highlight the clock elements in Chip Planner.

Figure 25. Visualizing Clocks in Chip Planner

After running the Early Place stage, you can run late_place, rather than the full Place stage, to reduce total compilation time.

Identifying High Fan-Out Signals after Early Place

High fan-out signals increase placement difficulty. After Early Place, identify and consider moving high fan-out signals to global resources.

In the Compilation Dashboard, click the Early Place stage.
In the Compilation Report, under the Early Place Stage folder, click the Non-Global High Fan-Out Signals report. The report lists the number of fan-outs for each signal.

Figure 26. Non-Global High Fan-Out Signals Report
To visualize the clock fan-out, right-click the signal name in the report, and then click Locate Node > Locate in Chip Planner.

Figure 27. Non-Global High Fan-Out Signal in Chip Planner
To place those high fan-out signals on global resources, click Assignments > Assignment Editor, and then assign the high fan-out signal to a global signal before re-starting compilation.

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.

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.

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 28. 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 designs.

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 29. Place Stage Reports

Global Signal Visualization Report

In addition, for Intel^® Stratix^® 10 designs, you can access the Global Signal Visualization report to view global signal routing and overall clock sector utilization in an interactive heat-map. Use this data to quickly review how the Fitter constrains clock regions to device sectors. 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.

Filter the display to Show Routing Utilization and Show Sector Utilization. You can search for Signal Names, and then click the signal names to display its properties. Right-click the Signal Names to Locate Node in Chip Planner and various other tools.

Figure 30. Heat-Map in Global Signal Visualization Report

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 31. Route Stage Reports

Retime Stage Reports

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 32. Retiming Limit Details

Finalize Stage Reports

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

HSLP Summary. For Intel^® Arria^® 10 designs, the Compiler converts unnecessary tiles to High-Speed or Low-Power (HSLP) tiles.
Post-route hold fix-up data. For Intel^® Stratix^® 10 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 33. Finalize Stage Reports ( Intel^® Stratix^® 10 Design)

Running Full Compilation

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.

Running the Hyper-Aware Design Flow

The Intel^® Quartus^® Prime Pro Edition Compiler helps you to take full advantage of the Intel^® Stratix^® 10 Intel^® Hyperflex™ architecture. Use the Hyper-Aware design flow to shorten design cycles and optimize performance.

The 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 for Intel^® Stratix^® 10 designs.

Hyper-Aware Design Flow

Hyper-Retiming

A key innovation of the Intel^® Stratix^® 10 architecture is the addition of multiple Hyper-Registers in every routing segment and block input. Maximizing the use of Hyper-Registers improves design performance. The prevalence of Hyper-Registers improves balance of time delays between registers and mitigates critical path delays. Hyper-Retiming moves registers out of ALMs and retimes them into Hyper-Registers, wherever advantageous. Hyper-Retiming runs automatically during fitting, requires minimal effort, and can result in significant performance improvement.

Figure 34. Hyper-Register Architecture

Fast Forward Compilation

If you require optimization beyond Hyper-Retiming, run Fast Forward compilation to generate timing closure recommendations that break key performance bottlenecks. Fast Forward compilation shows precisely where to make the most impact with RTL changes, and reports the performance benefits you can expect from each change. The Fitter does not automatically retime registers across RAM and DSP blocks. However, Fast Forward analysis shows the potential performance benefit from this optimization.

Fast-Forward compilation identifies the best location to add pipeline stages (Hyper-Pipelining), and the expected performance benefit in each case. After you modify the RTL to place pipeline stages at the boundaries of each clock domain, the Hyper-Retimer automatically places the registers within the clock domain at the optimal locations to maximize performance. Implement the recommendations in RTL to achieve similar results. After implementing any changes, re-run the Hyper-Retimer until the results meet performance and timing requirements. Fast Forward compilation does not run automatically as part of a full compilation. Enable or run Fast Forward compilation in the Compilation Dashboard.

Table 8. HyperFlex Optimization Steps
Optimization Step	Technique	Description
Step 1	Hyper-Retiming	Retimer moves existing registers into Hyper-Registers.
Step 2	Fast Forward Compile	Compiler generates design-specific timing closure recommendations and predicts performance improvement.
Step 3	Hyper-Pipelining	Use Fast Forward compilation to identify where to add new registers and pipeline stages in RTL.
Step 4	Hyper-Optimization	Design optimization beyond Hyper-Retiming and Hyper-Pipelining, such as restructuring loops, removing control logic limits, and reducing the delay along long paths.

The Hyper-Aware design flow includes the following high-level steps this chapter covers in detail:

Run the Retime stage during the Fitter to automatically retime ALM registers into Hyper-Registers.
Review Retiming Results in the Compilation Report.
If you require further performance optimization, run Fast Forward compilation.
Review Fast Forward timing closure recommendations.
Implement appropriate Fast Forward recommendations in your RTL.
Recompile the design through the Retime stage.

Figure 35. Hyper-Aware Design Flow

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 device interconnect.

The Fitter runs the Retime stage automatically following place and route when you target an Intel^® Stratix^® 10 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:

Create or open an Intel^® Quartus^® Prime project that is ready for design synthesis and fitting.
To run register retiming, click Retime on the Compilation Dashboard. The Compiler runs prerequisite stages automatically, as needed. The Compiler generates detailed reports and timing analysis data for each stage. Click the Report or Timing Analyzer icons to review results of each stage. Rerun any stage to apply any setting or design changes.
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.

Figure 36. Retiming Stage in Compilation Dashboard

Step 2: Review Retiming Results

The Fitter generates detailed reports showing the results of the Retime stage. Follow these steps to review the results and make additional performance improvements with register retiming.

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.
To further optimize, resolve any Limiting Reason in your design, and then rerun the Retime stage, as necessary.
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.

Table 9. 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 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.

Figure 37. Retiming Limit Details

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.

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 38. Technology Map Viewer

Figure 39. Post-Fit Viewer After Retiming

Step 3: Run Fast Forward Compile and Hyper-Retiming

When you run Fast Forward compilation, the Compiler predictively removes signals from registers to allow mobility within the netlist for subsequent retiming. Fast Forward compilation generates design-specific timing closure recommendations, and predicts maximum performance with removal of all timing restrictions. After you complete Fast Forward explorations, determine which recommendations you can implement to provide the most benefit. Implement appropriate recommendations in your RTL, and recompile the design to realize the performance levels that Fast Forward reports.

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

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.
View timing closure recommendations in the Compilation Report to evaluate design performance and implement key RTL performance improvements.
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.
Figure 40. Running Fast Forward Compilation

Figure 41. HyperFlex Settings

HyperFlex Settings

The HyperFlex settings page controls whether Fast Forward Compilation analyzes and reports results for specific logical structures in the Intel^® Hyperflex™ architecture of the Intel^® Stratix^® 10 FPGA. 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 10. 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.

Step 4: Review Hyper-Retiming 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.

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 42. Current and Potential Performance in Clock Fmax Summary

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 to view the implementation details and performance calculations for that step.

Table 11. 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.

Figure 43. Fast-Forward Details Report

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 44. Recommendations for Critical Chain

Figure 45. Locate Critical Chain in Fast Forward Viewer

Figure 46. Fast Forward Viewer Shows Predictive Results

Step 5: Implement Fast Forward Recommendations

Implement the Fast Forward timing closure recommendations in your design RTL and rerun the Retime stage to 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. However, if you require additional performance, implement more Fast Forward recommendations, 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.

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 47, 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 47. 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 12. 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.
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.

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 13. 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.

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 48. 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.

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 49. 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)).

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 50. 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 51. Creating a Design Partition from the Project Hierarchy
To view and edit all design partitions in the project, click Assignments > Design Partitions Window.

Figure 52. Design Partitions Window

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

Table 14. 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.
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.

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 53. 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 54. Specifying Export File in Design Partitions Window

.qsf Equivalent Assignment:

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

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 55. 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.

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 56. 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]
```

QDB File Attribute Types

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

Table 15. 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` ...

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 57. Clean Project Dialog Box Cleans the Project Database

Reducing Compilation Time

The Intel^® Quartus^® Prime Pro Edition software supports various strategies to reduce overall design compilation time. Running a full compilation including all Compiler modules on a large design can be time consuming. Use any the following techniques to reduce the overall compilation times of your design:

Parallel compilation—the Compiler detects and uses multiple processors to reduce compilation time (for systems with multiple processor cores).
Incremental optimization—breaks compilation into separate stages, allowing iterative analysis of results and optimization of settings at various compilation stages, prior to running a full compilation.
Rapid Recompile of changed blocks—the Compiler reuses previous compilation results and does not reprocess unchanged design blocks. This flow is recommended for making small design changes in HDL or for adding or changing Signal Tap debug logic.

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 58. 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 to 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 59. Rapid Recompile Preservation Summary

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.

Generating Programming Files

The Compiler's Assembler module generates files for device programming. Run the Assembler automatically as part of a full compilation, or run the Assembler module independently after design place and route. After running the Assembler, you can use the Programmer to download configuration data to a device. The Assembler generates one or more of the following files according to your specification in the Device & Pin Options dialog box.

Table 16. Assembler Generated Programming Files
Programming File	Description
SRAM Object Files (.sof)	A binary file containing the data for configuring all SRAM-based Intel FPGA devices.
Programmer Object Files (.pof)	A binary file containing the data for programming an EEPROM-based Intel configuration device. For example, the EPCS16 and EPCS64 devices, which configure SRAM-based Intel FPGA devices.
Hexadecimal (Intel-Format) Output Files (.hexout)	Contains configuration data that you can program into a parallel data source, such as an EPROM or a mass storage device, which configures an SRAM-based Intel FPGA device.
Raw Binary Files (.rbf)	Contains configuration data that an intelligent external controller uses to configure an SRAM-based Intel FPGA device.
Tabular Text Files (.ttf)	Contains configuration data that an intelligent external controller uses to configure an SRAM-based Intel FPGA device. Note: Generation of these files not available for Intel^® Stratix^® 10 designs.
Serial Vector Format File (.svf)

Before running the Assembler, specify settings to customize programming file generation. Click Assignments > Device > Device & Pin Options to enable or disable generation of optional programming files.
To generate device programming files, click Processing > Start > Start Assembler, or click Assembler on the Compilation Dashboard. The Compiler confirms that prerequisite modules are complete, and launches the Assembler module to generate the programming files that you specify. The Messages window dynamically displays processing information, warnings, or errors. After Assembler processing,

After running the Assembler, the Compilation report provides detailed information about programming file generation, including programming file Summary and Encrypted IP information.

Figure 60. Assembler Reports

Figure 61. Device & Pin Options

Synthesis Language Support

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

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)

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.

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 62. Verilog HDL Input Settings Dialog Box

Table 17. 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.

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.

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.

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.

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

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

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.

VHDL Input Settings (Settings Dialog Box)

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

Table 18. 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 63. VHDL Input Settings Dialog Box

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.

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;

Synthesis Settings Reference

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

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.

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 19. 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.

Allow Register Retiming

The Allow Register Retiming option 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|”

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 20. 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: Not available for Intel^® Stratix^® 10 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: Not available for Intel^® Stratix^® 10 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 21. 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 22. 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 23. 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 24. 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 25. 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 26. 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 27. 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 28. 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: Not available for Intel^® Stratix^® 10 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 29. 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 30. 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 31. 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 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 32. 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

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 33. 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: Not available for Intel^® Stratix^® 10 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: Not available for Intel^® Stratix^® 10 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: Not available for Intel^® Stratix^® 10 devices.

Table 34. 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: Not available for Intel^® Stratix^® 10 devices.

Table 35. 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: Available only for Intel^® Stratix^® 10 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 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 36. 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: Not available for Intel^® Stratix^® 10 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: Not available for Intel^® Stratix^® 10 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 37. 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 38. 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: Not available for Intel^® Stratix^® 10 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 39. 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: Not available for Intel^® Stratix^® 10 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 40. 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.

Design Compilation Revision History

This document has the following revision history.

Document Version	Intel^® Quartus^® Prime Version	Changes
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."
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.0	Described dependency of Rapid Recompile on Enable Intermediate Fitter Snapshots option.
2018.09.24	18.1.0	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.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 41. 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.

Reducing Compilation Time

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

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.

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

Running Rapid Recompile

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

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.

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.

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.

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 is available only for Intel^® Stratix^® 10 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.

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:

To view registers with defined power-up states that cannot be preserved, refer to the Registers with Explicit Power-up Settings dialog, as shown in the following image:

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

Reducing Compilation Time Revision History

Document Version	Intel^® Quartus^® Prime Version	Changes
2019.07.02	19.1	Added the Using the No-Register Initialization Flow topic.
2018.10.19	18.1.0	Described dependency of Rapid Recompile on Enable Intermediate Fitter Snapshots option.
2017.11.06	17.1.0	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.

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.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

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.