CHAPTER FOUR

Creating a Floorplan: From an Area Estimate to a Boundary

By the end of this chapter you will be able to take the area estimate from Chapter 1 and turn it into a legal floorplan — a die boundary, a core, rows and tracks — using one command that you will run more than once; to say which of the five ways of specifying size is right for the job in front of you; to read every number in the result back out of the tool rather than trusting what you typed; and to refine the floorplan without destroying the work the previous run produced.

Why this chapter matters in a real project

This is the chapter where the design stops being a set of numbers and becomes a shape. Everything after it — block shaping, macro placement, power planning, pin assignment, routing — is done inside the boundary this chapter creates, and every one of those steps is easier or harder because of decisions made here in about four minutes.

The decisions are unglamorous and the consequences are not. A core one utilisation point too tight leaves nowhere for the cells that optimisation has not yet added, and the symptom arrives eight weeks later as congestion nobody can route. A core made long and thin because a ratio was typed the wrong way round lengthens every top-level net that has to cross it. A second run of the same command, launched to try a slightly different size, silently deletes the power routing somebody spent a day on, because nobody read the seven options whose entire purpose is to prevent that. And a floorplan whose rows and tracks were never read back is a floorplan whose numbers exist only in a spreadsheet.

None of these is subtle once you know to look. That is what this chapter is for.

Prerequisites

Chapter 1: die, core and core offset; placement rows and routing tracks; core utilisation and what it counts; the three floorplan styles as a first survey. Chapter 2: how to start a session that configures itself, and why you read a number back before you quote it. Chapter 3: the constraint mapping file and load_block_constraints, both of which reappear here with a different keyword.

Learning objectives

4.1 The beginner's mental model

Start with a plot of land

A plot of land has a boundary, and inside that boundary a smaller area you are allowed to build on. The strip between the two is the set-back, and it is not wasted — it is where the pavement, the drains and the service access go. Inside the buildable area the building rises in floors of a fixed height, stacked from the bottom, and how much of the plot you have used is buildable area divided by plot area.

Every word of that transfers. The die boundary is the plot. The core is the buildable area. The core offset is the set-back, and it is where the I/O, power, ground, corner and filler pad cells go. Standard-cell rows are the floors, and the row height comes from the library exactly as a floor height comes from the structural design rather than from the architect's preference. Core utilisation is built area divided by buildable area — what you place, divided by the core, not the core divided by the die. Buildable divided by plot is a different ratio: how much of the die is core. And the surveyor's grid that everything is measured against is the routing track grid, with the FinFET grid beneath it.

Now the engineering model

A floorplan describes four things: the size of the core; the shape and placement of standard-cell rows and routing channels; standard-cell placement constraints; and the placement of peripheral I/O, power, ground, corner and filler pad cells. That list is worth learning verbatim, because it is also the list of things that a floorplan does not describe — no block shapes, no macro locations, no pins, no power mesh. Those are later chapters, and each of them assumes this one is finished.

One command does the work: initialize_floorplan. It creates a floorplan with a boundary, a core, a site array or rows, and wire tracks. Before it runs, you must have opened a physical design or created one with a netlist reader. After it runs, you refine by running it again.

Figure 4.3 puts all of that on the design this book has been carrying since Chapter 1, with the numbers attached. Read it now for the anatomy — die, core, offset, rows, tracks — and read it again after §4.5, where the same numbers are derived rather than presented.

Do not confuse these

4.2 The concepts, built in dependency order

4.2.1 Three floorplan styles, and what each one costs

Chapter 1 named the three styles. Here they are, properly, because the choice changes what the rest of the chapter has to produce.

Channelled floorplans contain spacing between blocks for the placement of top-level macro cells. The spacing lets the tool place standard cells between blocks. That is the whole idea: a channelled floorplan reserves core area so that top-level logic has somewhere to live.

Abutted floorplans have blocks touching, and the tool does not allocate space for macro cell placement between them. Designs with abutted floorplans do not require top-level optimisation, because all the logic is pushed down into the blocks. The costs are real and they are all downstream: abutted floorplans might require over-the-block routing to meet design requirements; the style requires more attention to clock planning and to feedthrough management; and routing congestion might become an issue. Because of those difficulties, the narrow-channel style is often used instead, to minimise the spacing between blocks rather than eliminate it.

Narrow-channel floorplans provide a balance. You abut certain blocks where top-level cells are not needed, and elsewhere reserve a channel between certain blocks for top-level clock routing or other special-purpose cells.

4.2.2 The library, and why floorplanning starts with an outline

Before a netlist can be read, there has to be somewhere to put it. create_lib creates the design library that will contain the design, with -technology naming the technology file and -ref_libs the reference libraries. If the library already exists, open_lib opens it.

icc2_shell> set libs [glob -directory ${lib_dir} *.ndm]
icc2_shell> create_lib -technology nimbus8.tf -ref_libs $libs \
   nimbus8.dlib

Then the netlist. Chapter 3 required read_verilog, the flat netlist reader, and explicitly forbade the outline reader. This chapter reverses that: to read the Verilog netlist and begin floorplanning, use read_verilog_outline.

icc2_shell> read_verilog_outline -top NIMBUS8 nimbus8.v

The outline reader exists because it processes very large designs efficiently. To conserve resources and minimise turnaround time it creates an outline view of the blocks at the different levels of design hierarchy: the outline design contains hierarchy, but no leaf cells and no nets.

Two consequences follow immediately. First, the outline reader does not partition the design. To partition it you commit the design blocks with commit_block and expand the blocks to their full netlist representations with expand_outline. Second, during early floorplanning you can reduce the tool's disk and memory requirements by saving only hard macros, interface logic, standard-cell area and standard-cell count information. That reduced set is stored in the outline view, and it is sufficient for refining block shapes before floorplan-level placement and pin assignment.

4.2.3 Dense and sparse modules, and the two methods that assign them

On a very large design, blocks should contain the smallest amount of information necessary to perform a meaningful analysis. To support that, the tool separates Verilog modules into two content types. Dense modules retain most of their contents, except buffers and inverters, and support comprehensive data flow analysis. Sparse modules have greatly reduced content, contain only macro cells, and support only the size and interface information needed for connectivity analysis.

Which modules are marked which is decided by one of two methods, chosen with -partition or -allocation on the reader, or by the plan.outline.partition application option. By default, the partition method is used.

In the partition method the tool examines the modules in the hierarchy and determines module density from the target block size and the number of leaf cells in the block. Top-level modules are marked dense until the hierarchical cell count beneath the module is less than a target block size — and buffers and inverters are included in that hierarchical cell count. This keeps connectivity in the top levels of hierarchy, which is where data flow analysis needs it. The target block size is plan.outline.target_block_size, by default 1 000 000 leaf cells, overridable with -target_block_size. After the partitions are designated, small module hierarchies within each partition are also designated dense, to maintain connectivity for data flow analysis; the target number of leaf cells to allocate to those is plan.outline.glue_cell_count, by default 100 000, and a value of −1 avoids marking any of the small modules dense. Buffers and inverters are not represented in the outline design and are not included in that glue cell count.

In the allocation method the tool explores as much of the design hierarchy as possible within a memory budget expressed as a maximum number of leaf cell instances. Modules that exceed a leaf cell count threshold are considered large and are treated as sparse in the outline view; buffers and inverters are again not counted. That threshold is plan.outline.large_threshold, by default 10 000 leaf cells.

Cutting across both methods is the depth control. plan.outline.dense_module_depth specifies the module hierarchy depth that should be marked dense; by default the depth is one and only the top-level module is marked dense. -depth overrides it, and a value of −1 marks all non-sparse modules dense. The hierarchy depth overrides the target cell count.

4.2.4 Five ways to say how big

After the netlist is read, initialize_floorplan defines a floorplan boundary based on your design criteria. You can create a floorplan by specifying the length ratio between the floorplan edges, the length of the core or die edges, the aspect ratio, or the exact width and height. The step uses the outline view for the top-level design.

The five levers, and what each one settles:

Two more options decide what those numbers are measured against. -control_type takes core or die, and core is the default: the dimensions apply to the core boundary and the core offsets are added to reach the die boundary. With die, the dimensions apply to the die boundary and the offsets are subtracted to reach the core. And -macro_utilization specifies the utilisation of the macro cells; its default is the same as the core utilisation value.

-core_offset deserves a sentence of its own because its argument shape changes meaning. One value is used for all sides. Two values give the horizontal distance from the die boundary's vertical edges and the vertical distance from its horizontal edges. More than two are side numbers based on the standard rectilinear numbering — and, importantly, those side numbers do not correlate with the side_a, side_b naming used to size each edge.

# One value: the same offset on every side.
icc2_shell> initialize_floorplan -core_offset 100

# Two values: 50 horizontally, 100 vertically.
icc2_shell> initialize_floorplan -core_utilization 0.8 \
   -core_offset {50 100}

4.2.5 Shapes, and how many numbers each one needs

-shape takes R, L, T or U, and R — rectangular — is the default. The shape decides how many values the sizing option must carry: a rectangle has only two dimensions, width and height, while the L, T and U shapes need four, six and six respectively. If you provide more values than the shape requires, the extra values are ignored; if you provide fewer, the tool issues an error message.

The arithmetic of a ratio is worth doing once by hand. Each value is the proportion of that edge to the sum of all the values listed. So for an L-shaped block given -side_ratio {1 2 1 1}, the sum is 5, each side given as 1 is one fifth — 20 percent — of the sum, and the side given as 2 is two fifths, or 40 percent.

A rectangle takes only two values, and the order is the one place people slip. -side_ratio {3.0 1.0} is three wide by one high — an aspect ratio of 3.0 — and -side_ratio {1.0 3.0} is the same rectangle stood on end, an aspect ratio of 0.33. Both cores have the same area, because the ratio changes the shape and never the size; the size still comes from the utilisation and the area it has to hold.

-orientation takes N, W, S or E and repositions the block by rotating it clockwise; for a rectangle the orientation is always N. And -coincident_boundary, which defaults to true, decides whether the die boundary follows the shape of the core. If it is true, the die assumes the same shape as the core and requires a -core_offset with the same number of sides as the core. If it is false, the die boundary is rectangular and the offset requires only four values; the die is then created so that each offset value is honoured to the closest core edge, and its bounding box is the minimum size that meets all four.

4.2.6 Rows: how many, which way up, and how much room between

Three separate decisions hide behind the word "rows", and they are easy to merge on first meeting.

How many is arithmetic, not an option. The core side divided by the row height gives the number of whole rows, and whatever is left over is a remainder at the edge. For Nimbus-8's 3.20 mm core and the teaching library's 0.576 µm row height, 3200 ÷ 0.576 = 5555.56, so there are 5555 whole rows and 0.32 µm left over. The remainder is not a defect.

Which way up is -flip_first_row, which defaults to true. It specifies whether the command flips the first row at the bottom of the core area for horizontally placed cell rows, or the leftmost row for vertically placed ones. To avoid flipping the first row, say -flip_first_row false.

How much room between is -row_core_ratio, a number between 0 and 1.0 that specifies the amount of channel area between cell rows in the core area to reserve for routing. A smaller ratio creates more space for routing channels; a value of 1.0 creates none. The default is 1.0 — and the ratio should be equal to or greater than the core utilisation value.

4.2.7 Tracks

initialize_floorplan creates wire tracks along with the boundary, the core and the rows. The other track commands exist to change or add to what it produced.

To create routing tracks, use create_track, specifying the layer with -layer, the number of tracks with -count, the pitch distance between tracks with -space, the wire width with -width and so on. The location can be given two ways. -coord specifies the location of the first track, with the tool using the x- and y-coordinates set by -dir, which specifies the stepping direction in which the tracks are placed; by default, the first track is located at half the space distance inside the die area. Alternatively -relative_to aligns one of the track lines to the lower boundary of either the core area bounding box or the block bounding box, and the tracks are then created completely within the block boundary even if that boundary is larger than the core; -end_grid_relative_to does the same for subsequent grid points.

icc2_shell> remove_tracks -all
1
icc2_shell> create_track -layer METAL3 -space 0.5
{TRACK_0}
icc2_shell> report_tracks
Layer          Direction     Start         Tracks    Pitch          Attr
------------------------------------------------------------------------
METAL3             Y         0.250          4023     0.500       default

That report is the whole reason to run it. The pitch is 0.500 and the start is 0.250 — half the pitch, exactly as documented — so one line of output confirms both the number you typed and the rule the tool applied to it.

There is an easier method. If you have defined an appropriate track constraint, derive_tracks creates tracks automatically; -layers and -labels specify the layer and the label, and if no label is specified the command searches all default label track constraints in all the given layers. -verbose reports the details of track generation on the specified layers.

# Let the constraints decide, on two layers.
icc2_shell> derive_tracks -layers {M1 M2}

4.2.8 The FinFET grid, and the rows and grids you did not create

The tool supports a FinFET grid to guide the placement of library cells that contain FinFET devices. The x- and y-spacing and offset values for that grid are specified in the technology file — not by you. report_grids -type finfet reads them out, and check_finfet_grid checks for placement or boundary violations with respect to the grid, with -objects narrowing the check to specific object types.

Sixteen commands are FinFET-grid aware, initialize_floorplan among them, and so are the block-shaping, macro-array, I/O-ring, placement and site-row commands that later chapters use. That is the reason to run the check here rather than later: a boundary point that is off-grid at floorplan time is off-grid for everything built on it.

One more thing the command creates without being asked. By default initialize_floorplan creates site array objects; -use_site_row forces it to create site rows instead. -site_def names the site definition to use when the technology file has more than one; the default is to use the default site def, and if there is no default, the command uses the site def with the smallest site width.

4.2.9 Re-running the command without losing your work

After creating the initial floorplan, you repeat the command with different options to experiment with different shapes and characteristics. That is the intended workflow, and it has one sharp edge: by default the command deletes all existing routes and rebuilds everything from the options you have given it this time.

Seven options stop it. -keep_boundary uses the existing die boundary, and issues an error if the core-based constraints result in a core too large to fit inside it. -keep_pg_route keeps the power and ground routes; -keep_detail_route keeps all the routes except those. -keep_placement takes a list of object types — io, macro, block, std_cell, physical_only or all. -keep_objects takes named cells and nets, either as a collection from an object-access command or as name patterns in a Tcl list. -keep_object_types takes placement_blockage, routing_blockage and move_bound. And -keep_all keeps macros, standard cells, I/O, physical-only objects, blocks, blockages, detail routes and PG routes.

4.3 Inputs, outputs and readiness

What has to be true before the first run

What the floorplan makes, and what it does not

Reporting what you have

report_design -floorplan, or report_design -all, reports the floorplan information. What it covers is worth knowing before you need it: the core and chip area; the site rows, with name, width, height, number of rows, number of tiles and area for each; the blockages, with a count and an area for each blockage type; the power domains, with the domain name, voltage area name and primary power and ground nets; the voltage areas, with name, number of shapes, area, target utilisation and bounding box; the group bounds and move bounds; the route guides; the multibit registers; the reserved placement groups; and the layers, with name, direction, pitch, default width, minimum width, minimum spacing, and minimum spacing between the same nets.

That is a lot for one command, and the reason to run it here is narrow: it is where the core and chip area, the site-row count and the layer pitches can be read in one place, without a timing update and without a spreadsheet.

Preflight checklist

When the result is not trustworthy

The readiness gates that belong to this chapter

dp_pre_floorplan is the gate for this chapter, and its three checks are all about the technology data rather than your design: it checks that the technology file information is correct, that the layer directions are set, and that the design contains both horizontal and vertical layers.

dp_floorplan_rules is the gate on the other side. It checks the segment parity rule and the macro spacing rule, and it runs the checks performed by check_finfet_grid.

# Before the floorplan: is the technology data fit to floorplan with?
icc2_shell> check_design -checks {dp_pre_floorplan}

# After it: does the geometry obey the rules?
icc2_shell> check_design -checks {dp_floorplan_rules}

4.4 The guided workflow

4.4.1 A session from an empty directory to a written floorplan

4.4.2 Command by command

create_lib — somewhere to put the design

Purpose. Create the design library that will contain the design, bound to a technology and a set of reference libraries.

Syntax in plain English. The library name is positional. -technology takes the path to a technology file, or -use_technology_lib names a library to take the technology from instead. -ref_libs takes the reference libraries. -scale_factor sets the library's database units per micron — the number Chapter 2 spent a section on, and the one you cannot change afterwards. -convert_sites, -base_lib and -dont_set_current cover the rest.

icc2_shell> set libs [glob -directory ${lib_dir} *.ndm]
icc2_shell> create_lib -technology nimbus8.tf -ref_libs $libs \
   nimbus8.dlib

Expected result. A library exists and is current.

Verification. report_design -library. And, because Chapter 2 earned the right to say so: get_attribute [get_lib nimbus8.dlib] scale_factor before you rely on any coordinate.

Common mistakes. Creating a library without the technology file and discovering it when the floorplan has no rows. Choosing a scale factor on the first day of a project without checking the technology file's own length precision.

Prerequisites. A technology file and reference libraries on the search path.

Finding the rest. man create_lib, and man open_lib for the case where the library already exists.

read_verilog_outline — the netlist, cheaply

Purpose. Read the Verilog netlist and create an outline view of the blocks at the different levels of hierarchy, so that floorplanning can begin without the memory cost of the full netlist.

Syntax in plain English. The file names are positional and -top names the top module. -library and -design name the library and design. -partition and -allocation choose the density method; -target_block_size, -glue_cell_count, -large_threshold, -target_cell_count and -depth tune it. -dense_modules, -sparse_modules and -port_modules name modules explicitly. -leaf_cells, -buffer_cells and -macro_cells tell the reader which cells are which.

icc2_shell> read_verilog_outline -top NIMBUS8 nimbus8.v

Expected result. An outline design containing hierarchy, and no leaf cells or nets.

Verification. current_design names the representation. On a large design, also check that the density assignment is what you intended before you spend an hour on it.

Common mistakes. Expecting the design to be partitioned — it is not; commit_block and expand_outline do that. Tuning the cell counts while the depth is also set, so that only the depth is having an effect.

Prerequisites. A library, and the netlist file on the search path.

Finding the rest. man read_verilog_outline, and man read_verilog for the full netlist flow Chapter 3 needed.

initialize_floorplan — the command this chapter is about

Purpose. Create an initial floorplan with a die boundary, a core, a site array or rows, and wire tracks — either with a die boundary coincident with the core, or a rectilinear core inside a rectangular die.

Syntax in plain English. Everything is optional, and the options fall into four groups: what shape, how big, where the die sits relative to the core, and what to keep from last time.

# A first exploratory run: one option, and the defaults do the rest.
icc2_shell> initialize_floorplan -core_utilization 0.8 \
   -core_offset {1000 1000 1000 1000}

# An L-shaped core, sized by proportion.
icc2_shell> initialize_floorplan -core_utilization 0.7 -shape L \
   -orientation N -side_ratio {1 1 1 1} -core_offset {100.0} \
   -flip_first_row true -coincident_boundary true

# A rectangle three times as wide as it is high.
icc2_shell> initialize_floorplan -core_utilization 0.7 -shape R \
   -orientation N -side_ratio {3.0 1.0} -core_offset {100.0} \
   -flip_first_row true -coincident_boundary true

# A complex rectilinear die, from coordinates.
icc2_shell> initialize_floorplan -control_type die -core_offset 100 \
   -boundary { {0 0} {0 3000} {1000 3000} {1000 2000} \
   {2000 2000} {2000 3000} {3000 3000} {3000 0} \
   {2000 0} {2000 1000} {1000 1000} {1000 0} }

Expected result. A boundary, a core, a site array or rows, and wire tracks.

Verification. Three reports and one check, in that order: report_design -floorplan for the areas and the site rows, report_tracks for the pitches and starts, report_grids -type finfet for the grid, and check_finfet_grid for violations against it.

Common mistakes. Relying on the default -control_type and being surprised that the offsets were added rather than subtracted. Typing -side_ratio {1 3} for a core meant to be wide. Setting -row_core_ratio below the utilisation. Re-running without -keep_* and losing the PG routing.

Prerequisites. An open physical design, or one created by read_verilog or read_verilog_outline.

Finding the rest. man initialize_floorplan — including the labelled diagram that maps argument positions to edges for the L, T and U shapes.

read_physical_rules — a floorplan from a rules file

Purpose. Load a physical rules file so that the floorplan is created from the specifications it lists rather than from options alone.

Syntax in plain English. The file name is positional; -include narrows what is read and -library names the library. The rules content can also live inside a technology file.

icc2_shell> read_physical_rules in.prf
icc2_shell> initialize_floorplan -row_pattern hybrid_a

Expected result. A floorplan built using the information in the rules file. In a physical rules file you can include placement rule constraints, physical cell and pin properties, and stream-in instructions in one unified format.

Verification. The rows and tracks the floorplan ends up with. For layers that have a track pattern defined in the file, wire tracks are created from that pattern; for layers without one, they are created the ordinary way.

Common mistakes. Two, both documented as conditions rather than errors. To make the tool use the rules file to calculate the core area you must set -row_pattern, and you must not set -boundary, -keep_boundary or -side_length. And where a hybrid design has site rows of different heights, the cells need balancing to arrive at an optimal core area — which is what the hybrid-design application option is for.

icc2_shell> set_app_options \
   -name plan.floorplan.enable_adjust_core_area_for_hybrid_design \
   -value balance

Prerequisites. A physical rules file, and hybrid rows defined in it if you intend to use a row pattern.

Finding the rest. man read_physical_rules.

modify_die_area — shrink or grow what you already have

Purpose. Shrink or expand the die area, or the size of the design, without rebuilding the floorplan from scratch.

Syntax in plain English. The three scaling options — -area_scaling_factor, -height_scaling_factor and -width_scaling_factor — control the resizing of the core area, its height and its width, with valid values from 0.1 to 10. -core_utilization instead specifies the required utilisation of the core area. -fixed_edges lists the edges whose length must remain unchanged. -sizing_type defines constraints on aspect ratios, taking fixed_width, fixed_height or fixed_aspect_ratio. -row_pattern names the row pattern to use. -compile calculates and prints a summary of the estimated floorplan layout and creates a new floorplan based on the estimates. And -run_track_creation_script runs a custom script that re-creates the tracks after the resizing; by default the command derives the track information from the input floorplan and reuses it.

# Shrink the core area to 85 % of its original size.
icc2_shell> modify_die_area -area_scaling_factor 0.85

# Shrink the core height to 80 % — a 20 % reduction.
icc2_shell> modify_die_area -height_scaling_factor 0.8

# Or state the utilisation you want instead of a factor.
icc2_shell> modify_die_area -core_utilization 0.75

# Grow the core height to 110 % — a 10 % increase.
icc2_shell> modify_die_area -height_scaling_factor 1.1

# Shrink by area but hold the width, and print the summary first.
icc2_shell> modify_die_area -area_scaling_factor 0.85 \
   -sizing_type fixed_width -compile

Expected result. With -compile, a die-size exploration summary that prints the original and the estimated floorplan layout side by side — utilisation ratio, core area, core width, core height and boundary coordinates for each — and then a new floorplan based on the estimate.

Verification. Divide. The estimated core area over the original should be the factor you asked for, the dimension you fixed should be unchanged, and the utilisation should have moved by the reciprocal of the factor. §4.5 does this on real numbers.

Common mistakes. Aiming for a large change. Reducing the size can offer benefits — the smaller the die, the more dies per wafer — but you should aim for minor changes, because major ones can cause excessive utilisation or macros that no longer fit. The action counts as successful when the shrunken design is still routable, still meets its operating speed requirements, and still meets its allowable power consumption.

Prerequisites. An existing floorplan.

Finding the rest. man modify_die_area.

4.4.3 Getting the floorplan out, back in, and into another block

Three commands, and one of them reuses machinery from Chapter 3.

Writing. write_floorplan creates a directory named floorplan and writes three files into it. floorplan.def contains the physical layout, connectivity and design constraint information. floorplan.tcl contains additional design intent that cannot be described in the DEF file — hard macro keepout margins, for instance. fp.tcl contains commands to remove design constraints such as voltage areas, bounds and routing guides. The command supports both design views and abstract views for blocks, and it also writes out the constraint mapping file that maps each block to its corresponding fp.tcl.

Options control what goes in. -include and -exclude take object type lists — and there are thirty of them, from blockages and bounds through rows, tracks and vias to bump_regions and anchors; by default all supported object types are written out. -objects and -blocks narrow it further. -include_physical_status and -cell_types filter by status and by kind of cell. -exclude_user_attributes takes none, which writes all the user-defined attributes out, or all, which excludes them. -force overwrites, -def_version sets the DEF version, and -read_def_options adds options to the read_def call in the generated fp.tcl.

# Just the hard macros, with their origins and orientations.
icc2_shell> write_floorplan -output "macros" -objects [get_cells \
   -physical_context -filter is_hard_macro==true]

# The PG regions, overwriting the directory if it exists.
icc2_shell> write_floorplan -force -objects [get_pg_regions] \
   -output pg

# Pad and macro cells that are fixed or unplaced.
icc2_shell> write_floorplan -force -include cells \
   -include_physical_status {fixed unplaced} -cell_types {pad macro}

# Clock, power and ground nets only; signal nets excluded.
icc2_shell> write_floorplan -force -output nets \
   -net_types {clock power ground}

Reading it back. For a flat block, source the fp.tcl file. For a hierarchical design that might contain a mix of design and abstract block representations, use the two commands from Chapter 3 with a different keyword: set_constraint_mapping_file assigns the map, and load_block_constraints -type FLOORPLAN -all_blocks sources each fp.tcl named in it, re-creating the floorplan for each block.

icc2_shell> source floorplan/fp.tcl

# or, for a hierarchical design
icc2_shell> set_constraint_mapping_file floorplan/mapfile
icc2_shell> load_block_constraints -type FLOORPLAN -all_blocks

The DEF path is adjacent and not the same. read_def reads a DEF file; -syntax_only analyses the syntax of the input files before annotating the objects on the design. write_def writes one out. What a DEF cannot carry is the design intent that floorplan.tcl holds, which is exactly why the floorplan writer produces both.

Copying. copy_floorplan copies floorplan data from the design view of a source block to the design view of an existing destination block; the designs can be in the same library or in different ones, and a design label can be given along with the block name. -from_block is required, -to_block names the destination, and -include, -exclude and -objects narrow what travels; by default all object types are copied. -force copies objects into an existing floorplan under new names even when they are already present.

# Everything, into the currently open block.
icc2_shell> copy_floorplan -from_block test:mem/placed

# Everything, into a named destination.
icc2_shell> copy_floorplan -from_block test:mem/placed \
   -to_block test:mem_copy/placed

# Only blockages and bounds.
icc2_shell> copy_floorplan -verbose -from_block test:mem/placed \
   -to_block test:mem_copy/placed -include {blockages bounds}

4.4.4 Floorplan rules for advanced technology nodes

Floorplans developed for advanced technology nodes have additional requirements for the placement and spacing of standard cells, macros and other objects. Seven commands create those rules, and one checks them.

# A minimum area for the standard-cell area.
icc2_shell> set_floorplan_area_rules -name area_rule_1 \
   -object_types std_cell_area -min 100

# A width that must fall on an 8.0 step with a 40.0 offset.
icc2_shell> set_floorplan_width_rules -name width_rule_1 \
   -object_types std_cell_area -type simple -direction horizontal \
   -step 8.0 -offset 40.0

# And then check the floorplan against the rules you created.
icc2_shell> check_floorplan_rules {floorplan_rule_1 floorplan_rule_2}
icc2_shell> check_floorplan_rules -object_types {std_cell hard_macro}
icc2_shell> check_floorplan_rules -lib_cells MACRO4

check_floorplan_rules takes the rules to check as a list after the command name, and with no arguments lists the currently specified floorplan rules. -object_types narrows the check to hard_macro, std_cell_area, soft_macro, block_boundary or core_area; -lib_cells narrows it to named library cells; -exclude_rules and -exclude_lib_cells take things out; -bbox restricts it to a region; and -error_view names a view for the violations.

4.5 Worked example: Nimbus-8's floorplan, twice

The situation

Chapter 1 left Nimbus-8 with an area estimate and a partition, and nothing geometric. The estimate is 6.313 mm² of placeable area: 3.465 mm² of standard cells, 2.304 mm² of SRAM macros and the 0.544 mm² DDR PHY. The partition is four block references and one top-level hard macro, and the style is narrow-channel — thin channels between most blocks, with room for glue logic where the top level needs it.

Two questions have to be answered before anything is typed. How big should the core be? And how far should the die sit outside it?

Step 1 — Do the arithmetic before you open the tool

The default utilisation is 0.7. At 0.7, the estimate asks for a core of 6.313 ÷ 0.7 = 9.0186 mm², which is a square 3.0031 mm on a side. That is the floorplan the command would produce if you gave it nothing but the netlist.

Nimbus-8 does not take it. The narrow-channel style needs channel area that the estimate does not include, so the core is set to 3.20 mm square — 10.24 mm² — which puts the utilisation at 6.313 ÷ 10.24 = 0.6165. That is deliberately below the default, and the difference, 10.24 − 9.0186 = 1.2214 mm², is the channel budget: leftover core after packing placeable area at utilisation 0.70. That is not Chapter 1’s leftover between committed block shapes (10.24 − 8.149 = 2.091 mm²). Same word “channel,” two identities.

#=============================================================
# The arithmetic, written down before the command that uses it
#=============================================================
placeable area                              =  6.313 mm2
core at the default utilisation  6.313 / 0.70  =  9.0186 mm2
                                 sqrt(9.0186)  =  3.0031 mm

chosen core                        3.20 x 3.20  =  10.24 mm2
utilisation that implies          6.313 / 10.24  =  0.6165
channel budget                   10.24 - 9.0186  =  1.2214 mm2

core offset                                     =  0.12 mm per side
die                            3.20 + 2 x 0.12  =  3.44 mm
die area                           3.44 x 3.44  =  11.8336 mm2
core as a share of the die       10.24 / 11.8336  =  86.53 %

Step 2 — Start the session, and gate before you build

% icc2_shell -dp_mode

icc2_shell> report_user_units
... time 1.00ps, the project convention from the setup file ...

icc2_shell> report_app_options -non_default
... one line: lib.setting.use_tech_scale_factor is true ...

icc2_shell> set libs [glob -directory ${lib_dir} *.ndm]
icc2_shell> create_lib -technology nimbus8.tf -ref_libs $libs \
   nimbus8.dlib

icc2_shell> check_design -checks {dp_pre_floorplan}
... technology file correct; layer directions set; both
    horizontal and vertical layers present ...

The gate runs before the netlist, deliberately. It checks the technology data, and the technology data is what everything else will be derived from.

Step 3 — Read the netlist, cheaply, and prove which reader ran

icc2_shell> read_verilog_outline -top NIMBUS8 nimbus8.v
icc2_shell> current_design
{nimbus8:NIMBUS8.outline}

The representation is outline, which is what this chapter wants and what Chapter 3 forbade. If it had read design, somebody had used the flat reader and the session is carrying a full-chip netlist it does not need.

Step 4 — Create the floorplan

#=============================================================
# ./scripts/20_floorplan.tcl
#=============================================================

# Say what the numbers describe, rather than relying on the
# default: these are core dimensions, in microns.
initialize_floorplan -control_type core -shape R \
   -side_length {3200 3200} \
   -core_offset {120} \
   -coincident_boundary true \
   -flip_first_row true

# Read it back, three ways, before believing any of it.
report_design -floorplan
report_tracks
report_grids -type finfet

Step 5 — Check the six numbers you did not choose

Six of those thirteen rows are yours: the core side, the offset, and the four areas and ratios that follow from them. The other seven come from the technology data, and the only correct way to obtain them is to read them out of the tool.

Step 6 — Somebody asks for it 15 percent smaller

Two weeks later the die cost target moves and the request is for 15 percent less core area. This is exactly what modify_die_area is for, and exactly the situation in which to print the summary before committing to it.

icc2_shell> modify_die_area -area_scaling_factor 0.85 -compile

Die Size Exploration Summary
--------------------------------------------------------------
Original Floorplan Layout
        Utilization Ratio: 0.6165
        Core Area: 10.2400
        Core Width: 3.2000     Core Height: 3.2000

Estimated Floorplan Layout
        Utilization Ratio: 0.7253
        Core Area: 8.7040
        Core Width: 2.9503     Core Height: 2.9503

Step 7 — Read the last row of that table again

Seven of the eight rows are arithmetic. The eighth is an engineering judgement, and it is the reason the table is worth building.

At 0.6165 the core held the placeable area plus 1.2214 mm² of channel budget. At 0.7253 it holds the placeable area and 0.3146 mm² less than the area a 0.7 utilisation would want — so the channel budget that justified the narrow-channel style has not merely shrunk, it has gone. The resize is legal, the floorplan is legal, and the style the project agreed to is no longer affordable inside it.

That is the conversation to have before accepting the 15 percent, and it is a conversation about one number. Aim for minor changes: a shrunken design counts as a success only when it is still routable, still meets its operating speed requirements and still meets its allowable power consumption. A 15 percent area reduction that eats the entire channel budget is not obviously any of those things.

Step 8 — Write it out and save

icc2_shell> check_finfet_grid
icc2_shell> check_design -checks {dp_floorplan_rules}
icc2_shell> write_floorplan -force -output floorplan
icc2_shell> save_lib -all

Step 9 — What a senior engineer looks at next

1. Is the utilisation defensible for the style? Not "is it below 0.7" — is the difference between the core area and the placeable area enough for the channels the style needs.
2. Do the reported rows and tracks match the arithmetic? If they do not, the row height or the pitch is not what you assumed, and everything downstream inherits the error.
3. Did the FinFET check pass on the boundary as well as the macros? Boundary points are the ones people forget, and sixteen commands care.
4. Is the floorplan written out, with its map? An unwritten floorplan exists in one session on one machine.

4.6 Failure modes and debugging

Each entry follows the same five-part shape: symptom, likely cause, diagnostic check, correction, prevention.

The misleading one, in detail

Here is the failure that looks like a tool problem and is not. An engineer creates a floorplan, is happy with it, spends a day building the power mesh, then decides the core should be two percent larger. They re-run initialize_floorplan with the new number, the command succeeds in a second, and the floorplan looks right. The power mesh is gone.

Nothing failed. By default the command deletes all existing routes, and deleting a route is not an error — it is documented behaviour, and it is the correct behaviour, because a route drawn for one core is not valid on a different one. The engineer's instinct is to look for a bug in the PG commands, or to wonder whether the save failed, and both instincts lead away from the answer.

The diagnostic is not an analysis: it is reading the command line that ran. If there is no -keep_pg_route on it, the routes were deleted on purpose. The correction is to re-create the mesh from the script that made it, which is an argument for the mesh being in a script. The prevention is a habit rather than an option: the first run of initialize_floorplan carries no -keep_* options, and every subsequent run carries the ones that match what now exists.

4.7 Hands-on mini lab

Goal

Turn an area estimate into a floorplan you can defend. Working on a small synthetic design called Draco-5, you will size a core from a utilisation, choose an aspect ratio, compute the rows and tracks the core implies, resize it, and prove every number two ways. No real design data is needed.

Supplied assumptions — Draco-5

Steps

1. Predict, before you run. On paper, compute the core area, the core width and height, the die dimensions, the die area, the offset area and its share of the die, the number of whole rows, the number of tracks across the core width, and where the first track sits. Do not look at the answers below.
2. Build the library. Write the create_lib line with a technology file and reference libraries. Say in a comment why the scale factor is not something you will change later.
3. Gate first. Run the pre-floorplan check and record which three things it examined.
4. Read the netlist. Use the outline reader, name the top module, and prove with current_design which representation you have.
5. Create the floorplan. One initialize_floorplan command. State the control type, the shape, the size and the offset explicitly, even where you are choosing a default. Add a comment saying which of the two sizing options you used and why.
6. Read it back. Three reports, in order. Compare every number with your predictions from step 1 and explain any difference before changing anything.
7. Check the grid. Run the FinFET grid report and then the check. Write down what the check would have caught if a macro had been placed half a pitch off.
8. Refine once, safely. Re-run the floorplan command with the utilisation raised to 0.78, keeping the boundary. Say what you expect to happen, then say what you would expect if the boundary had not been kept.
9. Resize. Apply the 10 % request with the width held fixed, printing the summary first. Compute the new height, the new utilisation and the new row count, and check each of them two ways.
10. Write it out. Write the floorplan, list the three files it produced, and say which of the three a DEF alone would not have given you.

Expected observations

Stretch task

Draco-5 is abutted, so it needed no channel budget. Repeat the whole prediction for a narrow-channel version that needs 0.540 mm² of channel area. What utilisation should you type, what core does that give, and does the 10 % resize request still leave the channel budget positive? Then say which of the two designs you would rather defend in a review, and why.

4.8 Interview preparation

Sixteen questions, grouped by level. Answer each one out loud before reading the model answer. This chapter is the most heavily interviewed of the four so far, because it is the one where a candidate's answer reveals immediately whether they have ever run the flow or only read about it.

Beginner

Intermediate

Scenario and debugging

4.9 Chapter close

Sign-off checklist for a floorplan you would defend

Key-concept flashcards

Compact glossary

Five-question self-check

1. A core is 2.40 mm square with a core offset of 0.15 mm on all sides. What is the die area, and what percentage of the die is offset?
2. A core of 5.400 mm² holds 3.240 mm² of placeable area. What is the utilisation, and is it above or below the default?
3. A core is 1.440 mm high, and the library's row height is 0.576 µm. How many whole rows, and how do you know there is no remainder?
4. A core is 3.750 mm wide and the track pitch is 0.048 µm. How many track pitches across the core, and where does the first track sit?
5. You have a utilisation of 0.60 and you want 0.75 without changing the design. What area scaling factor do you ask for, and what one thing would you check before accepting the result?

Answers.

1. The die is 2.40 + 2 × 0.15 = 2.70 mm square, so the die area is 2.70 × 2.70 = 7.29 mm². The core is 2.40 × 2.40 = 5.76 mm², so the offset area is 7.29 − 5.76 = 1.53 mm², which is 1.53 ÷ 7.29 = 20.99 % of the die. Worth noticing: a small die spends a much larger share of itself on the offset than a large one does, because the offset is a perimeter effect and the core is an area.

2. 3.240 ÷ 5.400 = 0.60, which is below the default of 0.7. That is not a fault — it is either headroom for the cells optimisation has not added yet, or a channel budget, and a floorplan review should be able to say which.

3. 1440 ÷ 0.576 = 2500 rows exactly. You know there is no remainder because 1440 is a whole multiple of 0.576: 0.576 × 2500 = 1440.0. In general there is a remainder — Nimbus-8's 3200 µm core leaves 0.32 µm — and it is arithmetic rather than a defect.

4. 3750 ÷ 0.048 = 78125 pitches exactly. The first track sits half the space distance inside the die area, so at 0.048 ÷ 2 = 0.024 µm. Confirm both with report_tracks, which prints the start and the pitch on the same line so that one is a check on the other.

5. Utilisation moves by the reciprocal of the area factor, so you want 0.60 ÷ 0.75 = 0.80 — modify_die_area -area_scaling_factor 0.80, with -compile first so the summary prints before anything is created. The one thing to check before accepting it is the channel budget: a 20 percent area reduction is not a minor change, and the documented risks of a major one are excessive utilisation and macros that no longer fit. Concretely, whether core area minus placeable-area-at-the-intended-utilisation is still positive.

Where the next chapter goes, and why

There is now a boundary, a core, rows and tracks — and inside that boundary, blocks whose shapes are still nominal and one category of thing that has no shape at all. A black box is a block whose contents do not yet exist: a module that will be designed later, or bought, or is still being written, but which has to be planned around today. Chapter 5 handles them: how to identify which modules are candidates, how to create black box references, how to give a black box a timing model so the rest of the chip can be timed against it, and what the power intent has to say about something that is not there yet.

The connection to this chapter is direct and slightly uncomfortable. Chapter 1 mentioned that a black box needs a target area or a utilisation before it can be shaped, and this chapter has just shown where that number lands: in the same core area arithmetic, competing with everything else, for a block nobody has designed. That is the reason black boxes come immediately after the floorplan rather than at the end — an unsized unknown is the one thing a floorplan cannot absorb late.