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

This typically happens when output signals from a logic block are not connected (though a typo or some other unintended reason) ... as MAP works backwards it trims away.

To find the offending path, either use a simulator (highly recommended), or add some "debug only signals" .... which are the OR of all output signals from a suspected block .... whose output is brought to a top level I/O. If this small logic addition suddenly adds large amounts of previously trimmed logic, then you know that the downstream signals are being optimized away.

Good luck.

--
Regards,
John Retta
 Click to see the full signature
Reply to
John Retta
Loading thread data ...

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

Reply to
Austin Lesea

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.

--
Pierre-Olivier

-- to email me directly, remove all _N0SP4M_ from my address --
Reply to
PO Laprise

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

Reply to
Bret Wade

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

Reply to
john jakson

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

Reply to
BrakePiston

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:

formatting link

Bret

BrakePist> Thank you all for your replies.

Reply to
Bret Wade

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.