Synthesis Optimization Results Reports

Synthesis generates reports to display the following information based on specifying optimization settings in the Compiler Settings page or the Assignment Editor.

The Register Statistics folder

Multiplexer Statistics folder

The Netlist Optimization folder

Removed Registers Triggering Further Register Optimizations

Reports information about registers removed during synthesis which result in the removal of other registers, including the register name, the reason for removal, and any additional registers removed because of the removal of the original register. Registers that cause the optimization of other registers are listed in descending order, by the number of other registers they caused to be removed.

Registers Protected by Syn_Preserve, Dont_Touch Report

Reports information about registers protected by the syn_preserve or other Verilog or VHDL synthesis attributes. Equivalent assignments that preserve registers, or assignments specifying netlist optimizations are never allowed. The report includes the Register Name, and values for Status, Protected by Syn_Preserve, and Not to be Touched by Netlist Optimization settings.

Registers Duplicated to Honor Syn_Maxfan Report

Reports information about registers duplicated during optimization by the max_fanout or other Verilog or VHDL synthesis attributes. The report includes the Register Name, MAX_FANOUT Requirement, and the resulting Number of duplicate registers.

General Register Statistics Report

Reports information about general register usage including the total registers, number of registers using synchronous clear, synchronous load, asynchronous clear, asynchronous load, clock enable, and preset.

Registers Added for RAM Pass-Through Report

Reports the Register Name and RAM Name of registers that required added pass-through logic.

Registers Packed Into Inferred Megafunctions Report

Reports the registers packed into megafunctions including the Register Name, Megafunction, and Type of megafunction inferred. Types include RAM, DSP, and Shift Register.

Logic Cells Representing Combinational Loops Report

Reports combinational loops encountered by Quartus® Prime Synthesis and represents each loop as a logic cell Definition.

The following is an example of Verilog HDL source code where a combinational loop is detected:

 module top (ina, inb, out); 
input ina, inb; 
output out; 
assign out = (out & ina) | inb; 
endmodule

A combinational loop exists since the output pin out feeds itself through other combinational logic.

Combinational loops can lead to various problems in the design, including glitches and unstable or incorrect results. Combination loops can also make timing analysis cause glitches, unstable or incorrect results, make timing analysis difficult, and generally affect the stability and reliability of the design.

The Quartus® Prime software might recognize some combinational loops as latches. Combinational loops recognized as latches are not listed in the Logic Cells Representing Combinational Loops report; they are listed in the Synthesis Optimization Results folder.

Note: Not all logic cells and latches listed may be present at the end of synthesis due to various synthesis optimizations.

User-Specified and Inferred Latches Report

Reports latches generated in a design, the latch name, latch enable signal, whether or not the latch presents a timing hazard, and the total number of user-specified and inferred latches.

A latch may be generated in a design for the following reasons:

  • A latch is explicitly implemented using the appropriate primitive or the lpm_latch megafunction:
    module my_latch(in, enable, clr, out);
    input in; 
    input enable, clr; 
    output out; 
    reg out; 
    always@(in or enable or clr); 
    begin if (clr) out = 1'b0; 
    else if (enable) out = in;  // When "enable" is true, "out" is assigned the value of "in" 
                                // when "enable" is false, "out" retains its previous value! This is a latch. 
    end;
    endmodule;
  • A latch is inferred in HDL source code as in this example where a latch is inferred as a result of incompletely specified code:
    module my_latch3(data_a, data_b, data_c, select, clr, out);
    input data_a, data_b, data_c; 
    input [1:0] select; input clr; 
    output out; 
    reg out; 
    always@(data_a or data_b or data_c or select or clr) 
    begin if (clr) out = 1'b0; 
    else case (select) 2'b00 : out = data_a; 2'b01 : out = data_b; 2'b10 : out = data_c;  // out is not assigned when select = 2'b11 
                                                                                          // out retains its previous value! This is a latch. 
    endcase; 
    end; 
    endmodule;

Intel recommends that you only use latches when explicitly required in the design, and not as a result of incompletely specified HDL. Intel also recommends replacing latches, when possible, with registers. Register timing can be analyzed more accurately, and registers are not susceptible to glitches and can be simulated more easily than latches.

A design may also contain combinational loops that are not recognized by the Quartus® Prime software as latches. These loops are not listed in the User-Specified and Inferred Latches report, but are reported in the Logic Cells Representing Combinational Loops report in the Synthesis Optimization Results folder.

Note: Not all latches listed may be present at the end of synthesis due to various synthesis optimizations.

Gated Clock Conversion Details Report

Reports the results of gated clock conversion including the gated clock name, the base clock, whether or not the gated clock logic was converted to use the clock enable input port of the target register or registers, and the reason for conversion failure, if any.

Multiplexer Restructuring Statistics Report

Reports information about the Restructure Multiplexers logic option, which is an optimization technique for reducing the number of logic elements required to implement multiplexers.

Multiplexer Restructuring applies to entire hierarchical trees of multiplexers. Multiplexers may appear in different parts of the design through VHDL or Verilog HDL constructs, such as <if>, <case>, or <?>.

When multiplexers from one part of the design feed multiplexers in another part of the design, hierarchical trees of multiplexers are formed. Multiplexer Restructuring identifies buses of multiplexer trees that have a similar structure. Multiplexer buses occur most often as a result of combining vectors in Verilog, or STD_LOGIC_VECTORS in VHDL. When turned on, the Restructure Multiplexers logic option optimizes the structure of each multiplexer bus, taking advantage of the features in the target device so as to reduce the overall number of Logic Elements used. Area reductions as high as 20% are possible.

Multiplexer Restructuring is controlled from the Analysis & Synthesis Settings page. The default setting is auto, which means that Multiplexer Restructuring only takes place if the Optimization Technique is set to area or balanced. No restructuring takes place if the Optimization Technique is set to speed because in some cases, the clock speed of the design may be negatively affected.

Information for each bus of multiplexers is provided in the Multiplexer Restructuring Statistics report as follows:

  • Multiplexer Inputs shows the number of data inputs to the multiplexer. For example, you would see 10:1 for a 10-to-1 multiplexer.
  • Bus Width shows the width, in bits, of the bus.
  • Baseline Size shows an estimate of how many logic elements are needed to implement the bus of multiplexers being described by the table row before any Multiplexer Restructuring takes place. This estimate can be used to highlight any large multiplexers in the design.
  • Size if Restructured shows an estimate of how many logic elements are needed to implement the bus of multiplexers, if Multiplexer Restructuring is applied.
  • Saving if Restructured shows an estimate of how many logic elements are saved if Multiplexer Restructuring is applied.
  • Registered shows whether registers are present on the multiplexer outputs. Multiplexer Restructuring makes use of the additional features of a register (such as synchronous clear and synchronous load signals) to further reduce the number of logic elements needed to implement the bus of multiplexers.
  • Example Multiplexer Output shows the name of one of the outputs of the multiplexers in the bus. This name can help determine from which part of the design the multiplexer bus originated.

Physical Synthesis Netlist Optimization Report

Reports the following results of optimization of the physical synthesis netlist during Synthesis:

  • Node shows the node being optimized.
  • Action shows the type of optimization that occurred.
  • Reason shows the reason for the optimization action taken.

Gate-Level Report

Reports information about the registers created or deleted during retiming of the design and displays the following information:

  • Register Name shows the name of the register created or deleted during retiming.
  • Clock Name shows the clock name for the domain from which the register was created or deleted.
  • Created/Deleted shows whether the register was created or deleted during retiming.