Tcl · Module 23

Floorplan Automation

A floorplan command will happily create a die too small for the design it has to hold. The numbers that say so are arithmetic, and checking them costs nothing.

Intermediate16 min readtcledapart-iiphysical-designfloorplanutilisation

Part II · Module 23 · Chapter 23.1 · Floorplan Automation

Physical design turns a netlist into geometry, and the floorplan is the first decision: how big the die is, where the core sits, where the I/O goes.

Every step in this module shares one property, which is why the module exists in this form: a physical-design command succeeds on inputs that cannot work. So each step needs a report that proves it did what the script asked. This chapter establishes the pattern on the cheapest step.

1. What the floorplan fixes

Three things, and everything downstream depends on them:

The die size — the outer boundary.
The core area — the region cells are placed in, inside a margin left for I/O and seal ring.
Where the I/O sits, which decides where signals enter and therefore which paths are long.

2. Scripting it

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

create_floorplan -die_width 1000 -die_height 1000 -core_margin 50

Command names and options differ by vendor; find yours in the reference (Chapter 17.6). What is consistent is that the parameters are numbers, which means they can be computed, checked and recorded — Part I work on the quantities the command was given.

3. The numbers it implies

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

puts [format "    die area       : %.0f" [die_area]]
puts [format "    core area      : %.0f" [core_area]]
puts [format "    cell area      : %.0f" $::pd::cell_area]
puts [format "    utilisation    : %.1f%%" [utilisation]]
puts [format "    aspect ratio   : %.2f" [aspect_ratio]]

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

=== floorplan, and the numbers it implies ===
    die area       : 1000000
    core area      : 810000
    cell area      : 486000
    utilisation    : 60.0%
    aspect ratio   : 1.00

Two derived quantities matter more than the raw sizes:

Utilisation — cell area divided by core area. How full the core is before placement starts.
Aspect ratio — core width divided by height.

Both are division. Neither needs a tool to compute, which means both can be checked before anything expensive happens.

4. Deriving the die instead of guessing

§3 computed utilisation from a die size. The more useful direction is the other one: the cell area is a fact about the design, the target utilisation is a flow decision — so the die size can be solved for rather than guessed and corrected.

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

proc die_for_target {cell_area target_pct margin} {
    if {$target_pct <= 0 || $target_pct >= 100} {
        error "target utilisation must be between 0 and 100, got $target_pct" {} {PD BADTARGET}
    }
    set core_area [expr {100.0 * $cell_area / $target_pct}]
    set core_side [expr {sqrt($core_area)}]
    return [expr {ceil($core_side + 2.0 * $margin)}]
}

Three lines of arithmetic, run in both directions to check they agree:

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

=== derive the die instead of guessing ===
    cell area      : 486000
    target util    : 60.0%
    core margin    : 50
    derived side   : 1000
    achieved util  : 60.0%
    aspect ratio   : 1.00

The die comes back as 1000, the hard-coded value from §2 — which is the point: that number was never arbitrary, it was this calculation done once by hand and then frozen into the script. Writing the calculation down instead means it stays correct when the design grows.

Change the target and the die follows:

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

=== the same design at a tighter target ===
    derived side   : 880
    achieved util  : 79.9%

The guard is the other half:

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

=== an impossible target is refused ===
    1 / target utilisation must be between 0 and 100, got 100.0

A target of 100% asks for a core exactly the size of the cells, with no space for a single wire; a target of 0 divides by zero. Neither is a typo anyone makes twice, and both produce a number the rest of the script would use without complaint — so the procedure refuses them at the point where the mistake is still legible. That is Chapter 14.11's argument about validating an argument where it is understood rather than where it explodes.

Note sqrt assumes a square core. A real derivation takes the target aspect ratio as a parameter too, and a block with a fixed edge — against a die boundary, or beside a hard macro — has one dimension given and solves for the other.

5. The floorplan that cannot work

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

=== a floorplan that is too small for the design ===
    core area      : 435600
    utilisation    : 111.6%  <- too high to place and route

A bad shape fails differently and just as quietly:

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

=== and one with a bad aspect ratio ===
    aspect ratio   : 5.75  <- long and thin
    utilisation    : 52.8%

Utilisation is comfortable. The core is nearly six times wider than it is tall, so any path crossing it is long, routing resources in one direction are scarce, and the clock tree has to span a shape it was not designed for. Placement will run and produce a result that times badly for reasons that are not visible in the netlist.

6. The check

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

proc check_floorplan {min_util max_util min_ar max_ar} {
    set problems 0
    set u [utilisation] ; set a [aspect_ratio]
    if {$u > $max_util} {
        puts stderr [format "  ERROR   utilisation %.1f%% is above the %.0f%% limit" $u $max_util] ; incr problems
    } elseif {$u < $min_util} {
        puts stderr [format "  WARNING utilisation %.1f%% is below %.0f%% — the die may be larger than needed" $u $min_util]
    } else {
        puts [format "  ok      utilisation %.1f%%" $u]
    }
    if {$a > $max_ar || $a < $min_ar} {
        puts stderr [format "  ERROR   aspect ratio %.2f is outside %.2f..%.2f" $a $min_ar $max_ar] ; incr problems
    } else {
        puts [format "  ok      aspect ratio %.2f" $a]
    }
    return $problems
}

Across four dies:

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

  --- die 1000x1000
  ok      utilisation 60.0%
  ok      aspect ratio 1.00
      0 problem(s)
  --- die 760x760
  ERROR   utilisation 111.6% is above the 85% limit
  ok      aspect ratio 1.00
      1 problem(s)
  --- die 2400x500
  ok      utilisation 52.8%
  ERROR   aspect ratio 5.75 is outside 0.50..2.00
      1 problem(s)
  --- die 1600x1600
  WARNING utilisation 21.6% is below 50% — the die may be larger than needed
  ok      aspect ratio 1.00
      0 problem(s)

Four floorplans, four different verdicts, and the procedure is the shape from Chapter 22.9 §4: errors for what cannot work, a warning for what is merely questionable.

A die that is too large is wasteful, not broken — and making it an error would get the check switched off, which is exactly the failure mode that chapter described.

7. Where the limits come from

The numbers in check_floorplan are not universal, and inventing them would be worse than useless.

Utilisation limits come from the technology, the design style and how much the tool will need to add later — buffers, clock tree, spare cells. A design routed at a density that was fine five years ago may not route now. Take the number from your flow's own guidance, not from a tutorial.

Aspect ratio limits come from the block's role and the surrounding floorplan. A near-square core is the easy default; a long thin block may be exactly right if it sits along an edge.

What matters is that the limits are stated in the script, so the check is a decision somebody made rather than a judgement applied inconsistently — the same argument as Chapter 22.7 §6's acceptable-slack threshold.

8. Check before the expensive step

The ordering argument from Chapter 21.7 §6, applied here.

Floorplan creation takes seconds; placement takes a long time. A floorplan check costs microseconds — it is division — and it prevents a placement run on geometry that cannot succeed.

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

create_floorplan -die_width $W -die_height $H -core_margin $M
if {[check_floorplan 50 85 0.5 2.0] > 0} {
    error "floorplan is not usable" {} {PD BADFP}
}
place_design                              ;# only now

Three lines between the two, and they are the difference between a failure in the first second and a failure after an hour.

9. Exercises

Exercise 1. What three things does the floorplan fix?

Exercise 2. How are utilisation and aspect ratio computed?

Exercise 3. Why derive the die size from the cell area and a target rather than hard-code it?

Exercise 4. The derived die achieves 79.9% against an 80% target. Why is that the right direction to miss by?

Exercise 5. Why does die_for_target refuse a target of 100%?

Exercise 6. Utilisation is 111.6% and the command succeeded. What does that tell you about physical-design commands generally?

Exercise 7. The aspect-ratio case had comfortable utilisation. Why is it still a problem?

Exercise 8. Why is a too-large die a warning rather than an error?

Exercise 9. Why should the limits live in the script rather than in somebody's judgement?

Exercise 10. Why check the floorplan before placement rather than after?

Answers.

1. The die size, the core area inside the margin, and where the I/O sits — which decides which paths are long.

2. Utilisation is cell area divided by core area; aspect ratio is core width divided by core height. Both are division, computable without a tool.

3. Because the cell area is a fact about the design and the target is a flow decision, so the size is a calculation. Hard-coding it freezes one hand calculation into the script and silently goes stale as the design grows — the derived value came out as exactly the 1000 that had been hard-coded.

4. Because utilisation is a ceiling to stay under, not a value to hit. ceil makes the core slightly roomier and the achieved utilisation slightly lower, so the arithmetic can never push a die over the limit by a rounding unit. Rounding the other way eventually would, on one design out of twenty.

5. Because 100% asks for a core exactly the size of the cells, with no room for a wire, and 0 divides by zero. Both produce numbers the rest of the script would use without complaint, so they are refused where the mistake is still legible.

6. That they succeed on inputs that cannot work. The command was asked for a die of a given size and made one; whether the design fits was not the question it was asked.

7. Because a core nearly six times wider than tall makes every crossing path long, leaves routing resources unbalanced, and gives the clock tree a shape it was not planned for. Placement runs and times badly for reasons invisible in the netlist.

8. Because it is wasteful rather than broken, and a check that errors on everything gets switched off — and then stops catching the cases that cannot work.

9. So the check is a decision somebody made and can review, rather than a judgement applied differently each time.

10. Because the check costs microseconds and placement costs a long time, so a doomed run stops in the first second.

Remember.

Physical-design commands succeed on inputs that cannot work — so every step needs a report proving it did what was asked.
The floorplan fixes die size, core area and I/O position.
Utilisation and aspect ratio are division — computable and checkable without a tool.
Solve for the die size from the cell area and a target instead of hard-coding it, and round so the arithmetic fails safe (ceil undershoots the target, which is the direction that cannot break the limit).
Refuse an impossible target where it is given, not where the resulting number explodes.
Utilisation above 100% is possible and the command still succeeds.
A bad aspect ratio passes the utilisation check and produces a design that times badly for invisible reasons.
Errors for what cannot work, warnings for what is merely wasteful — or the check gets switched off.
Take the limits from your flow's guidance, and state them in the script.
Check before placement. Microseconds against hours.

Where this fits

Part of the Tcl curriculum.