CHAPTER ONE

What a Design Plan Is, and Why the Rest of the Chip Obeys It

By the end of this chapter you will be able to explain what design planning produces, decide how a large netlist should be divided into physical blocks, size a core from cell area, and prove that a design is ready for the next planning step instead of hoping that it is.

Why this chapter matters in a real project

On a large chip, the decisions made in the first week of physical work are the ones nobody gets to take back cheaply. Where you draw the boundary between two blocks decides how many wires must cross that boundary for the next nine months. How big you make the core decides how much silicon area the company pays for on every wafer, forever.

Design planning is the stage where those decisions are made deliberately rather than by accident. It sits between synthesis, which produced a netlist with no physical meaning at all, and implementation, which will spend enormous compute on placement, clock trees and routing. Its job is not to finish anything. Its job is to find out — quickly, and before the expensive steps start — whether the shape of the chip you have in mind can actually work, and to hand every downstream team a piece of the problem small enough to solve.

Engineers who are good at this stage look slow at first. They measure before they draw. They write down the assumption behind every number. They run a cheap check before a long command. Then they finish months earlier than the engineer who started by typing a die size.

Prerequisites

This is the first chapter, so it assumes only that you know what a logic gate and a flip-flop are, and that a netlist is a list of cells and the nets connecting them. Everything physical is introduced from zero; if you have never seen a floorplan, a routing track or a Tcl command, you are the reader this chapter was written for.

Learning objectives

1.1 The beginner’s mental model

Start with a building

An architect handed an empty plot and a list of requirements — twelve offices, one laboratory, a server room, a lift — does not begin by drawing walls. She begins by adding up how many square metres of room she has been asked for, comparing that with the plot, and deciding how the space will be divided. Only then does she draw. She knows that corridors are not wasted space: without them nobody reaches the offices. She knows the lift shaft cannot be moved to suit a nicer layout, because it is a fixed structure that arrives as it is. And she knows that if she gets the division wrong, every later drawing inherits the mistake.

Design planning is that stage of work for a chip. You are handed a netlist instead of a room list, silicon area instead of a plot, and hard intellectual-property blocks instead of a lift shaft — and the discipline is the same. Measure, divide, place the immovable things, leave room for the connections, and check the arithmetic before anyone starts building.

Now the engineering model

Strip the analogy away and the model is concrete. A chip is fabricated as a rectangle of silicon called the die. Inside the die, set back from its edge, is the core: the region where logic cells are allowed to sit. The strip between core and die edge — the core offset — is not wasted either; it carries power rings, input/output structures and the seal ring that protects the die when it is cut from the wafer. No standard cells go there.

The core is not smooth. It is ruled into placement rows, each exactly as tall as the standard cells in your library, because a standard cell may only sit on a row, aligned to it, the way a book sits on a shelf. Crossing the rows, in every metal layer above, are routing tracks: the evenly pitched lines that wires are expected to follow. Rows tell you how much logic fits. Tracks tell you how much wiring fits. A floorplan that ignores either one will fail late and expensively.

Two kinds of things get placed in the core. A standard cell is a small library cell — an inverter, a flip-flop — one row tall, and there are millions of them. A hard macro is a large pre-built object such as a static random-access memory (SRAM) or a physical interface block: it arrives fully designed, it cannot be reshaped, it is taller than a row, and it blocks the rows it covers. You place macros. You do not synthesise them.

Do not confuse these

1.2 The concepts, built in dependency order

The rest of this chapter builds the subject one idea at a time, in the order the ideas depend on each other. Read the subsections in sequence the first time. Afterwards, each one is short enough to be re-read on its own.

1.2.1 What design planning is for

Design planning is an integral part of the path from register-transfer level (RTL) description to the final layout data. It exists for two reasons.

The first is feasibility. You want to know early — while changes are still cheap — whether a given implementation strategy can work. Is this die big enough? Can these blocks be placed so that the critical paths stay short? Will the wires fit? A planning run answers those questions in hours, using estimates, instead of finding the answer weeks later using a full implementation.

The second is divide and conquer. A design with millions of cells is expensive to process as one flat object. Splitting it into smaller, more manageable pieces lets separate teams work on separate blocks in parallel, from RTL all the way through physical implementation, and lets the tools work on one piece at a time. Working with smaller blocks — and reusing one block in several places — reduces overall runtime.

1.2.2 What floorplanning actually is

Floorplanning is the concrete work inside design planning. It means: partitioning logical modules into physical blocks; sizing and placing those blocks; performing a floorplan-level placement of macros and standard cells; and creating a power plan. The purpose is to make every downstream physical step more efficient, so that the design can be optimised robustly rather than rescued repeatedly.

An effective floorplan helps timing close, because placing blocks well makes critical paths short and reduces routing congestion. The difficulty is that the two goals fight each other. You want a small, area-efficient footprint, because area is money. You also want enough space left for routing, because wires need room. A floorplan that is too generous wastes silicon on every chip ever shipped. A floorplan that is too tight cannot be routed, and you will discover that after weeks of work.

Floorplanning is also iterative by nature. A realistic sequence reshapes the blocks, creates a new cell placement, reallocates the timing budgets, re-checks top-level timing, and goes round again until the floorplan is good enough. Expect several passes. An engineer who describes the first floorplan as “done” has not yet measured it.

1.2.3 Area arithmetic: the calculation you must be able to do by hand

Everything physical starts from one ratio. Core utilisation is the total area occupied by all standard cells and macro cells divided by the total core area. It is expressed as a number between 0 and 1: a core utilisation of 0.80 means 80 % of the core area is used for cell placement at this stage, and the remaining area is available for routing and for the cells that later steps will add.

That definition is worth reading twice, because two details in it catch people out. First, macros count: a design that is 30 % SRAM by area has far less standard-cell freedom than its cell count suggests. Second, it describes the area at this stage. Optimisation, clock-tree synthesis and hold fixing all add cells later, so a plan that starts at the utilisation you can just barely route has already failed.

Here is the arithmetic for this book’s teaching design, Nimbus-8, a small edge-inference system-on-chip. Every number in the table below is used again in later chapters, so it is worth following the calculation rather than skimming it.

Notice what happened between the two core numbers. Asking for a utilisation of 0.70 produces a 3.00 mm core — but that number quietly assumes the whole core can be filled with blocks. In a design with top-level logic sitting between the blocks, it cannot: some of the core must stay as channel. Once 2.09 mm² of channel is reserved, the honest core is 3.20 mm square and the honest utilisation is 0.617. Both numbers are correct; only one of them is a plan.

1.2.4 Logical hierarchy, physical hierarchy, and the moment one becomes the other

A netlist has a logical hierarchy: modules inside modules, written by designers for reasons of readability, reuse and verification. It has no physical meaning at all. Nothing about a module says where it sits, how big it is, or what shape it takes.

A physical hierarchy is something you choose. You select certain logical modules and declare that each will be planned, shaped, placed, routed and handed over as a unit. That declaration is called committing the module, and the result is a physical block. Blocks are committed early in the floorplanning flow, precisely so that the reduced views built from them can be used to produce an initial floorplan and initial timing budgets.

What changes in the database when you commit? The module stops being merely a name inside its parent and becomes an object with a boundary, an origin, pins where its nets cross that boundary, its own area target, and its own constraints. It can then be opened separately, planned separately, and given to another engineer. That is a genuine change of kind, not a label.

Two aids exist for the decision itself. A hierarchy browser in the graphical interface lets you navigate the design hierarchy, examine the logical structure, and read per-module information such as utilisation, standard-cell count and pin count — which is exactly the data the decision needs. For the same information in text form, ask the tool for a hierarchy report. Then, once you have decided, you commit.

1.2.5 Floorplan style: channelled or abutted

The tool supports complete hierarchical planning for both layout styles, and the choice interacts directly with your partitioning.

In an abutted floorplan the blocks sit directly against one another and there is no top-level logic between them. In a channelled floorplan there are gaps between blocks, and those gaps hold top-level logic — either a small amount or a large amount. There is also a narrow-channel variant for the case where the gaps are deliberately thin.

The consequence is simple and often missed by beginners: if your partition leaves cells at the top level, you cannot have an abutted floorplan, because those cells have nowhere to sit. Nimbus-8 keeps 0.19 M cells of clock generation, reset synchronisation and test control at the top, so Nimbus-8 is a channelled design, and 2.09 mm² of its core is reserved accordingly. Had we pushed every one of those cells down into blocks, an abutted style would have become possible — and the design would have had a smaller core but stiffer block interfaces.

1.2.6 Deciding where the boundaries go

Partitioning is the highest-leverage decision in the whole planning stage, and it is made with judgement informed by four factors.

Read those four in order and a rhythm appears: get the sizes comparable, respect function, match the style, align with synthesis. Figure 1.7 turns the same four factors into something you can walk through module by module.

1.2.7 More than two levels of hierarchy

Many tools are limited to two levels of physical hierarchy — top and block. Large system-on-chip designs frequently need more, and the tool provides comprehensive support for multiple levels at the same time, which is what makes it possible to treat u_cpu_cluster as a block that is itself a parent. You can enable or disable specific blocks and levels of hierarchy for planning with the set_editability command, which is how you keep a large multi-level design manageable while working on one part of it.

Support for extra levels is not a single feature; it appears in every planning function, and it is worth knowing where:

• Data model. Multiple levels of physical hierarchy are built into the data model, so shaping, placement, routing and timing can each reach the specific data they need for a given level quickly.
• Block shaping. The shaper needs each sub-chip’s target area, the aspect-ratio constraints imposed by hard macro children, and the interconnect that exists at sibling-to-sibling, parent-to-child and child-to-parent interfaces — plus, in multivoltage designs, the target locations of voltage areas. Shaping constraints on lower-level sub-chips are propagated upward as shaping constraints on their parents. Notably, the shaper does not need the full netlist inside each block, which is what keeps it fast.
• Cell and macro placement. After shaping, placement sees a global view of interconnect paths and data flow at the hierarchy boundaries, so it can place macros for every sub-chip at every level, reserve resource at adjacent sub-chip edges for the paths that must cross, and avoid positions where a path would need heavy buffering to get across a macro. It models the environment outside each sub-chip’s boundary, then distributes the per-sub-chip placement jobs across processes to shorten turnaround.
• Power planning. Construction rules — widths, layers, pitches — are described as reusable patterns and applied to regions such as voltage areas or macro groups, with strategies binding patterns to regions. From your top-level specification the tool characterises the plan and generates strategy definitions for sub-chips at all levels, so a floorplan change at any level can be followed by regenerating the power plan instead of redrawing it.
• Pin placement. With shapes formed, macros placed and power routed, pin placement gathers interface data from all levels and calls the global router to find good pin locations, aligning pins across levels where it can. It also creates the feedthroughs that let a signal cross a block it does not use, decides where a feedthrough can be reused, and connects unused ones to power or ground as required.
• Timing budgeting. The tool estimates timing at the hierarchical interfaces and creates budgets for the sub-chips: constraints for child interface pins in the full chip, for parent and child interfaces of mid-level sub-chips, and for the primary pins of the lowest-level sub-chips. With those in hand, the whole design can proceed into placement and optimisation concurrently.

You can also view, analyse and edit any level in full-chip context, choosing to see the top level alone or several levels at once. When several levels are shown, interactive routing behaves as though the design were flat; when you finish, the routes are pushed into the children and the hierarchical pins are added automatically.

1.2.8 One block, many placements: multiply instantiated blocks and feedthroughs

When the same block appears more than once in a design it is a multiply instantiated block, universally abbreviated MIB. Nimbus-8 has one: a single NPU (neural processing unit) core reference placed twice. You plan it once and place it twice, which is one of the strongest runtime and effort savings available in a hierarchical flow.

The saving comes with a constraint that beginners consistently underestimate. Because every instance is the same block, the pin placement must work for all of them: the algorithm determines a placement that suits every instance and makes the pin positions identical on each. A pin location that is ideal for instance 0 and awkward for instance 1 is not a legal location at all. The same applies to feedthroughs — the global router creates them across MIBs, decides which can be reused, and ties unused ones off to power or ground.

A feedthrough is a path provided through a block for a signal the block does not use. Without it, a net that needs to get from one side of the die to the other must detour around every block in the way, which costs wire length, delay and routing resource in the channels — often exactly where they are scarcest.

1.2.9 Sharing the clock period: timing budgets

Here is the idea that makes hierarchical planning possible at all. Two blocks that exchange a signal cannot be optimised independently unless somebody first decides how much of the clock period each of them is allowed to consume. That decision is a timing budget.

The tool estimates timing at the hierarchical interfaces and creates budgets for the sub-chips, so that each block team receives ordinary timing constraints describing its own slice and can then work alone. Figure 1.10 shows what the arithmetic looks like for one path in Nimbus-8: a 625 ps clock period, minus the clock uncertainty and the capture flip-flop’s setup requirement, leaves 550 ps to be divided between the launching block, the top-level channel and the capturing block.

1.2.10 The shape of the flow

You now have every concept needed to read the flow itself. Design planning is performed during the first stage of the hierarchical flow, after the initial netlist is available from synthesis, and it does three things: it partitions the design into blocks, it generates hierarchical physical constraints, and it allocates top-level timing budgets down to the physical blocks.

Figure 1.5 lays the whole sequence out with the command that drives each step and — just as important for a beginner — what the design database has gained by the time the step is finished. Do not try to memorise it. Read it as a map, and notice three things about its shape.

First, the physical comes before the temporal: shapes, macros, power and pins are settled before timing is budgeted, because the budget depends on distances that do not exist until the shapes do. Second, abstracts appear twice, once for placement and once for timing, because the two tasks need different reduced views of the same block. Third, the sequence is a loop, not a line: a bad budget sends you back to the floorplan, and the last step of a first pass is usually the first step of a second one.

1.3 Inputs, outputs and readiness

What has to exist before planning starts

Assumptions you are making, whether you say so or not

• That the average cell area you used is representative of this design, not of the last one.
• That the macro list is complete — including the macros that arrive in month three.
• That a black-box module (Chapter 5) will eventually fit in the area you typed for it — that area is spent, not a placeholder.
• That the clocks in the constraint file are the clocks the architects intend to ship.
• That your physical hierarchy matches the one synthesis used, if you intend to exchange scan-chain data.

Write each of these down with its value. An assumption on paper is a decision; an assumption in your head is a future argument.

Preflight checklist

What you get out

Planning changes the design database, and it is worth being precise about what appears in it. After a full pass you have: a die and core boundary with placement rows and routing tracks; committed blocks with boundaries, origins and pins; reduced views of each block for placement and for timing; block shapes and locations; an initial macro and cell placement; a power plan generated from patterns and strategies; planned buses, repeaters and routing corridors; placed hierarchical pins and the feedthroughs that go with them; one timing-constraint set per block; and written-out data for the implementation teams.

You also get something that is not a file: a defensible answer to the question “can this be built?”. That answer is the real deliverable.

When planning is premature, unsafe or misleading

1.4 The guided workflow

This section walks the flow end to end at survey level, then treats in detail the four commands that belong to this chapter. The deeper commands are named here so that you can see where they fit, and taught properly in the chapter that owns them — a command is best learned once, in context, not twice in outline.

1.4.1 The fourteen steps, and where each is taught

Three topics sit alongside the main line rather than inside it: blocks whose contents do not exist yet (Chapter 5), designs stacked in three dimensions (Chapter 7), and the planning of clock distribution across blocks (Chapter 12). The interface conventions, scripting and monitoring that make all of this comfortable to drive are Chapter 2.

1.4.2 Validation: the gate before every step

Design planning has a checking command, and the single most useful habit you can form in this chapter is to run it before a step rather than after it. You specify the command with the -checks option followed by one or more check keywords, and the tool performs those checks on the current design:

icc2_shell> check_design -checks {dp_pre_floorplan}

Each planning keyword guards a particular step. Table 1.7 lists them with what they examine, and Figure 1.11 shows the same information positioned along the flow.

1.4.3 A first session, step by step

The workflow below is the one this chapter can complete on its own: understand the design, decide the partition, and prove readiness. Steps that belong to later chapters are marked as such and deliberately not expanded.

1. Open the design. Library setup, block opening and the shell itself are Chapter 2. For now, assume a session with the design open.
2. Read the hierarchy. Produce a hierarchy report and, if you have the graphical interface, the hierarchy browser. Record for each candidate module: cell count, macro count, pin count.
3. Compute the area budget by hand (Table 1.2). Do not skip this because the tool can report utilisation later; the point is that you know the number before the tool tells you.
4. Decide the partition using Table 1.3 and Figure 1.7. Write the decision and its reasons in the script as comments.
5. Decide the floorplan style and reserve channel area consistent with the top-level logic you are leaving behind.
6. Scope your session with set_editability if the design has several levels and you only intend to work on part of it.
7. Run the readiness gate for the step you are about to take — here, dp_pre_floorplan.
8. Read the message summary, not just the last line. Fix the rules that were reported, and re-run until the gate is clean.
9. Only then proceed to floorplan initialisation (Chapter 4).

1.4.4 Command reference for this chapter

Four commands are genuinely part of this chapter’s work. Each is presented the same way: what it is for, what its syntax says in plain English, what must be true before you use it, a small realistic example, what to expect, how to verify, what goes wrong, and how to see the rest of its options.

report_hierarchy — see the structure you are about to divide

Purpose. Displays the logical and physical reference hierarchy for a block, so you can see what modules exist, which are already physical blocks, and where the leaves are.

Syntax in plain English. report_hierarchy with no arguments reports on the current block, showing both physical and logical references down to leaf level. -block names a different block to report on. -physical_context restricts the report to physical blocks and leaf modules, hiding internal modules. -hierarchical unfolds repeated blocks or modules that would otherwise be reported once. -no_leaf leaves the leaf modules out. -nosplit stops long fields from being wrapped onto a second line, which matters if you intend to post-process the report with a script.

Prerequisites. A design open in the session.

# What does the hierarchy look like, without the leaf-cell noise?
icc2_shell> report_hierarchy -no_leaf

# Only the physical picture: blocks and leaf modules, no internal modules.
icc2_shell> report_hierarchy -physical_context -no_leaf

# Unfold repeated instances instead of folding them into one line.
icc2_shell> report_hierarchy -hierarchical -no_leaf

Expected result. An indented tree. Blocks are printed with their full name, which distinguishes them from internal modules; leaf modules are shown with the library they come from. Repeated blocks or modules are folded into a single appearance unless they are bound to different views, or unless you ask for the unfolded form.

Verification step. Compare the tree against the module list you were given by the front-end team. Two mismatches matter: a module you expected to see and cannot, and a module that appears with a different reference than you expected.

Common mistakes. Reading the folded report as though it showed instance counts — a block used twice appears once by default. Reporting the wrong block because the current block is not the one you think it is. Post-processing a report captured without -nosplit and losing half of the long names to line wrapping.

Finding the rest. report_hierarchy -help lists the options; man report_hierarchy gives the full description.

get_design_checks — find out which checks exist

Purpose. Creates a collection of the available checks, both the ones predefined by the tool and any you have defined yourself. Use it when you want to know what is available rather than guessing a keyword.

Syntax in plain English. get_design_checks with a pattern returns the checks whose names match it. -filter narrows the collection using a Boolean expression over check attributes; -regexp treats the pattern as a regular expression rather than a wildcard; -nocase ignores case; -exact turns pattern matching off, which is what you need when a name itself contains * or ?; -quiet suppresses the warning when nothing matches.

Prerequisites. A session with the tool loaded. You do not need a floorplan.

# Which planning checks does this version of the tool provide?
icc2_shell> get_design_checks dp_*

# Everything, when you want to browse the whole list once.
icc2_shell> get_design_checks

# Which attributes can I filter on?
icc2_shell> list_attributes -class ems_check

Expected result. A collection of check objects. Predefined checks are those the tool ships with; user-defined checks are ones created with the check-strategy command. Some predefined checks are single checks; others are collections of several, so running one keyword can run a group.

Verification step. Confirm that the keyword you are about to pass to the checking command appears in this list. That single step removes an entire class of confusing failures.

Common mistakes. Assuming a keyword that existed in one release exists in the next; typing a keyword from memory rather than from the list; and forgetting that names are patterns by default, so a stray wildcard can return more than you meant.

Finding the rest. get_design_checks -help, then man get_design_checks.

check_design — prove the design is ready for the next step

Purpose. Runs predefined or user-defined checks on the current design. The messages produced are captured into a message database and a text log, and a summary of them is reported.

Syntax in plain English. -checks takes a list of one or more check names and is required. -ems_database names the database file the errors, warnings and information messages are stored in; if you do not give one, a default file name is used, and an existing file of that name is overwritten. -log_file names the text log to write; by default the tool generates one whose name carries a timestamp, in the working directory. -open_message_browser opens the graphical message browser on the results.

Prerequisites. The design open, and whatever data the specific check needs — technology data for the pre-floorplan check, blocks and targets for the shaping check, and so on. A check with nothing to inspect reports nothing useful.

# The gate before floorplan initialisation.
icc2_shell> check_design -checks {dp_pre_floorplan} \
               -log_file reports/ch01_pre_floorplan.log

# Two gates at once, into a named message database.
icc2_shell> check_design -checks {dp_pre_floorplan dp_floorplan_rules} \
               -ems_database reports/nimbus_pre_fp.ems \
               -log_file reports/nimbus_pre_fp.log

Expected result. A report header naming the command, the options you passed and the design, followed by the checks as they run and then a message summary: one line per rule, giving the rule identifier, its type — error, warning or information — the count, and the message text. A total line follows, and the message database is saved.

*** EMS Message summary ***
-----------------------------------------------------------------
Rule    Type  Count  Message
-----------------------------------------------------------------
...     Error   n    <one line per rule that fired>
...     Warn    n    <one line per rule that fired>
-----------------------------------------------------------------
Total N EMS messages : n errors, n warnings, n info.

Verification step. Two questions, in this order. Is the error count zero? And of the warnings, which ones are about the step you are about to run? A warning that names the very data the next command consumes is not a warning; it is an error that has not happened yet.

Common mistakes. Running it after a step instead of before. Reading only the total line — the rule identifiers are the actionable part. Letting the default database name overwrite the previous run’s evidence when you wanted to compare two runs. Passing a keyword that does not exist in your release. And treating a clean gate as proof of a good floorplan: it proves legality, not quality.

Finding the rest. check_design -help for the options, man check_design for the description, and get_design_checks for the keywords.

set_editability — decide which part of a big design you are working on

Purpose. Changes the hierarchical edit control of specified blocks, or their reference edit lock. In a design with several levels of physical hierarchy this is how you make one region editable for planning and leave the rest alone.

Syntax in plain English. -blocks lists the blocks whose editability changes, relative to the current top-level context; with no -blocks, the current block is affected. -value true makes them editable — the default — and -value false makes them uneditable. -from_level applies the value from a given design depth downward, and -to_level from a given depth upward; each of these is mutually exclusive with the other and with -blocks. -edit_reference_lock switches the meaning from hierarchical edit control to locking or unlocking the physical blocks for edit. -verbose prints more detail. The command returns the number of blocks whose control changed.

Prerequisites. A design with the blocks in question present in the current context.

# Work on the CPU cluster only; leave the rest of the design alone.
icc2_shell> set_editability -blocks {u_cpu_cluster} -value true -verbose

# Freeze everything from the second level of hierarchy downward.
icc2_shell> set_editability -from_level 2 -value false

Expected result. An integer count of the blocks that changed, and a design in which only the intended part can be edited.

Verification step. Attempt a harmless edit inside a block you intended to freeze and confirm that the tool refuses it, and one inside a block you intended to open and confirm that it succeeds. Two seconds of checking is cheaper than an afternoon of wondering why an edit did nothing.

Common mistakes. Combining -blocks with a level option — they are mutually exclusive. Forgetting that the default is true, so a call meant to freeze something opens it instead. Confusing hierarchical edit control with the reference edit lock: the first governs this top-level context, the second locks the block itself. And leaving a design frozen at the end of a session, so that the next engineer inherits a design that mysteriously refuses to change.

Finding the rest. set_editability -help, then man set_editability.

1.5 Worked example: the first planning session on Nimbus-8

The situation

You have joined the physical design team for Nimbus-8, an edge-inference system-on-chip. Synthesis has produced a first gate-level netlist. The architects want to know two things by Friday: how big the die will be, and how the work will be divided between the four engineers on the team. Nobody has drawn a floorplan yet.

The inputs you have been given are the netlist, the reference and technology data for an advanced FinFET node, a constraint file with four clocks, and a power-intent description with two supplies and one switchable area. The DDR PHY is a hard macro that has already been characterised. There is no timing result of any kind yet, and there will not be one until a plan exists.

Initial conditions and assumptions

Step 1 — Read the hierarchy before touching anything

# What am I actually dealing with?
icc2_shell> report_hierarchy -no_leaf

From the report, and from per-module cell and macro counts, you build the inventory in Table 1.9. This table is the whole basis of the partition decision, so it is worth ten minutes of care.

Two facts jump out of that table. The CPU cluster is 2.7 times the size of the next largest candidate. And three modules — the peripheral bus, the power-management unit and the PHY wrapper — are each too small to justify their own block.

Step 2 — The first partition attempt, and why it is wrong

The obvious first cut is one block per top-level module: seven blocks, no thought required. Walk Figure 1.7 over it and it fails three of the five questions.

• Size. The CPU cluster is far larger than the others. To fit it beside two NPU cores and the ISP on a 3.20 mm core it has to be drawn long and thin — 2.60 mm × 1.22 mm — and its tallest SRAM bank no longer fits inside that height. The fix is to divide it: commit its two internal core pairs as blocks of their own, giving three levels of physical hierarchy.
• Size again, in the other direction. Three blocks under 0.4 mm² each bring three boundaries, three pin sets, three abstracts and three budgets. Group them into one block, u_soc_periph, of 0.34 mm² — with the PHY itself left at the top level as a hard macro, since a wrapper containing one macro is not worth a block.
• Repetition. u_npu_core_0 and u_npu_core_1 are the same module. Committed as two separate references, they are planned twice, budgeted twice, checked twice and can drift apart. Committed as one reference with two instances — a multiply instantiated block — they are planned once.

Step 3 — Size the core from the revised partition

With the partition settled, redo the arithmetic in the order that matters: cells and macros first, then a first core estimate, then an honest core after channel allowance.

# Area that must be placed
A_std   = 9.90e6 x 0.350 um2            = 3.465 mm2
A_sram  = 72 x 0.0320 mm2               = 2.304 mm2
A_phy   = 1 x 0.544 mm2                 = 0.544 mm2
A_place                                 = 6.313 mm2

# First estimate: what would a 0.70 core look like?
A_core(0.70) = 6.313 / 0.70             = 9.019 mm2  -> 3.003 mm square

# Block shapes at 0.75 internal utilisation
cpu 3.171 + npu 1.189 x 2 + isp 1.717 + periph 0.339 + phy 0.544
                                        = 8.149 mm2

# A channelled style needs channel area for 0.19 M cells of glue,
# plus buses, repeaters and PG access. Choose 3.20 mm square:
A_core  = 3.20 x 3.20                   = 10.240 mm2
channel = 10.240 - 8.149                = 2.091 mm2   (20.4% of the core)
U_core  = 6.313 / 10.240                = 0.617

# Die, with 0.12 mm of core offset on each side
die     = (3.20 + 0.24) squared         = 3.44 x 3.44 mm = 11.83 mm2

Now you can answer the architects’ first question with a number and a reason: 3.44 mm square, because 6.313 mm² of cells and macros must be placed, 8.149 mm² of block shapes hold them at 0.75 internal utilisation, a channelled style needs about a fifth of the core as channel, and the core offset adds 0.12 mm on every side.

Step 4 — Prove readiness before initialising the floorplan

# Which planning checks exist in this release?
icc2_shell> get_design_checks dp_*

# Scope the session to the part of the hierarchy being planned.
icc2_shell> set_editability -blocks {u_cpu_cluster} -value true -verbose

# The gate that guards floorplan initialisation.
icc2_shell> check_design -checks {dp_pre_floorplan} \
               -log_file reports/nimbus_pre_fp.log

Suppose the summary comes back with a small number of errors and a larger number of warnings. Read it like this, in plain English:

Step 5 — What a senior engineer looks at next

With a clean gate and a defensible die size, the plan is not finished; it is ready to be criticised. These are the questions a senior engineer asks, in this order, and each of them is the subject of a later chapter:

1. Are the block aspect ratios sane? The CPU cluster at 2.00 mm × 1.59 mm is fine; at 2.60 mm × 1.22 mm it was not, because its tallest macro bank did not fit. Macro-driven shape constraints are Chapter 9.
2. Is the channel where the traffic is? 2.09 mm² of channel is worthless if it sits in the corner while the buses run across the middle. Bus and repeater planning is Chapter 11.
3. Can the pins get out? Count the interface signals per block and compare with the boundary length available at your usable layers. Pin and feedthrough planning is Chapter 13.
4. Does the MIB constrain anything unacceptably? Both NPU instances share one pin plan; if their neighbours differ, one instance will have a longer route. Chapter 13 again.
5. Where will the clocks cross? Four clocks and two blocks that share one of them means clock distribution must be planned across boundaries, not per block. That is Chapter 12.
6. Is the budget survivable? 190 / 150 / 210 ps looks balanced; whether the 150 ps channel share is realistic depends on the distance between the two block pins, which the floorplan has just fixed. Budgeting is Chapter 14.
7. What happens when the DDR PHY grows? Hard IP changes late. Ask now which direction it can grow in without redrawing the plan.

1.6 Failure modes and debugging

Every entry below follows the same five-part shape: symptom, likely cause, diagnostic check, correction, prevention. Read them once now and again after your first real planning session, when at least three of them will have happened to you.

The misleading one, in detail

The first row of Table 1.11 deserves its own walkthrough, because its apparent cause and its real cause point in opposite directions. Shaping fails. Two blocks overlap, one sits outside its parent, and the floorplan looks perfectly reasonable on screen. The obvious reading is that the core is too small — so you enlarge the die by 8 % and run again. It fails again, and now you also have more white space to justify.

The real cause is that one block had no target area and no target utilisation, so the shaper had nothing to size it from, and the two identical NPU instances had no block grid to align to. Neither of those is an area problem. Both are named directly by the shaping gate, in seconds, if you run it.

1.7 Hands-on mini lab

Goal

Produce a defensible die size and a justified partition for a small synthetic design, and prove that the design is ready for floorplan initialisation. No proprietary data and no completed floorplan are needed; the arithmetic is the lab.

Supplied assumptions

Average standard-cell area 0.350 µm²; SRAM macro 0.0320 mm² each; target block internal utilisation 0.75; core offset 0.10 mm per side; one clock at 1.25 GHz; the top-level glue must stay at the top level.

Steps

1. Compute the cell area, macro area and total area that must be placed. Show units at every step.
2. Compute a first core estimate at a target utilisation of 0.70, and state the square core side that follows.
3. Compute the area each module needs at 0.75 internal utilisation, and total the block shapes.
4. Decide the partition. Apply Figure 1.7 to every module and write one sentence of justification for each decision. Expect to divide one module and group two.
5. Choose a channel allowance consistent with keeping 0.10 M cells at the top level, and state the resulting core, die and core utilisation.
6. In a session with any small design open, list the available planning checks, then run the pre-floorplan gate and capture the log:

   icc2_shell> get_design_checks dp_*
   icc2_shell> check_design -checks {dp_pre_floorplan} \
                  -log_file reports/vega2_pre_fp.log

7. Read the summary and classify every line as error, warning or information, and — for each warning — as relevant or not relevant to floorplan initialisation.

Expected observations

• Cell area 1.645 mm² (4.70 M × 0.350 µm²), macro area 1.088 mm² (34 × 0.0320 mm²), so the area that must be placed is 2.733 mm².
• First core estimate at 0.70: 3.904 mm² → 1.976 mm square.
• Block shapes at 0.75: DSP core 0.761 mm² each, codec 1.896 mm², I/O bridge 0.169 mm², real-time clock 0.009 mm².
• u_codec needs about two and a half times the area of the largest other candidate: a division candidate.
• u_io_bridge and u_rtc together are 0.20 M cells: a grouping candidate.
• The two DSP cores are identical: one block reference, two instances.
• The pre-floorplan gate will complain if layer directions or tracks are absent — which, in a freshly set-up library, they often are.

Stretch task

Redo steps 1 to 5 with a target utilisation of 0.80 instead of 0.70, and with the codec growing by 15 % late in the project. Report the two die sizes side by side, and write two sentences on which risk you would rather carry: a larger die now, or a re-plan in month four. There is no single right answer — the exercise is to make the trade explicit, which is exactly what you will be asked to do in a real review.

1.8 Interview preparation

Sixteen questions, grouped by level. Read the question, answer it out loud, and only then read the model answer — the gap between the two is the part worth studying. Every model answer ends with what the question is really testing, because interviewers ask about design planning to find out how you think about tradeoffs, not whether you remember option names.

Beginner

Intermediate

Scenario and debugging

1.9 Chapter close

Sign-off checklist for this stage of planning

Key-concept flashcards

Compact glossary

Five-question self-check

1. A design has 6.4 M standard cells averaging 0.40 µm², plus 40 macros of 0.05 mm² each. What area must be placed, and what square core would a target utilisation of 0.75 imply?
2. Your partition leaves 0.25 M cells at the top level. Which floorplan style is now impossible, and why?
3. Name two things that change in the design database when you commit a module.
4. Two instances of one block need pins in different places to suit their different neighbours. What is the legal outcome, and what does that tell you about MIBs?
5. A readiness gate reports zero errors and forty warnings. What do you do next, and what have you not proved?

One-page recap

Where the next chapter goes, and why

You now know what a design plan contains, how to divide a netlist into blocks, how to size a core from measured area, and how to prove that a step is legal to run. Every one of those activities was described here as something you decide — and every one of them has to be typed into a tool that runs it, logs it, and lets you repeat it tomorrow without repeating the thinking.

That is the subject of Chapter 2. Before you can plan a real chip you need to be at home in the environment: the interfaces available to you, how commands are entered and interrupted, how to ask the tool about itself, how application options change its behaviour, how scripts and setup files make a session reproducible, where the command log lives when you need to reconstruct what you did, and how work is run in parallel and monitored when a design is too large for one process. Those are not administrative details. They are the difference between an engineer who can do this once and an engineer who can do it every day, on a design too big to hold in their head.