We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

AR# 23990

11.1 MAP - Master Answer Record for MAP Trimming Issues


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[6]" (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[6]" (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[5]" (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[0]" (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:

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

  2. Run MAP and PAR on the design (disable routing to save time) and load the placed NCD file in FPGA Editor.
  3. 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.
  4. 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.
  5. 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 ;


Links to Answer Records for specific known trimming and optimization problems:

(Xilinx Answer 20350) - Removed Logic Summary is misleading about the source of logic trimming

(Xilinx Answer 17765) - A change in the functionality of the MAP "-u" switch that disables logic trimming

(Xilinx Answer 30112) - New SAVE behavior in 10.1

(Xilinx Answer 31574) - Lack of trimming on DCM_ADV output signals leads to "ERROR:PhysDesignRules:1577 - Illegal routing"

(Xilinx Answer 33743) - Change in trimming behavior for IBUFDS_GTXE1 components in 11.3

(Xilinx Answer 34352) - Optimization of LUT6_2 inputs mishandled leading to trimming errors
AR# 23990
Date 03/06/2013
Status Active
Type Known Issues
  • ISE - 10.1
  • ISE Design Suite - 11.1
  • ISE Design Suite - 11.2
  • More
  • ISE Design Suite - 11.3
  • ISE Design Suite - 11.4
  • ISE Design Suite - 11.5
  • ISE Design Suite - 12.1
  • ISE Design Suite - 12.2
  • Less
Page Bookmarked