Phase 15.18 placement optimization

[Andrew Holme]

I'm working on a Virtex 5 project containing a 13-stage pipeline clocked at
200 MHz. The data path gets quite wide in the latter stages; but only 11%
of available slices are used; so the FPGA is relatively empty. Every other
step in the build process rips through quickly, except the above named MAP
stage, which accounts for 98% of total build time. Routing is over in a
flash, and the result meets timing. I would like to reduce the build time
and I was wondering how to go about it. One idea was to create LOC
constraints on logic, perhaps based on where the tools themselves placed it
after a previous optimization run. Any other suggestions?

TIA

 

[Gabor]

On 10/16/2012 3:24 PM, Andrew Holme wrote:

I'm working on a Virtex 5 project containing a 13-stage pipeline clocked
at 200 MHz. The data path gets quite wide in the latter stages; but
only 11% of available slices are used; so the FPGA is relatively empty.
Every other step in the build process rips through quickly, except the
above named MAP stage, which accounts for 98% of total build time.
Routing is over in a flash, and the result meets timing. I would like
to reduce the build time and I was wondering how to go about it. One
idea was to create LOC constraints on logic, perhaps based on where the
tools themselves placed it after a previous optimization run. Any other
suggestions?

TIA

For Virtex 5 and newer parts, Map always places the design as well as

mapping into slices, so "PAR" really only routes. You should expect
map to take the longest time of the processes.

If your pipeline is not hand-optimized and requires register-balancing,
then map may be spending a lot of time on that (physical synthesis), and
using LOC constraints might not help much for execution time. An easy
way to try the LOC idea without a lot of effort is to use "guided"
placement. This normally works best when you make only small mods
to the design between runs. It essentially tries to LOC everything
where it was in the prior "golden" run. The problem is when you make
enough changes that very little of the design keeps its prior instance
names.

-- Gabor