Pre-placement readiness

6.1 Stage purpose

Placement reads inputs that were prepared earlier and in different places: the macros and physical cells that are already fixed, the restrictions that tell optimisation what it may not use or modify, the blockages that shape where cells may land, the decisions about tie cells, scan chains and spare cells, and the timing environment. A fault in any of them shows up later as a placement problem, and it is then hard to see that the cause was a setting made before placement began. This chapter qualifies those inputs while they are still cheap to change.

Some terms first. An instance is FIXED when its placement status tells placement not to move it. Macros are normally fixed in the floorplan, and end caps and well taps are added with preplaced status, which the tool treats as fixed. Whether dbGet reports those cells as fixed is not verified. A dont_use attribute on a library cell stops optimisation from choosing that cell. A dont_touch attribute on an instance or net stops optimisation from modifying it, but the object can still be moved. A placement blockage is a floorplan object that limits where standard cells may go. A tie cell drives a constant 1 or 0 onto pins that the netlist ties off. A scan chain is the series of flip-flops that test logic connects into a shift register, and a spare gate is a cell that has no function yet and is kept for a later change. Figure 9 shows the physical part of this on one small core.

The two utilisation figures are the point of the drawing. Nothing in the netlist changed between them. Blockages, halos and preplaced cells took sites that the first number still counts. Thus, a floorplan can be legal and on target and still start placement with much less room than the target suggests.

This chapter keeps four ideas apart. Tool completion means a command ended. Analysis coverage means a report examined what you needed it to examine, and an empty report is not a pass. Stage qualification means the evidence meets your project budgets. Signoff is a later stage and is not claimed here. Listings and legality checks are implementation evidence. Timing and congestion numbers taken before any cell is placed are preliminary evidence.

6.2 Entry prerequisites

6.3 Relevant files and analysis context

The inputs come from four places. The floorplan script holds the blockages, halos, fixed macros and the spare gate list. The power script from Chapter 5 holds the physical cells and the connection rules. The libraries carry dont_use and dont_touch attributes of their own. The constraints and the scan DEF come from synthesis and test insertion. The checks read the database in memory, so what they report is what placement will see.

Keep every setting of this chapter in one pre-placement script under version control, and record its revision with the reports. The reference states that the dont_use attribute set with setDontUse persists through save and restore. Whether a restored session keeps the mode commands is not verified, so source the script again before you trust a mode listing. A number without the setting that produced it cannot be compared with a later run, so each card asks you to store the listing beside the report.

Timing is read only by the timing cards. They need the active views from Chapter 3, and they run with ideal clocks and ignored net load, as the next sections explain.

6.4 Checks and command cards

6.4.1 Pre-stage checks

Before you change any pre-placement setting, take a snapshot of what is already placed. It is cheap, and it is the baseline that Chapter 7 compares against. Also confirm that the Chapter 5 evidence is current, because a change to the grid or the physical cells after the last placement-prerequisite check makes that check stale, and R-09 must run again.

dbGet -p top.insts.pStatus fixed
dbGet -p top.insts.pStatus placed
dbGet -p top.insts.pStatus unplaced
dbGet [dbGet -p top.insts.isPhysOnly 1].name

6.4.2 Post-stage checks

The remaining cards look at the setup that placement will run with. Run them after the last change to the inputs, in the order shown, and keep the listings.

report_preserves -dont_use
report_preserves -dont_touch
report_preserves -obj_type inst -dont_touch
dbGet top.insts.isDontTouch 1 -p
get_property [get_lib_cells <lib_cell>] is_dont_use
get_property [get_nets <net>] is_dont_touch

Placement also treats preroutes like routing blockages. By default it honours preroutes and routing blockages on metal2, or on metal2 and metal3 for a process with four or more metal layers, and setPlaceMode -place_detail_preroute_as_obs changes that. The grid from Chapter 5 therefore decides where cells can legally sit, and it belongs in the thinking behind the next card.

writeFPlanScript -fileName <f> -sections {placeBlockages routeBlockages}
checkFPlan -reportUtil -outFile <f>
reportInstPad -all
reportCellPad -file <f>
dbGet top.insts.pHaloBox
getPlaceMode -place_detail_honor_inst_pad -place_detail_pad_fixed_insts

Padding and blockages are also the place to reserve room for later stages. The documentation advises that, when the clock is concentrated in a tight area, you reserve three to five percent of the targeted final utilisation for clock buffers. Take that as guidance for the discussion, and let your project budget decide.

getTieHiLoMode -nonDefault
checkDesign -tieHiLo -noHtml -outfile <f>

report_scan_chain -out_file <f>
scanTrace -verbose
reportScanCell
getScanReorderMode -nonDefault
dbGet [dbGet [dbGet top.insts.cell.name <spare_cell> -p2 ].isSpareGate 1 -p ].name

getPlaceMode -nonDefault
getOptMode -nonDefault
getAnalysisMode -nonDefault

check_timing -verbose > <f>
check_design -type "timing opt" -out_file <f>
timeDesign -prePlace -outDir <dir>

report_route -track_utilization -layer <bottom_layer>:<top_layer>
getDesignMode -congEffort
reportCongestion -hotSpot -overflow
getPlaceMode -place_global_cong_effort -place_global_auto_blockage_in_channel

check_design -type place -out_file <f>
checkPlace <report_file>
checkDesign -place -noHtml -outfile <f>
saveDesign <name>.enc

6.5 Required reports, artefacts and how to read them

checkPlace                                                  ## illustrative excerpt
Begin checking placement ...
Pin Access Violation:          0
*info: Placed = 1441            (Fixed = 1441)
*info: Unplaced = 41600
Placement Density:0.00%(0/62560)
Placement Density (including fixed std cells):2.25%(1440/64000)

The numbers here are illustrative and are not taken from a run. Read the counts first. Every placed instance is also fixed, which is what you expect when the only things placed are the macro, end caps and well taps, and the unplaced count should equal the number of standard cells in the netlist inventory from Chapter 2. If the two differ, some cells were dropped or placed by an earlier step. The first density line is zero, which fits a design whose standard cells are all unplaced. The second line includes fixed standard cells, which here are the end caps and taps, and its denominator is larger by the sites those cells take, so its value is what the preplaced cells alone occupy.

A clean summary is not the whole gate. It shows that the preplaced objects are legal and does not show that the settings behind placement are right, so read it together with the listings from the other cards.

6.6 Healthy, suspicious and hard-stop examples

6.7 Debugging, corrective action and reruns

Faults found here are cheap, because nothing has been placed. Faults found after placement cost a full placement run, and sometimes a rerun of everything that followed. Rerun only the cards that read the thing you changed, and rerun the gate last, because it reads all of them. The table lists the usual changes.

6.7.1 Worked example: tie cells that the tie step is told to avoid

Suppose the team marks its tie cells dont_use so that optimisation never picks them for logic, and a script copied from another project also sets tie insertion to honour dont_use. The two listings below come from R-02 and R-04.

report_preserves -dont_use                                  ## illustrative excerpt
base_cells
------------------------------------------------------------------
base_cell:TIEH_X1
dont_use true
base_cell:TIEL_X1
dont_use true
Total of 2 base_cells constrained

getTieHiLoMode -nonDefault
-cell {{TIEH_X1 TIEL_X1}}
-honorDontUse true      # bool, default=false

Each listing looks reasonable alone. Together they say that tie insertion honours dont_use, and that the only tie cells it was told to use carry dont_use. Nothing fails now, because tie insertion belongs after placement, and that is why the check belongs before it. The decision is HARD STOP. If the intent was to keep optimisation away from the tie cells, reset the honour setting to its default, which lets tie insertion use them. If the tie cells should be avoided everywhere, name different tie cells. Then rerun R-02, R-04 and R-09. The cell names here are illustrative.