Synplicity and the Xilinx MAP Memory Monster

I have a design which uses around 80% of an XC5V330. Synthesis to EDIF is via Synplicity and it's pretty quick.

MAP is another story. It takes around six hours and uses upwards of

6GByte (not a typo) of memory. Actually MAP claims to have used 6GB, but Linux/LSF reports that MAP has used 12GB. The machine has 16GB installed.

Since the Synplicity EDIF is essentially a bunch of LUT definitions, I cannot see what MAP could be doing that needs this immense slug of memory and time. The target speed is 20MHz, which is DC on an XC5V part, and Synplicity believes it has achieved it. Are there any hints and tips out there for switches or whatever that could cut the processing resources?

For the future, Smartguide looks good. But first the design has to be stable.

Reply to
Tim (one of many)
Loading thread data ...

For XC5, MAP also (by default) performs the placement part of PAR, see "timing driven placement".

This has been optional but not very useful on previous logic families, but my limited V5 experience suggests that for Virtex-5, "timing driven placement" at the MAP phase yields huge benefits over the traditional placement phase during PAR. I've no idea why it makes such a difference with V5, but apparently not with previous families.

So while MAP takes a long time; PAR will be faster to compensate.

One ProjNav bug in 9.2: if you want to change the constraint table entry because you just missed timing, be aware that MAP now has its own constraint table entry; change them both and keep them in step! Otherwise MAP will run for 6 hours, then PAR (seeing a different seed) will throw away the (good) placement and take 6 more hours to create its own (terrible) one!

This makes MPPR singularly useless under these circumstances; another good reason to script/batch your own...

- Brian

Reply to
Brian Drummond

I've had some instances in the past where mistakes in my code (mistakes from the perspective of my intent, not syntax errors) have sent the mapper phase of the Synplify compile into an uncharacteristically long phase.

If you had been running fine but suddenly hit a wall, look for the changes you made that brought on the 6 hour mapping phase that produces your EDIF so slowly.

My recollection of one problem was the inference of a memory that wasn't integrating nicely into the Xilinx primitive; I ended up with thousands of registers in its place. While thousands of registers shouldn't bring on a long map phase themselves, there was something very strange about the way I inferred the memories that seemed to get the map phase of the synthesis bound up in a knot.

It's probable the good folks at the Synplicity hotline can run your code through the synthesizer and - with performance monitors the developers use - determine what aspect of the code is crunching all that time.

- John_H

Reply to
John_H

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.