Re: The mapper is getting rid of all my logic!!

John,

My favorite is when you forget to have an output pin to your logic, and it just optimizes everything away.

Aust> This typically happens when output signals from a logic block are not

It can also happen if a) the clock signal to your output flip-flops is unconnected somehow or (more common) b) the enable signal to these flip-flops is stuck low for some reason.

This is true and the trim report in the .mrp file can sometimes be misleading about where the trimming originated. I use the following iterative process to debug unexpected trimming behavior:

1. Pick an instance (usually a FF) from the logical design that is being trimmed unexpectedly and apply an "S" property to all input/output nets.
2. Rerun map and examine the resulting NCD in FPGA Editor. Note which inputs/ouputs are undriven/unloaded or optimized to constants and what affect this would have on the trimmed logic. This should identify the direction that the trimming is coming from. For example, the CE input may be GND.
3. Once the direction of the trimming has been identified. apply more "S" properties on the logic in that direction and repeat step 2. Continue until the source of the trimming has been identified.

Other tips:

If you suspect that a FF is never going high, try applying an INIT=1 property to it as a test. Does the trimming behavior change?

If you reach a point where the "S" properties don't successfully block some trimming, this is a sign that the logic is being removed due to optimization. Usually one or more of the inputs has been optimized to a constant.

Bret Wade Xilinx Product Applications

snipping

While a large block is incomplete, it often has far more IOs than can fit in a package you might be targeting.

Instead I run a scan in chain on one side for all inputs and another on the other side to collect outputs. The top level block now only has ck, scanin, scan out, fits in every package but does use quite a few FFs which I subtract from the synth report. Since the 2 scan chains can be ucf'ed, they can also bring their signals close enough to where needed in a final floorplan so that they don't contribute any real delay to the proto design when you try to get PR timing.

The only issue this brings up is lots of false warnings that FFx (in scan chain) is same as FFx+1 (in my pipeline) and so on, but these are safe to ignore since I already know that. Once the logic loop is closed, the scan chain falls away quickly leaving the final design.

Before I did this, I often lost the whole design too, except a few inputs!

Kinda of pulling up oneself by bootstraps.

regards

johnjakson_usa_com

Thank you all for your replies.

I have tried debugging mi design using simple AND and OR gates, and what I found is that all my LUTs are being optimized!!

So I did a simple design, one 2 4-input LUTs, one and gate, 8 inputs and 1 output.The LUTs are initialized with different numbers. All gets optimized away. Obviously, it works if I only have other components, such as gates.

Anyone has any idea what's going on? Thanks

The OP provided me with a test case and the problem turns out to be that the INIT values on the LUTs were not being passed to the implementation tools correctly. The values were being passed as "00" and the LUTs were being optimized to GND.

This is known problem with XST generating VHDL from XCS schematics. It's fixed already for 6.2i SP2. Meanwhile a work around is to specify a Verilog flow. In ISE Project Properties, set "Generated Simulation Language" to Verilog. See Answer 18350 for details of the issue:

Bret

BrakePist> Thank you all for your replies.