Xilinx “map” tool trimming just a little too much

This post was written by eli on January 23, 2013
Posted Under: FPGA,Zynq

Sometimes, in particular when working on a relatively new Xilinx device family, the “map” tool fails on several errors like

ERROR:MapLib:979 - LUT5 symbol
R_201_o_inv1" (output
en_d_OR_201_o_inv) has input signal
"project/project_core/module/module_almostfull_d" which will
be trimmed. See Section 5 of the Map Report File for details about why the
input signal will become undriven

The first thing to say about this, is that it’s a bug in Xilinx’ tools. Sooner or later, Xilinx will announce that it has been fixed, and ask people to upgrade to recent versions (like in this case).

What the message says is more or less

Hi, this is the mapper. I was too eager to throw away logic which I thought was useless, but oops, it turns out I need this piece of logic after all. Please look in Section 5, and try to figure out why I made this mistake.

My own experience with solving this problem is that there is no quick fix. No flag to add or anything like that. The trick is to find what provoked the mapper into removing logic eagerly (usually whole blocks of logic) and accidentally remove a few elements too much. Look in section 5 for the signal that was trimmed (called “input signal” in the error message), and try to spot what triggered off the logic removal. It’s usually a significant chunk of logic (a functional block) which is effectively useless, because it’s fed with constant signals. A very possible reason for this is that those signals aren’t even connected in the module’s instantiation, so they are all held constant zero. So the mapper rightfully removes this dead weight. Just a bit too much.

Another thing to mention in this context, is that this problem always occurs with black-box logic in the design, that is, IP cores (e.g. FIFOs) and other logic blocks that are included as netlists to the project (as opposed to HDL sources). Dead logic is optimized out by the synthesizer when possible, so the only reason for dead logic in the mapping stage is that it came from different netlists.

So the exact thing to look for is an IP core or another black box that was instantiated with some of its ports either constant or ignored, causing significant parts of it turning into dead logic.

And finally, let’s say this again: This is a bug in Xilinx’ tools, and one of the reasons why working with new device families is a bit difficult. There is no excuse for failing a build because some of the logic is unused.

Add a Comment

required, use real name
required, will not be published
optional, your blog address