How to prevent mapper stripping when synthesizing without IO buffers?

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
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<1><6>" 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





Re: How to prevent mapper stripping when synthesizing without IO buffers?
On Sun, 13 Jul 2008 17:21:23 -0700 (PDT), Andrew FPGA

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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

Quoted text here. Click to load it

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

Re: How to prevent mapper stripping when synthesizing without IO buffers?

Quoted text here. Click to load it

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


Quoted text here. Click to load it



Re: How to prevent mapper stripping when synthesizing without IO buffers?
Quoted text here. Click to load it

Check the "-u" option with map.

Cheers,
Jim (jimwu88 NOOOSPAM at yahoo NOOOSPAM dot com)
http://home.comcast.net/%7Ejimwu88/tools /


Re: How to prevent mapper stripping when synthesizing without IO buffers?
Quoted text here. Click to load it
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...

Site Timeline