PL_TARGET_DENSITY

Section 4.5 starts with two config knobs, two modules apart, both about how full the core is. It is easy to assume FP_CORE_UTIL from Module 3 and PL_TARGET_DENSITY here in Module 4 are the same setting under two names, and easy to be wrong about that in a way that causes real problems.

Two different questions

FP_CORE_UTIL, set during floorplanning, answers a sizing question. Given the total area of every standard cell in the netlist, how big does the core need to be so that cells occupy roughly this fraction of it? It is one number for the whole design, used once, to compute the core’s physical dimensions. Module 3 covered the arithmetic: core area = total cell area / target utilisation.

PL_TARGET_DENSITY, used during placement, answers a different question. As RePlAce spreads cells across that already fixed core, how full should it allow each local region, each density bin from Section 4.1, to get? It is not a sizing decision. The core’s dimensions are locked from Module 3. It is an optimisation target that shapes how tightly RePlAce is willing to pack cells locally before its density repulsion pushes back.

Why PL_TARGET_DENSITY is usually higher than FP_CORE_UTIL

Here is the part that trips people up. If FP_CORE_UTIL was 45 and you set PL_TARGET_DENSITY to 0.45 expecting a matching, tight setting, RePlAce has almost no slack. Every bin is being asked to hit almost exactly the design’s global average, which leaves the optimiser very little room to push cells around locally in the service of shorter wires, and no spare local capacity for anything added later. Buffer insertion during CTS in Module 5 needs somewhere to put new cells without immediately blowing past density in already packed regions.

A common convention, a starting heuristic rather than a rule, is to set PL_TARGET_DENSITY about 0.10 to 0.15 above FP_CORE_UTIL expressed as a fraction. For alu8’s FP_CORE_UTIL = 45:

$$\text{PL_TARGET_DENSITY} \approx \frac{45}{100} + 0.10 = 0.55$$

That 0.10 is not arbitrary padding. It is deliberately reserved headroom, giving RePlAce room to breathe locally and leaving slack for cells that arrive after placement, clock buffers, hold-fix cells, spare cells, without forcing a fight over density in every bin.

Setting PL_TARGET_DENSITY numerically equal to FP_CORE_UTIL / 100 compiles, runs, and is usually a mistake. You have removed exactly the headroom this knob exists to provide, and you will rediscover the problem later as unexplained congestion or a rough time inserting CTS buffers. Notice also the direction of the relationship: the density target should be higher than the floorplan utilisation, never lower. Setting it noticeably lower, say 0.30 against a 0.45 FP_CORE_UTIL, forces RePlAce to spread cells more sparsely than the core’s average requires. That sounds safe but wastes wirelength and creates its own oddities, since cells that need to be close get pushed further apart than the netlist would prefer.

Computing a candidate

A different design was floorplanned with FP_CORE_UTIL = 60. Using the same 0.10 margin:

$$\frac{60}{100} + 0.10 = 0.70$$

A starting candidate of 0.70. Whether that is the right final value is a different question, one that needs an actual placement run with the congestion and timing checks, which is exactly the discipline the next article names.

Practice Exercise

Two engineers working on the same design with FP_CORE_UTIL = 50 propose PL_TARGET_DENSITY values of 0.51 and 0.90. In one sentence each, what is likely to go wrong with each choice?

Choosing a starting PL_TARGET_DENSITY is an educated guess. Turning it into a good final value is a loop, not a single decision, and naming that loop explicitly is the next article’s entire job.