Preparing the Design in ICC2: A Mentor Guide

Opening promise

What you will be able to do after this chapter

By the end of this chapter you will be able to take a gate-level netlist, its libraries, and its power and timing intent, and turn them into a design library state that IC Compiler II (ICC2) considers linked, constrained, and safe to floorplan — and you will be able to prove that state is sound using the tool's own reports, not just your impression of it.

Concretely, you will be able to: set up a design library and its reference libraries with a search path that resolves the way you intend; read in a Verilog netlist and a floorplan DEF (Design Exchange Format, the file that carries physical geometry) and explain what each command actually changed; load and commit a UPF (Unified Power Format) power intent and recognize the difference between a design that merely has UPF text attached to it and one whose power intent has been committed and checked; put a first, defensible set of physical and optimization constraints in place before anything gets placed; and use the Early Data Check Manager to decide, on purpose, which incomplete-data problems stop you cold and which ones you accept as tracked technical debt.

None of this is about memorizing commands. It is about building a mental model of what "the design is ready" actually means inside ICC2, so that when something goes wrong three stages later, you already know which of these foundations to go back and re-check first.

Why this stage matters

Why this stage matters in the full flow

Every later stage in this guide — floorplanning, placement and optimization, clock tree synthesis, routing, chip finishing, hierarchical implementation, and ECO — assumes that the design it is working on is a known quantity: fully linked, with technology and libraries resolved, with scenarios and clocks defined, with power intent committed, and with a first set of physical and optimization guardrails already in place. Preparing the Design is where that assumption is either earned or quietly left unearned.

The cost of skipping steps here does not show up here. It shows up as a placer that silently ignores a keepout you thought you had defined, a clock tree that estimates the wrong latency because a clock-gating cell was never told to stop being ideal, or a signoff timing run that disagrees with everything ICC2 reported because a scenario was never actually made active. Nearly every "mystery" bug a physical design engineer chases three weeks into a project traces back to an assumption made, and never verified, during this stage.

Stage boundary

What enters, what must leave

What does not leave this stage: a floorplan shape, macro placement, or power network. Those belong to the next chapter, Floorplan. If a DEF file already carries floorplan information, this chapter shows you how to bring it in safely, but designing that floorplan from nothing is out of scope here.

Prerequisite knowledge

What you should already be comfortable with

• Reading a gate-level Verilog netlist well enough to recognize a module, an instance, a port, and a net.
• The idea of a standard-cell library and a technology file, even if you have not yet used one inside a place-and-route tool.
• Basic Tcl (Tool Command Language): variables, lists, and running a command with options from a shell prompt. ICC2's shell, icc2_shell, is a Tcl interpreter with design-specific commands added to it.
• What setup and hold timing checks are, in outline. This chapter uses those terms but does not re-derive them; the Clock Tree Synthesis chapter goes deeper.

You do not need prior place-and-route tool experience. Where this chapter uses a term for the first time, it defines it before relying on it.

Learning objectives

By the end of this chapter, you will be able to…

• Explain the difference between a design library, a block, and a reference library, and set the search path so that library resolution is deterministic.
• Import a gate-level netlist and a DEF floorplan, and verify what each import step actually changed using ICC2's own reports.
• Load, commit, and verify UPF power intent for a multivoltage design, and explain what changes when a design is single-voltage instead.
• Set up modes, corners, and scenarios well enough to know which combinations are active for which kind of analysis.
• Define keepout margins, placement blockages, and preservation attributes with the correct strength for each, and explain which flow stages honor each one.
• Configure the Early Data Check Manager to make a conscious choice, per check, between stopping the flow and tolerating a tracked gap.
• Produce and read the reports that prove the design is ready to floorplan, rather than assuming it from a lack of error messages.

Beginner mental model

Think of it as moving into an unfurnished apartment

Analogy. Imagine you are moving into a new apartment before you have furniture. You cannot just carry boxes in and call it done. You first confirm the lease (the technology and reference libraries), check which rooms exist and what their walls are made of (the linked block and its hierarchy), get the utilities turned on and verified — power, water, and their meters (power intent, committed and checked) — and only then do you start deciding which rooms are off-limits for the movers and which ones need extra padding on the corners (physical and optimization constraints). You do not need every piece of furniture placed yet; that is next chapter's job. What you need is a space where nothing unexpected will happen when the movers start working.

Engineering translation. "Confirming the lease" is creating or opening a design library with the right reference libraries and technology bound to it. "Checking the rooms" is reading and linking the Verilog netlist so every instance resolves to a real cell or a real subdesign, with no silent black boxes. "Utilities turned on and verified" is loading UPF, committing it, and running check_mv_design — or, for a single-voltage design, simply trusting the default power domain the tool created for you and connecting PG (power and ground) nets. "Rooms off-limits" is keepout margins and placement blockages; "extra padding" is preservation attributes like dont_touch that tell optimization to leave certain cells and nets alone.

Readiness checklist

Before you open icc2_shell

• You know the absolute or relative locations of every input file, and you have a directory layout that will not require a fragile search_path.Evidence: a written manifest listing each file and its path, checked into your working area.
• You know whether this design is single-voltage or multivoltage, and if multivoltage, you have the UPF file in hand.Evidence: a one-line statement of voltage domains from the power architecture owner.
• You know which modes, corners, and scenarios this design is expected to have, even before you create them.Evidence: a scenario table from the timing owner, or your own draft of one.
• You know whether a floorplan DEF already exists for this block, or whether floorplanning is still ahead of you.Evidence: confirmation from design planning, one way or the other — not an assumption.

Concepts in dependency order

Building the foundation, one dependency at a time

The topics below are ordered so that each one only depends on what came before it. Skipping ahead usually still "works" in the sense that the shell accepts your commands — but the resulting design state will not mean what you think it means.

1. Flow boundary and the database mental model

ICC2 keeps your design as an in-memory database, organized as design libraries containing blocks, plus the reference libraries and technology data those blocks depend on. A block is a specific version of a design — the current top-level netlist, or a subdesign, at a specific point in the flow. Nothing you do to files on disk affects this in-memory database until you explicitly read it in; nothing you do to the in-memory database reaches disk until you explicitly save it.

This matters because the phrase "the design" is ambiguous in casual conversation but never ambiguous to the tool. When someone says "the design doesn't have that constraint," the precise question is: is the constraint missing from the file, missing from the current in-memory block, or present in memory but not yet saved? Each of those is a different bug with a different fix.

2. Tool start and reproducibility

Every ICC2 session starts from a working directory and a set of setup files you source or pass at invocation. Two things make a session reproducible: a deterministic search path (covered next), and a habit of capturing what you ran. A minimal run manifest is nothing more than a text file recording the tool version, the working directory, and the exact sequence of setup and command files you sourced, in order.

Relative paths are the most common source of "it worked on my machine." A relative path resolves against the working directory the shell happened to be started from, not against wherever your script file lives. If two engineers invoke the same script from two different directories, a relative path in that script can silently resolve to two different files.

3. Defining the search path

When ICC2 needs a file specified with a relative path or with no path, it searches the directories listed in the search_path Tcl variable, left to right, and uses the first match it finds. You set the whole list with set_app_var search_path {…}, or add to the front or back of the tool's default search path (the directory you invoked the tool from) with Tcl's lappend.

icc2_shell> lappend search_path ./mylibdir

Order is the whole point of this mechanism. If two directories in your search path both contain a file with the same name, the leftmost directory wins silently — there is no warning that a second candidate existed.

Figure 3 — Search path resolution example

4. Design and reference libraries

A design library is a container for one or more blocks plus shared technology data. A reference library is a library of cells that a design library uses but does not own — standard cells, hard macros, and physical-only cells such as pads and fillers. A design library can itself serve as a reference library for whatever is built on top of it, which is exactly how hierarchical implementation composes blocks in a later chapter.

Figure 4 — Design library, block, and reference library model

You create, open, query, save, and close a design library with create_lib, open_lib, current_lib, save_lib, and close_lib. Creating a library makes it the current library in memory only; nothing reaches disk until save_lib.

icc2_shell> create_lib ../my_lib_dir/my_libA
{my_libA}
icc2_shell> open_lib my_libA
/* loads the library and every reference library it points to */
{my_libA}

You specify the reference library list either at creation time, with the -ref_libs option of create_lib, or afterward with set_ref_libs. If a reference library moves, use set_ref_libs -rebind to re-resolve the paths against the current search_path. Note that rebinding the library's reference list does not automatically rebind blocks already loaded from it — use link_block -rebind for that.

5. Library readiness

Having a library bound is not the same as having a library that is safe to build with. Two checks matter before you move on: which library cells the tool is allowed to use, and whether those cells are physically legal to place given your technology's pin-access rules.

By default ICC2 can use every cell in every bound library for optimization and clock tree synthesis. Use set_lib_cell_purpose -include | -exclude to restrict specific cells to specific purposes (all, cts, hold, optimization, or none). A cell carrying a dont_use attribute is automatically excluded everywhere, equivalent to -include none.

icc2_shell> set_lib_cell_purpose -include none [get_lib_cells HVT_lib/CLK*]
icc2_shell> set_lib_cell_purpose -include cts   [get_lib_cells HVT_lib/CLK*]

Separately, you can restrict which library cells are eligible for specific blocks or hierarchies with set_target_library_subset, then enable the restriction with the opt.common.enable_target_library_subset_opt application option. This is how you keep a low-Vt library confined to one voltage-sensitive subblock instead of letting it leak into the rest of the chip.

The Pin Access Checker (PAC) utility is a separate, earlier-stage check aimed at library developers: it verifies that a cell's pins are physically reachable given real placement, legalization, and routing rules, using create_pin_check_lib and check_libcell_pin_access. As an implementation engineer you will not usually run PAC yourself, but you should recognize its vocabulary — pin accessibility — because a library that fails PAC in development will show up to you later as unexplained legalization displacement.

6. Import logical design

With the design library open and its reference libraries bound, you read the gate-level netlist with read_verilog. By default the tool creates a block in the current library, determines the top-level module as whichever module is not instantiated by anything else in the files you gave it, and uses that module's name as the block name. It also creates a default power domain for the block — the single-voltage starting point described in Setting up multivoltage designs below.

icc2_shell> read_verilog nimbus8_top.v nimbus8_core.v
/* top module auto-detected: the module nothing else instantiates */

Figure 5 — Import and link funnel

You manage blocks explicitly with create_block, open_block, current_block, save_block, and close_blocks. In most single-block sessions you will not touch these directly — read_verilog creates the block for you — but you need them the moment you work with more than one block in a library, which becomes routine in the Hierarchical Implementation chapter.

Rollback point: before you read in a netlist over an existing block, save the current library state if it is worth keeping. read_verilog into an already-open design is not allowed — the design must not already exist or be closed — which is itself a small safety rail against accidentally overwriting work.

7. Import or create physical context

A floorplan carries the core area and shape, port locations, macro locations and orientations, blockages, site rows, routing tracks, and any preroutes. If a floorplan already exists for your block — commonly handed off from an earlier project phase or a design-planning pass — you bring it in as a DEF file with read_def. If no floorplan exists yet, you defer that work entirely to the next chapter, Floorplan, which builds one from nothing.

icc2_shell> read_def nimbus8_core.def

By default read_def annotates the current block, preserves existing floorplan information rather than discarding it (incremental mode), and uses rule-based name matching so that small naming differences — hierarchical separators, bus notation — do not cause false mismatches between the DEF and the block. To discard existing floorplan data before applying a new DEF, use -no_incremental. To require exact name matches instead of rule-based matching, set the file.def.rule_based_name_matching application option to false.

Only a specific set of physical constraints are extracted from a DEF file: placement area, port locations, cell locations, placement blockages, site rows, routing tracks, placement bounds, routing blockages, and preroutes. Objects in the DEF that do not already exist in the block are ignored by default, except PG (power and ground) objects. Use -add_def_only_objects to allow the tool to create new cells, nets, or ports from DEF-only content when you explicitly want that.

8. Power intent and multivoltage readiness

Every block gets a power domain the moment it is read in. For a single-voltage design, that is the end of the story: read_verilog creates a default power domain covering the whole core area, and you move on. A multivoltage design replaces that default with real power domains, voltage areas, and supply connectivity, defined in a UPF file and made authoritative through a specific load-and-commit sequence.

Figure 6 — Single-voltage vs. multivoltage power setup

The load-and-commit sequence is: read the UPF with load_upf; optionally read a Design Compiler name-mapping file with read_name_map if you are using the golden-UPF flow; optionally verify consistency and preview PG-conflict resolution with resolve_pg_nets -check_only; then commit with commit_upf, which performs global UPF consistency checks, resolves PG conflicts among the netlist, floorplan, and UPF specification, and associates power strategies with any multivoltage cells already present. Finally, confirm the associations with report_mv_path.

icc2_shell> load_upf nimbus8.upf
icc2_shell> commit_upf
icc2_shell> report_mv_path

Once power intent is committed, logical PG connections between supply nets and the power, ground, and tie-off pins on every cell must exist. Use connect_pg_net -automatic to derive connections from the UPF specification, or connect_pg_net -net NET_NAME [get_pins ...] for manual control. Single-voltage designs still need this step — the "UPF specification" they resolve against is just the default domain read_verilog created.

Multivoltage designs place power-domain cells inside voltage areas, defined with create_voltage_area -power_domains … -region …. A voltage area behaves like an exclusive move bound: cells in the domain must stay inside it, and everything else must stay out. Guard bands, set with the -guard_band option, add a hard keepout ring around the voltage area's effective boundary so that adjacent domains cannot short at the edge.

Figure 7 — Voltage area and guard band

Finish with check_mv_design to verify the design has no multivoltage rule violations, and use the reporting commands — report_mv_design, report_mv_cells, report_voltage_areas, and related commands — to confirm the domains, voltage areas, and multivoltage cells are what you expect before moving on.

9. Timing setup: modes, corners, and scenarios

Timing constraints describe what your design must achieve, and clocks are the essential part of that description: everything else about a timing path is measured relative to when a clock edge arrives. When you define clocks, ICC2 automatically constrains the paths between the registers those clocks drive. You then layer exceptions — false paths, multicycle paths — and boundary constraints — input and output delays — on top of that default behavior.

A block can operate under different conditions — voltage, temperature — and in different functional modes. ICC2 represents each set of operating conditions as a corner, each functional mode as a mode, and a specific combination of the two, used for one purpose of timing analysis and optimization, as a scenario.

Figure 8 — Mode × corner = scenario matrix

ICC2 performs on-chip variation (OCV) analysis by default: for a setup check it applies maximum delays to the launch clock path and data path and minimum delays to the capture clock path. For a hold check it reverses that, using minimum delays on the launch side and maximum on the capture side. You do not configure this behavior in this chapter — you only need to know it is happening so that a "surprising" number of paths reported later does not surprise you.

9a. Logical design rule constraints

Minimum capacitance, maximum capacitance, and maximum transition are technology-specific limits your design must respect regardless of timing, power, or area goals — the tool treats them as a higher priority than those optimization objectives. Library cells already carry technology-appropriate defaults; you tighten them with set_min_capacitance, set_max_capacitance, and set_max_transition, and remove a user override with the matching remove_* command. After optimization, report_constraints -max_transition and its siblings show remaining violations.

9b. Controlling clock-gate latencies

Before clock tree synthesis, ICC2 treats clocks as ideal — zero delay through the network — because real network delay is unknown until the tree exists. For a design with clock gating, that idealization hides a real asymmetry. The clock-network delay at a clock-gating cell differs from the delay at the registers it gates, which tightens the effective setup margin at the gating cell's enable input.

Figure 9 — Clock gating latency before CTS

10. Physical constraints for placement and legalization

Four constraint families shape where cells may legally land, each with a different strength and a different set of stages that honor it. Getting the strength right matters as much as getting the geometry right.

Figure 10 — Physical constraints gallery

icc2_shell> create_keepout_margin -outer {10 10 10 10} nimbus8_ddrphy
icc2_shell> create_placement_blockage -boundary {{120 75} {230 200}} -type hard_macro

11. Controlling the optimization of cells, nets, pins, and ports

Before any placement or optimization command runs, you decide what optimization is not allowed to touch. Four mechanisms cover almost every situation, and they compose in a specific precedence order.

Figure 11 — Preservation scope: four locks

icc2_shell> set_dont_touch [get_cells U_DDR_PHY] true
icc2_shell> set_size_only [get_cells U_CORE/reg_bank_*] true
icc2_shell> set_dont_touch_network [get_clocks CPU_CLK] -clock_only

Two more controls round out this stage: set_auto_disable_drc_nets selectively turns off design rule checking on clock, constant, or scan nets where DRC (design rule checking) fixing would be counterproductive; and set_allow_new_cells false, alongside a create_voltage_area_rule -allow_new_cells false variant for voltage areas, stops optimization from inserting new cells into a hierarchical cell or domain you consider closed.

12. Preroute, power, and routing-resource setup

This section is a setup contract, not a routing tutorial — the Routing and Postroute Optimization chapter covers the router itself. What belongs here is telling optimization what resources it will have to work with before it starts using them.

Routing layer constraints. Set global minimum and maximum routing layers with set_ignored_layers -min_routing_layer -max_routing_layer, which by default acts as a soft constraint for routing and a hard constraint for RC estimation and congestion analysis. Net-specific overrides use set_routing_rule; clock-tree-specific layer constraints use set_clock_routing_rules, which can target a clock's root, internal, or sink nets separately. Set these before placement — they feed RC estimation and congestion analysis from the start, not only routing at the end.

icc2_shell> set_ignored_layers -min_routing_layer M2 -max_routing_layer M8

Preferred routing direction. Every routing layer needs a preferred direction. Cell libraries usually supply this, but you can set or override it per block with set_attribute [get_layers M5] routing_direction vertical.

Parasitic estimation. Two techniques improve how closely preroute optimization's RC estimates track the postroute result: global-route-layer-based (GRLB) estimation, enabled with opt.common.use_route_aware_estimation, and route-driven estimation (RDE), enabled with opt.common.enable_rde and automatically on by default below 16 nm. Pick one path and use it consistently through every preroute optimization step — mixing them across stages produces inconsistent RC assumptions from one command to the next.

Via ladders. A via ladder is a stacked via from a pin layer up into the routing layers, used on timing-critical or electromigration-sensitive pins. Define candidates per library pin with set_via_ladder_candidate, in priority order, then enable automatic insertion with opt.common.enable_via_ladder_insertion.

Power setup. If you plan dynamic-power-aware placement or optimization, annotate switching activity first — either read_saif or set_switching_activity — and enable the relevant scenario status with set_scenario_status -dynamic_power true or -leakage_power true. Without an annotated activity, the tool falls back to a default toggle rate propagated from primary inputs, which is a reasonable estimate, not a substitute for real activity when power is a hard goal.

13. Early data checks and strategy settings

Early in a design cycle, some of your data will be incomplete or wrong, and you will still need to make forward progress for exploration purposes. The Early Data Check Manager (EDC) is how you make that a deliberate decision instead of an accident. For each named check you choose a strict policy, which stops the flow with an error, or a lenient policy, which tolerates the failure, logs it, and continues.

Figure 12 — Early Data Check Manager policy decision

icc2_shell> set_early_data_check_policy -policy strict -check place.coarse.missing_scan_def
icc2_shell> create_placement
/* Error: No valid scan def found. Flow stops here by design. */

report_early_data_checks shows the policy, strategy, and fail count for each check. The companion command get_early_data_check_records returns a Tcl collection of violations for use in other commands; write_early_data_check_config saves your policy settings for reuse; and remove_early_data_check_records clears logged violations before another iteration.

Separately, mega-switch commands apply a coordinated bundle of settings across placement, legalization, routing, and extraction in one call. That is useful once you know your technology node or QoR priority: set_technology -node 7 applies advanced-node-specific defaults; set_hpc_options -core … -stage … applies settings tuned for a named high-performance core design at a specific flow stage; and set_qor_strategy -stage pnr -metric timing | leakage_power | total_power applies the setting bundle for a specific QoR priority. Use -report_only or -diff_only on these commands to see what they would change before you commit to them.

Command cards

The commands worth knowing cold

Every card below follows the same eight-point shape, and every syntax line has been checked against the ICC2 Tcl command reference for this release. Where your installed release differs, trust man <command> over this page.

Libraries and search path Importing the design Power intent Physical constraints Optimization controls and data checks

Worked example

Nimbus‑8: preparing a teaching design end to end

Nimbus‑8 is a fictional SoC block used across this guide for continuity. Its numbers are teaching data, not measured silicon: 9.90 million standard cells, 72 SRAM macros, one DDR PHY hard macro, a 3.20 mm × 3.20 mm core, and four clocks — CPU at 1.60 GHz, NPU at 1.10 GHz, ISP at 800 MHz, and APB at 200 MHz. This chapter works the single-voltage path first, then shows the multivoltage delta on a smaller lab design, Lyra‑2, in the mini lab below.

Step 1 — directory manifest and search path

/* manifest: nimbus8/{rtl,libs,tech,def,upf,scripts} — checked into project area */
icc2_shell> set_app_var search_path {. ./libs ./tech ./def}

Step 2 — design library and reference libraries

icc2_shell> create_lib nimbus8_lib \
   -technology n8_tech.tf \
   -ref_libs {StdCells_rvt.ndm StdCells_lvt.ndm SRAM_macros.ndm PhysicalOnly.ndm}
{nimbus8_lib}
icc2_shell> report_ref_libs
Name          Path                    Location
------------------------------------------------------------
*+ StdCells_rvt  StdCells_rvt.ndm      /proj/nimbus8/libs/StdCells_rvt.ndm
*+ StdCells_lvt  StdCells_lvt.ndm      /proj/nimbus8/libs/StdCells_lvt.ndm
*  SRAM_macros   SRAM_macros.ndm       /proj/nimbus8/libs/SRAM_macros.ndm
*  PhysicalOnly  PhysicalOnly.ndm      /proj/nimbus8/libs/PhysicalOnly.ndm
"*" = open   "+" = has technology

Proof: every reference library shows *. If StdCells_rvt or StdCells_lvt were missing the +, technology resolution would be ambiguous later — investigate before continuing.

Step 3 — import the netlist

icc2_shell> read_verilog -design nimbus8_top nimbus8_top.v nimbus8_core.v nimbus8_uncore.v
/* top module auto-detected as nimbus8_top: nothing else instantiates it */
icc2_shell> current_block
{nimbus8_top}

Proof: a link or black-box report shows zero unresolved references against the 9.90 million-cell teaching count. Any nonzero black-box count is a stop-and-investigate signal, not a warning to note and continue past.

Step 4 — import the floorplan

icc2_shell> read_def -syntax_only nimbus8_core.def
icc2_shell> read_def nimbus8_core.def
icc2_shell> check_duplicates -remove

Proof: the layout view (see Visual inspection guide) shows a 3.20 mm × 3.20 mm core with 72 SRAM macros and the DDR PHY macro at their DEF-specified locations.

Step 5 — power intent (single-voltage path)

icc2_shell> connect_pg_net -automatic
/* single-voltage: resolves against the default domain read_verilog created */

Proof: a PG connectivity report shows zero cells with an unconnected power or ground pin.

Step 6 — timing setup

/* four clocks; two active teaching scenarios, explained before use */
/* func_ss_0p72v_125c: functional mode, slow-slow corner, 0.72V, 125C — worst-case setup */
/* func_ff_0p88v_m40c: functional mode, fast-fast corner, 0.88V, -40C — worst-case hold */
icc2_shell> set_scenario_status -active true func_ss_0p72v_125c
icc2_shell> set_scenario_status -active true -setup true func_ss_0p72v_125c
icc2_shell> set_scenario_status -active true -hold true func_ff_0p88v_m40c

Proof: report_scenarios shows both scenarios active with the intended setup/hold roles, and no unconstrained endpoints on the CPU, NPU, ISP, or APB clock domains.

Step 7 — physical and optimization constraints

icc2_shell> create_keepout_margin -outer {10 10 10 10} nimbus8_ddrphy
icc2_shell> create_placement_blockage -boundary {{0 0} {3200 60}} \
   -type hard -name pad_ring_bottom_margin
icc2_shell> set_dont_touch [get_cells nimbus8_ddrphy] true
icc2_shell> set_ignored_layers -min_routing_layer M2 -max_routing_layer M8

Proof: get_placement_blockages and the layout view both show the keepout and the pad-ring margin at the coordinates intended, and report_dont_touch lists the DDR PHY macro.

Step 8 — early data check policy

icc2_shell> set_early_data_check_policy -policy strict -check place.coarse.missing_scan_def
icc2_shell> set_early_data_check_policy -policy lenient -check mv.upf.*
/* lenient here only because Nimbus-8's first pass is deliberately single-voltage */

Step 9 — checkpoint

icc2_shell> save_lib nimbus8_lib
Saving library 'nimbus8_lib'
1

Checkpoint / rollback point: this saved library is the point every later chapter, and every failed experiment in this one, should be able to return to. Treat the return value 1 as confirmation, not decoration — a failed save returns a different, checkable status.

Visual inspection guide

What to look for in the GUI

No screenshots are supplied here — your installed release's GUI layout will not match a static image for long, and the habit of looking is more durable than the habit of matching a picture. After each step above, open the layout view and check:

• After read_def: does the core outline match the 3.20 mm × 3.20 mm teaching dimension, with 72 SRAM macros and the DDR PHY macro visible at fixed locations, not floating at the origin?
• After defining keepout margins and blockages: do the shaded regions appear exactly where you specified them, with no overlap you did not intend?
• After create_voltage_area (multivoltage path): does the voltage area's guard band render as a visually distinct ring outside the placeable region, not merged into it?
• Zoom to a single macro's edge and confirm the keepout margin distance visually matches the numeric value you set — a margin defined in the wrong units is a classic, easy-to-miss mistake.

Reports and how to read them

Reading proof, not just running commands

Stage completion checklist

The Preparing the Design exit gate

This is the same checklist a careful reviewer would use before approving a handoff to Floorplan. Every item names its evidence; "looks fine" is not evidence.

• All intended references resolve.Evidence: zero unexplained black boxes in the post-read_verilog link report.
• Top design and hierarchy match expectation.Evidence: current_block name and instance count match the design manifest.
• No unexplained black boxes or unresolved references remain.Evidence: black-box report reviewed line by line, not just for a zero count.
• Units, technology, sites, layers, and routing directions are coherent.Evidence: report_ref_libs technology flags and layer routing_direction attributes reviewed against the technology file.
• Scenarios and clocks exist, and the intended analysis roles are active.Evidence: scenario status report showing setup/hold/leakage/dynamic-power flags matching the plan.
• Unconstrained paths are investigated.Evidence: an unconstrained-endpoints report with zero unexplained entries.
• UPF and power-domain checks pass, where applicable.Evidence: check_mv_design clean, or every finding tracked in the issue register.
• PG connectivity intent is understood.Evidence: PG connectivity report shows zero cells with unconnected power or ground pins.
• Physical constraints are present, scoped, and justified.Evidence: every keepout and blockage has a name and a one-line reason a reviewer can check.
• Cell availability, legal placement, and pin access checks are reviewed.Evidence: set_lib_cell_purpose and target-library-subset settings documented against the plan.
• Early data check results are resolved or formally tracked.Evidence: report_early_data_checks fail count matches the issue register exactly.
• Saved checkpoint, logs, reports, and manifest are reproducible.Evidence: a second engineer can open_lib your saved checkpoint and reproduce the same reports.

Mini lab

Lab: Lyra‑2, a small multivoltage design

Nimbus‑8 is too large to hand-trace in a short lab. Lyra‑2 is a smaller teaching design used here specifically to make the single-voltage-to-multivoltage delta concrete: two power domains, PD_ALWAYS_ON and PD_SWITCHED, on a 0.60 mm × 0.60 mm core with roughly 40,000 standard cells. All numbers are synthetic.

Setup

• A design library with Lyra‑2's Verilog, reference libraries, and a lyra2.upf file defining the two power domains.
• A DEF file with a floorplan already defined, including a rectangular region intended for PD_SWITCHED.

Tasks

1. Create the design library, import the netlist, and import the floorplan, following Steps 1–4 of the worked example.
2. Load and commit the UPF, then confirm the associations with report_mv_path.
3. Define a voltage area for PD_SWITCHED over the region reserved in the floorplan, with a guard band of 2 on every side.
4. Run check_mv_design and resolve or document every finding.
5. Save the checkpoint and write a one-paragraph handoff note as if for a reviewer who has not seen this lab.

Expected observations

The voltage area's effective placement region should be visibly smaller than the region you specified in -region, because the guard band eats into the effective boundary without shrinking the placeable area from the inside — recheck Power intent and multivoltage readiness if that distinction is not intuitive yet. check_mv_design on a first attempt commonly flags a PG connectivity gap if connect_pg_net was run before commit_upf instead of after; if you see that finding, it is expected, and fixing the command order is the task, not a tool bug.

Cleanup

Close the library with close_lib once you have confirmed the saved checkpoint reopens cleanly with open_lib in a fresh session. Do not leave two engineers' work sharing one open, unsaved library state.

Interview questions

25 questions worth being able to answer cold

Glossary

Terms used in this chapter

Black box

An instance in the netlist whose reference could not be resolved to a real library cell or subdesign, treated as an opaque placeholder.

Checkpoint

A saved, reopenable state of a design library on disk, written with save_lib.

Corner

A named set of operating conditions — voltage, temperature, process — used in timing analysis.

Current library / current block

The library or block that unqualified commands act on by default.

DEF

Design Exchange Format; a standard file format carrying physical floorplan and layout information.

Design library

An on-disk container for one or more blocks and their shared technology data.

Early Data Check Manager (EDC)

The subsystem that lets you set a strict or lenient policy per named data-completeness check.

Guard band

A hard keepout ring attached to a voltage area's boundary, included in its effective boundary but excluded from its placeable area.

Keepout margin

A region, inner or outer, around a fixed object in which no other cell may be placed.

Linking

Resolving every instance in a netlist to a real cell reference and flagging what cannot be resolved.

Mode

A named functional operating state of the design, used together with a corner to define a scenario.

Placement blockage

A named region with a declared strength (hard, soft, partial, category, and related variants) limiting what may be placed inside it.

Power domain

A logical grouping of cells sharing the same supply and power state, defined in UPF for multivoltage designs.

Reference library

A library of cells that a design library points to and uses, but does not own.

Scenario

A named combination of one mode and one corner, used for a specific type of timing analysis and optimization.

Search path

The ordered list of directories, held in the search_path Tcl variable, the tool searches for relative or unqualified file names.

UPF

Unified Power Format; the file format carrying power intent — domains, supplies, and multivoltage strategy.

Voltage area

A physical placement region associated with one or more power domains, behaving like an exclusive move bound.

Self-check questions

Test yourself before moving on

1. You have two reference libraries with a cell of the same name in different directories, both listed in search_path. Which one does the tool use, and how would you confirm it?
2. Explain, in one sentence each, the difference between a hard blockage, a soft blockage, and a partial blockage.
3. Why is connect_pg_net handled differently for single-voltage and multivoltage designs?
4. A colleague sets a keepout margin on a hard macro using -tracks_per_macro_pin and also passes -type soft. What actually happens, and why?
5. Name two application options mentioned in this chapter that control routing-layer constraint strength, and state what each one's default constraint strength is.
6. Why does this chapter insist that a lenient Early Data Check policy still requires an entry in the issue register?

Answers

1. The library found first in search_path, scanning left to right. Confirm with report_ref_libs, checking the path resolved for each library name.
2. Hard: honored through placement, legalization, optimization, and CTS. Soft: honored during coarse placement only, by default. Partial: a density cap during coarse placement only, with no effect on legalization or optimization.
3. Multivoltage designs get PG conflicts resolved automatically as part of commit_upf; single-voltage designs never run that commit sequence, so they need an explicit resolve_pg_nets pass first.
4. The derived margin from -tracks_per_macro_pin is always hard; the -type soft setting is ignored for a derived margin on a hard macro.
5. route.common.global_min_layer_mode and route.common.global_max_layer_mode, both defaulting to a soft constraint for routing unless set to hard or allow_pin_connection.
6. Because "lenient" changes the tool's response to a failing check, not the underlying data problem. Without a tracked, owned entry, a deliberately tolerated gap quietly becomes a forgotten one.

Part summary

What to carry forward

Sign-off checklist

Before you call this stage done

This is the same twelve-item exit gate from earlier in this chapter, repeated here as the final gate before handoff. See Stage completion checklist for the full evidence requirements attached to each item.

• All intended references resolve, with zero unexplained black boxes.
• Top design and hierarchy match the design manifest.
• Units, technology, sites, layers, and routing directions are coherent with the technology file.
• Scenarios and clocks exist, with intended analysis roles active.
• Unconstrained paths are investigated, not merely noticed.
• UPF and power-domain checks pass, or every finding is tracked.
• PG connectivity is complete and understood.
• Physical constraints are named, scoped, and justified.
• Cell availability, legal placement, and pin access are reviewed.
• Early data check results are resolved or formally tracked in the issue register.
• A saved checkpoint, with logs, reports, and manifest, reproduces cleanly for a second engineer.

Last word

Last word and bridge to Floorplan

Everything in this chapter was about proving a starting point, not building anything visible. That can feel unsatisfying — there is no picture of a chip to show for it yet. But every later chapter in this guide spends less time fighting mysterious failures in direct proportion to how rigorously this one was done. When a clock tree three chapters from now estimates a strange latency, or a macro keeps landing somewhere unexpected during placement, the first productive move is almost always back here: is the library resolution really what I think it is, is the power intent really committed, is the scenario really active.