1. Home
  2. Field-Programmable Gate Arrays
  3. How to prevent mapper stripping when synthesizing without IO buffers?

How to prevent mapper stripping when synthesizing without IO buffers?

Hi, I have designed a VHDL entity that is a subset of the complete design. I have verified its functionality with a simulation in modelsim and now I want to run it through the xilinx synthesis(XST) and place and route tools to verify it meets timing. This entity is a subset of the complete design, and one of its output ports contains a large number of signals(several thousand). This fails to map since our target FPGA does not have several thousand IO pads. How can I run this sub module through the PAR tools to verify I meet timing?

Here is what I have tried so far:

1) IOB over mapping problem solved by unchecking the XST "add I/O buffers" option. However, the mapper rightfully strips the whole design since there are now no inputs or outputs. I have unsuccessfully tried to use the mapper constraint "SAVE NET FLAG". Despite applying this flag to the inputs and outputs of my submodule, everything still gets stripped.

e.g. attribute s: string; attribute s of inputs: signal is "yes";

The map report says: The signal "inputs" is sourceless and has been removed.

I can't understand why the the SAVE NET FLAG constraint is not preserving this signal. Inputs is an array of arrays - perhaps this attribute can't be applied to such a signal ?

Has anyone successfully used SAVE NET FLAG on array of arrays before? What other approaches do folk use to verify timing of a submodule without letting the IOB's affect the result?

(I could create some dummy mux logic to mux the outputs down to a fewer number, so that an achieable number of IOBS are created - But this will distort the timing and logic usage.

Cheers Andrew

Reply to
Andrew FPGA
Loading thread data ...

You can get it through synthesis, and use the synthesis timing estimate as an indicator whether you are on track for timing or not.

IMO there is no point taking it further; the synthesis timing estimates are slightly conservative in my experience (though they may be accurate for a 95% full FPGA) so you stand a good chance of exceeding them in PAR.

On the other hand, PAR results for a block will probably NOT be repeated when the same block is incorporated into the whole design. As you fill up the rest of the FPGA with other stuff, the PAR tools are much more restricted in their ability to find good fast placement and routes. So you may believe your timings are achievable based on PAR in an almost empty FPGA, while in reality they are not, for the entire design.

This is the one. It gets you through synthesis, and that gives you estimated timings above.

You *could* create a wrapper with registers on your unit's ports, and some simple means of combining a thousand pins into a few (e.g. n-way multiplexer, controlled by a few further external pins). You NEED the registers; either 2 levels of registers, or ensure registers are NOT moved into the IOBs, and CHECK the map.mrp report file to make sure that they aren't. Routes from IOBs into the FPGA fabric can be unbelievably slow, so you need registers in the fabric...

Then you have a viable synthesisable unit which can be run through mapping and PAR.

But, as above, beware of trusting the timing results if the final design will be significantly larger. If the synthesis estimates aren't good enough, these probably aren't either.

- Brian

Reply to
Brian Drummond

Check the "-u" option with map.

Cheers, Jim (jimwu88 NOOOSPAM at yahoo NOOOSPAM dot com)

formatting link

Reply to
Jim Wu

The synthesis tool provides a statistical estimate of the delays. Using the mapper option to not strip out unused ports permits accurate measurement of achievable timing, which can be very useful for early identification of problem areas.

JTW

Reply to
jtw

Thanks, I had come across that option but felt it was a bit of a "sledgehammer". Its possible some parts of the design should be stripped - and so if I use that option those parts won't get stripped. The SAVE NET FLAG really should be doing the job, but for some reason it isn't working for me. It seems to work fine when I apply SAVE NET FLAG to a scalar or 1d array. But when I apply it to a signal that is an array of arrays, it only seems to effect the first array element.

I assume its valid VHDL syntax to apply an attribute to an array of arrays? If yes, then its looking like XST doesn't support this properly - at the very least it would be nice if XST warned it couldn't apply the attribute...

Reply to
Andrew FPGA

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.