This Answer Record is intended to cover all aspects of trimming and optimization during MAP.
What is logic trimming?
Logic trimming is the removal of logic that is unused because it has no driver, no load, or no effect on any chip outputs. For example, a state machine whose outputs are used only as feedback to its inputs can be removed without affecting the operation of the design.
What is constant optimization?
Constant optimization occurs when logic is removed or modified due to a constant input signal. For example, if a flip-flop is driving a LUT input, where the flip-flop data input is GND, INIT=0, and there is no Reset, the flip-flop can be removed and replaced with a constant GND. The LUT input can in turn be removed and the LUT equation simplified.
Section 4 of the MAP report (.mrp) is a summary of removed logic. Section 5 is a detailed list of removed logic.
What are the known problem areas for trimming and optimization?
- Valid trimming of unused logic - The most common reason for valid trimming is that a net has no driver or load and so it is unused, or a logical block is undriven or unloaded and so it is unused. This results in a cascade of trimming as the next element in the path becomes undriven or unloaded. The Removed Logic section (the trim report), "Section 5" of the MAP report (.mrp), attempts to track the sequence of trimming events by indenting a line if it is dependent on a previous line. An unindented line can be considered a starting point of trimming. This cause-and-effect sequencing is not always accurate. The order is sometimes reversed.
The signal "xyz/trn_rbar_hit_n<6>" is loadless and has been removed.
Loadless block "xyz/com/tlm/u_tlm_rx/vc0/fifo/trn_rbar_hit_i" (BUF) removed.
The signal "xyz/com/tlm/u_tlm_rx/vc0/fifo/trn_rbar_hit<6>" is loadless and has been removed.
Loadless block "xyz/com/tlm/u_tlm_rx/vc0/fifo/bar_d" (FF) removed.
The signal "xyz/trn_rbar_hit_n<5>" is loadless and has been removed.
Loadless block "xyz/com/tlm/u_tlm_rx/vc0/fifo/trn_rbar_hit_i" (BUF) removed.
The signal "xyz/com/tlm/u_tlm_rx/vc0/fifo/trn_rbar_hit<5>" is loadless and has been removed.
- Valid cycle trimming - MAP will correctly trim any logic that feeds back on itself without ever driving anything off-chip, even if every signal has a driver and load. This logic is referred to as a "cycle", and this term may appear in the trimming section of the MAP report (.mrp).
- Invalid trimming of memory feedback paths - Problems have occurred when one Dual Port RAM output feeds back to the data input while the other drives used logic. MAP incorrectly identifies this as a cycle (see above), and trims the RAM and logic driven by the RAM. For more information, including an environment variable work-around, see (Xilinx Answer 23284).
- Valid trimming to LUT inputs - If a path is trimmed to a LUT input, MAP fails with the following errors:
"ERROR:MapLib:820 - LUT2 symbol "b2.rp_3_i_m2" (output signal=rp_3_i_m2(0)) has an equation that uses input pin I0, which no longer has a connected signal. Please ensure that all the pins used in the equation for this LUT have signals that are not trimmed (see trim report for details on which signals were trimmed)."
"ERROR:MapLib:661 - LUT3 symbol "i_vio/vio/i_vio/gen_sync_in/32/sync_in_cell/async_f_mux" (output signal=i_vio/i_vio/gen_sync_in/32/sync_in_cell/async_mux_f_out) has input signal "i_vio/i_vio/gen_sync_in/32/sync_in_cell/falling_out" which will be trimmed. See the trim report for details about why the input signal will become undriven."
"ERROR:MapLib:979 - LUT2 symbol <instance name> has an equation that uses input pin I1 which no longer has a connected signal. Please ensure that all the pins used in the equation for this LUT have signals that are not trimmed (see Section 5 of the Map Report file for details on which signals were trimmed)."
ERROR:MapLib:978 - LUT4 symbol <instance name> has an equation that uses input pin I3, which no longer has a connected signal. Please ensure that all the pins used in the equation for this LUT have signals that are not trimmed (see Section 5 of the Map Report File for details on which signals were trimmed).
These errors occur because simulation is used to perform trimming calculations and it is not valid to simulate an equation with non-existent terms.
- The KEEP attribute does not block trimming - A common misconception is that KEEP properties can be used to block signal trimming. The KEEP property can be used to prevent a signal from being absorbed into a component, but it has no effect on trimming behavior. The correct attribute to block trimming is "S" (AKA Save, SAVESIG, NOCLIP).
- Beginning with ISE version 10.1, the S attribute not only blocks trimming, but also constant optimization. The S property can be applied directly to a logical block, or to a net attached to a logical block to prevent both constant optimization or trimming.
- Pin preassignment blocks trimming - The existence of LOC constraints on unused I/O logic triggers a new feature referred to as "Pin Preassignment". The unused I/O is no longer removed so that designers can work on board layout with only the I/O logic defined. If trimming is desired, LOC constraints should be removed.
- KEEP HIERARCHY - Several trimming issues have been experienced related to KEEP HIERARCHY constraints. Simulation is used to drive trimming behavior, and KH constraints have been known to cause problems with simulations, and therefore, trimming behavior. Try disabling KH (-ignore_keep_hierarchy) during MAP to see if a trimming problem depends on this feature.
- New trimming behavior in 10.1 might cause signals that should be trimmed to not be trimmed; this can lead to a variety of DRC warnings and errors including:
"ERROR:PhysDesignRules:1577 - Illegal routing. The DCM_ADV block <i_srl_top/i_srl_pcix_clk_wrap/i_pci_clk_fpga/DCM_BASE_pci_clk/DCM_ADV> has CLK output pin <CLK90> with incomplete or incorrect connectivity. Routing from the <CLK90> pin to a BUFG, BUFGCTRL or PLL_ADV block type was not found. The DCM_ADV CLK output pins can only route to BUFG, BUFGCTRL or PLL_ADV block types."
- If a design has no output pad connections, the entire design is "unused" and will be trimmed, leading to one of the following MAP Pack errors:
"ERROR:Pack:198 - NCD was not produced. All logic was removed from design. This is usually due to having no input or output PAD connections in the design and no nets or symbols marked as 'SAVE'. You can either add PADs or 'SAVE' attributes to the design, or run 'map -u' to disable logic trimming in the mapper."
"ERROR:Map:116 - The design is empty."
Debugging valid trimming behavior
If a certain trimming behavior is unexpected and the Removed Logic section of the MAP report file does not provide sufficient information, it is possible to use an iterative debugging technique to track down the source of trimming:
- A. Choose a logical instance involved in the unexpected trimming and apply an "S" property to all signals attached to the instance. In the case of the LUT error mentioned in (4) above, it might be necessary to repeat for every failing LUT in the design for the first pass. For example, the following UCF constraints would work for a LUT2 instance:
NET "net_name_1" S ; # I0 input of LUT xyz
NET "net_name_2" S ; # I1 input of LUT xyz
NET "net_name_3" S ; # O output of LUT xyz
- Run MAP and PAR on the design (disable routing to save time) and load the placed NCD file in FPGA Editor.
- Examine the component containing the instance chosen in step A and examine the signal connectivity. One or more of the signals involved will have either no driver or load and is an indication of the source of trimming for this instance. This may contradict the trim report in the ".mrp" file.
- After identifying the signal trimming source, trace through that signal in the logical design to the next instance in the path and repeat step A.
- Continue with this iterative process until the ultimate source of the trimming is reached.
NOTE: If you suspect that a flip-flop is being trimmed because it will never change state, this can be confirmed by changing the INIT value of the flip-flop and noting any change in the trim behavior; this is a diagnostic test, not a work-around. Similarly, the trimming behavior related to a LUT can be tested by changing the LUT INIT state:
INST "ff_name" INIT=1 ;