Floorplan, macro and pin qualification

4.1 Stage purpose

A floorplan defines the die and core boxes, the standard-cell rows, the macro locations and orientations with their halos, the placement and routing blockages, and the boundary pins. The vocabulary is shown in Figure 6. The die box (the design shape) is the outline of the block. The core box is the area inside it where rows exist and standard cells can be placed. A halo is a keep-out margin around a macro, and a channel is the space left between a macro, or its halo, and a neighbouring macro or the core edge.

Each of these objects can be legal and still be a problem. A channel can be legal and too narrow to route. A pin can be on a legal layer and on the wrong side of the block. Thus, this chapter uses two kinds of evidence: legality checks from the tool, and comparisons against the floorplan specification and project budgets.

4.2 Entry prerequisites

4.3 Relevant files and analysis context

The floorplan comes either from commands in the flow or from an imported floorplan file. Either way, what the checks see is the database in memory. The checks in this chapter are geometric and do not need a timing view, except where pin placement is judged against timing-critical ports.

The behaviour of checkFPlan depends on setFPlanMode -checkTypes: parameters set with setFPlanMode are used automatically whenever checkFPlan runs. The check types include basic, fence, macroPin, color, powerDomain, place, narrowChannel and others, with all selecting every type. The default is basic only. The blockOnly type bundles basic, oddEvenSiteRow, macroPin and color. The macroPin check works only when the block snap rule is LayerTrack, and narrowChannel needs a width threshold in microns. Thus, the setFPlanMode setting must be recorded with the report, because two runs of checkFPlan with different modes check different things, and a default run says nothing about macro pins or channels.

4.4 Checks and command cards

4.4.1 Pre-stage checks

Before the floorplan is built, the only checks are on the inputs: the floorplan specification is the released version, and every macro in the netlist appears in it. The second is easy to automate by comparing the macro list from the specification with the macro instances in your netlist report. The query that lists block instances depends on your database, so confirm attribute names with dbGet top.insts.? before scripting it.

4.4.2 Post-stage checks

dbGet top.fplan.boxes
dbGet top.fplan.coreBox

getFPlanMode -checkTypes
setFPlanMode -checkTypes {blockOnly narrowChannel} -narrowChannelThreshold <w>
checkFPlan -reportUtil -outFile <f>

dbGet -e -p top.insts.pStatus fixed
checkPlace <report_file>
checkPlace -macroBlockage <report_file>
dbGet top.insts.pHaloBox
report_narrow_channel -width <w>

checkPinAssignment -outFile <f>

earlyGlobalRoute
reportCongestion -hotSpot -overflow

check_design -type place -out_file <f>

verifyConnectivity -net {VDD VSS} -type special -noAntenna -report <f>

4.5 Required reports, artefacts and how to read them

reportCongestion -hotSpot -overflow                    ## illustrative excerpt
Overflow: 210 = 7 (0.01% H) + 202 (0.33% V)
[hotspot] Top   hotspot bbox                  hotspot score
[hotspot]   1   310.2 120.5 402.8 260.0       142.00
[hotspot]   2    32.2 262.6 126.5 300.8        31.40

Let us read it against Figure 6. Overflow is small over the whole block, which is why it is the least useful number here. The top hotspot score of 142 is above the tool guidance of 100, and its bounding box, compared with the macro location, falls in the narrow channel to the right of RAM0. A small overall overflow hides a single blocked channel. Thus, the decision follows the hotspot and its location, not the overall figure.

4.6 Healthy, suspicious and hard-stop examples

4.7 Debugging, corrective action and reruns

Floorplan fixes have a wide blast radius. Moving one macro changes channels, congestion, pin access and, later, the power grid. It is prudent to rerun the full chapter after any macro move, rather than only the card that found the problem, because the next problem is usually in the neighbouring channel.

4.7.1 Worked example: a legal floorplan that will not route

Suppose F-02 and F-03 are clean: no violations, utilisation within budget, every macro fixed. The congestion summary above, however, shows the worst hotspot in the channel between RAM0 and the core edge. The halo leaves about a dozen tracks on the routing layers of that channel, while the macro has a row of pins facing it. Every check that tests legality passes, because a narrow channel is legal, while report_narrow_channel with the budget width lists the same channel. With an illustrative budget of 100, the score of 142 exceeds it, so the decision for F-05 is HARD STOP: move the macro to widen the channel or turn it so its pins face open area, then rerun F-02 to F-05. Note that the dozen tracks in this example is illustrative. The real count comes from the routing layer pitch and the channel width of your design.