Design Data Import, Sanity Checks and Export: a judged first database

Why this chapter matters in a real project

The previous chapter gave you a session that starts as intended. A session is not a design. Before anyone starts the floorplan, somebody must say, with evidence, which design was loaded. They must also say from which files, under which timing assumptions, and how far that claim can be trusted.

A project hands you a package. A netlist comes from the synthesis team and libraries from the technology provider. Constraint files come from the block owner, and an email says "the usual corners". You are asked to bring it into Innovus and confirm that it is ready for floorplanning.

Every later stage inherits the database that the import creates. Suppose the import loaded the wrong top module, an incomplete library or the wrong timing views. The floorplan will still look plausible. The cost appears much later, when it is expensive to undo.

So the question is not "how do I run init_design". It is this: what must be true about the inputs, the configuration and the imported database before floorplanning can begin? And how do we find out? The command is one line. The judgment around it is the skill.

Prerequisites

• Understanding the Innovus Environment and Session: you can start a known session, keep a log, and tell a request from an observation.
• Basic Linux: a terminal, Bash, a text editor and file permissions.
• You do not need to know static timing analysis in depth. This chapter teaches just enough to judge a constraint set.
• You do not need a licensed tool for the teaching sections or the evidence-reading exercises. Only the lab needs one.

Learning objectives

1. Explain what each input of an import contributes, what it leaves undescribed, and who owns it.
2. Review a design handoff before launch and decide, with a reason, whether to proceed or stop.
3. Reconcile the netlist, the physical library and the timing library for the same cell.
4. Read a small constraint set and a multi-mode multi-corner (MMMC) configuration, and trace each analysis view back to its source files.
5. Explain every line of an init_design configuration and tell the alternative initialization routes apart.
6. Interpret representative post-import evidence, choose an action, and state what a clean report still leaves unproven.
7. Tell a native checkpoint from exported files, and say what each one can and cannot hand to the next person.

Figure 1 shows the whole chapter on one page. Come back to it whenever you lose your place.

Two short names appear in it and in the table that follows. LEF (Library Exchange Format) holds the physical cell data. RC (resistance and capacitance) data lets the tool estimate wire delay.

Data import on one page

Where the chapter sits, and its six learning stages

What to notice: Each stage ends with a sentence you should be able to say before moving on. Judging the evidence (stage 5) only means something against what stages 1 to 4 said the inputs should be.

1  What this chapter is for, and how it is organized

The chapter stops before floorplanning. Later stages appear only as context, never as products of a first import. The top row of Figure 1 shows this position: a known session comes in, and a checked, saved first database goes out.

1.1  The learning roadmap

The roadmap gives the learning order. The lab follows the operational order. Stages 1 to 3 need no tool. Performing stages 4 and 5 on real data needs a licensed tool and approved inputs.

1.2  Two ways to read this chapter

Real execution needs a licensed Innovus in the Legacy UI, the original Innovus command set. Understanding the Innovus Environment and Session teaches it. You also need an approved design, library and technology package. This chapter does not provide either.

1.3  How examples are labeled

One invented design runs through all examples: demo_top. It has two registers and three instances of a small module alu_slice; the third instance is a bypass path. It also has its own libraries, files, modes and corners.

2  Reading a design handoff

A handoff is a set of promises made by different people. Before you launch anything, you read the promises and decide which ones you can check. If you cannot say who delivered an input and what it describes, you cannot tell which one to suspect later.

2.1  A realistic arrival

The synthesis engineer sends demo_top.v. The library team points to a release directory. It holds a technology LEF, a standard-cell LEF, a memory-macro LEF and Liberty libraries at two corners. The block owner sends func.sdc and test.sdc.

One email lists the supplies as VDD and VSS. Another says the scan chains are not stitched yet. Someone mentions that the memory vendor "re-released" the macro last week.

Each fact matters and none is verified. The first job is not to launch. It is to record, for each item, what it is meant to be and who owns it. Also record how you will inspect it. The dependencies between these deliveries appear in Figure 2.

A design handoff and what depends on what

Separate deliveries, joined by the MMMC view file and the import configuration

What to notice: Some inputs name other files. Access to the top-level file does not guarantee access to the files it refers to.

2.2  What must be established before launch

Before the first command, answer these questions from the package and from the people who delivered it.

1. Which design revision, and which top module? A netlist directory may hold several versions and several candidate tops. The revision and the top name come from the design owner, not from a guess.
2. Which technology and library release? Use the combination your project has approved as compatible. A LEF from one release and Liberty files from another can each be valid and still disagree.
3. Which modes does the design need? A functional mode and a test mode, or one mode? The answer decides how many constraint files you should see.
4. Which corners are approved for analysis? The project, not the tool, picks the corners. "The usual corners" is not an answer you can check.
5. Which macros are present, and does each have both a physical and a timing model? A macro with a LEF abstract and no timing model is a classic gap.
6. What are the power and ground net names, and how do they map? The tool needs the global supply names at import. Unmapped names make power connectivity fail later, in a way that looks unrelated.
7. Which conditional inputs apply? An I/O assignment file, scan information, power intent, or none. A missing conditional input is not a defect unless the project requires it.
8. Who owns each input, and who do you ask when it looks wrong? The owner of a netlist is not the owner of a library or of constraints.
9. Are there nested dependencies, and can you read them? An MMMC file lists Liberty and SDC paths. An SDC file may source another. Permission to read the top file says nothing about those.

For question 6, the names must agree across the netlist, the LEF power pins and your configuration. None of these questions needs a licensed tool. Asking them first moves the discovery of a mistake from "after a ninety-minute import" to "before the launch".

2.3  The inputs at a glance

Table 2 lists each input, its owner, what Innovus takes from it, and the section that teaches it.

2.4  Six meanings of "OK"

Successful initialization establishes that the tool built a database. By itself, it does not establish the intended top, revision or views. Nor does it establish model completeness, constraint correctness or readiness. It is the start of the evidence, not the end. The ladder in Figure 3 makes the point: each rung needs its own evidence.

From a started session to a verified handoff

Six rungs, each with its own evidence

What to notice: Each rung needs its own evidence. Quality, closure and signoff sit above the ladder, in later chapters.

3  The gate-level netlist

The netlist decides what "the design" is. Two mistakes cost the most time. One is loading the wrong top module. The other is discovering late that modules are shared when they must be independent.

3.1  What a netlist is, and who provides it

3.2  Reading a netlist: module, instance, cell master

// A sub-module: two standard cells connected in series.
module alu_slice (a, b, y);
  input a, b;
  output y;
  wire n1;
  NAND2_X1 u_nand (.A(a), .B(b), .Y(n1));
  INV_X1   u_inv  (.A(n1), .Y(y));
endmodule

// The top module: a register, three copies of alu_slice, a register.
module demo_top (clk, din, sel, dout, ybyp);
  input clk, din, sel;
  output dout, ybyp;
  wire q0, y0, y1;
  DFF_X1    u_reg0 (.D(din), .CK(clk), .Q(q0));
  alu_slice u_alu0 (.a(q0),  .b(sel), .y(y0));
  alu_slice u_alu1 (.a(y0),  .b(sel), .y(y1));
  alu_slice u_alu2 (.a(din), .b(sel), .y(ybyp));
  DFF_X1    u_reg1 (.D(y1), .CK(clk), .Q(dout));
endmodule

Named connections such as .A(a) connect the cell pin A to the net a. The pin name must match the library definition. A netlist that says .A1 where the library says A disagrees about the interface, however similar the names look. The hierarchy of the excerpt is drawn in Figure 4.

The hierarchy of the teaching netlist

demo_top instantiates five things; the leaf cells of alu_slice drawn as schematic symbols

What to notice: alu_slice is defined once and used three times. Whether the three copies stay shared is the question of uniquification, below.

3.3  One file or many

3.4  Choosing the top

Automatic discovery suits a set with one obvious root. It is a poor choice when the set contains test benches, alternate versions or several blocks. In that case the tool may pick a module you did not mean. For a first import, name the top. A wrong name then fails visibly instead of loading something else quietly.

3.5  What can be wrong with a netlist

Each problem below has a recognizable consequence.

A netlist can be syntactically valid and still contain connections that a reviewer must look at.

3.6  Why a text search is not proof

A text hit is a reason to expect the import to succeed. The decisive evidence is what the tool reports after loading. Likewise, readable files prove only that they can be opened. They do not prove that they elaborate into the design you meant.

3.7  Uniquification: why identical modules may need to become different

Return to the three copies of alu_slice. The netlist has one definition and three instances, so a change to the definition would change every instance. That is efficient, and it is how hierarchy is normally written.

Implementation does not stay uniform. One copy may need a bigger cell on its critical path, and another a different buffer. A clock tree may add buffers in some instances only. If all three share one definition, any such change applies to all three, which is wrong.

To change instances independently, the tool needs a unique representation. Each instance gets its own module definition, usually with a derived name. This process is uniquification. Figure 5 compares the two states.

Shared modules and uniquified modules

Before: one definition serves three instances. After: each instance has its own

What to notice: The purpose is independent definitions. The new names are a by-product.

The effective value is whatever the session holds when init_design runs. A startup script may have changed it, and omitting it from your configuration does not reset it. The general rule for defaults and effective settings is in "The init_design import flow".

3.8  Before you import: inspecting the netlist

4  Physical library data: technology LEF, cell LEF and macro LEF

The tool must know what a cell looks like before it can place it. It must know what a layer allows before it can route over it. The physical library answers both, in a format called LEF.

4.1  What LEF is

4.2  Technology LEF

• Provided by: the technology or library team.
• Contains: layers, vias, the placement site and basic routing rules.
• Does not contain: any cell.
• Innovus uses it to understand the routing grid and the legal direction of each layer. It also learns the layer and site names that cell LEF files refer to.

UNITS
  DATABASE MICRONS 1000 ;
END UNITS
LAYER M1
  TYPE ROUTING ;
  DIRECTION HORIZONTAL ;
  PITCH 0.20 ;
  WIDTH 0.10 ;
  SPACING 0.10 ;
END M1

LAYER M2
  TYPE ROUTING ;
  DIRECTION VERTICAL ;
  PITCH 0.20 ;
  WIDTH 0.10 ;
  SPACING 0.10 ;
END M2
SITE core_site
  CLASS CORE ;
  SIZE 0.20 BY 1.60 ;
END core_site

4.3  Standard-cell LEF

MACRO NAND2_X1
  CLASS CORE ;
  ORIGIN 0 0 ;
  SIZE 0.60 BY 1.60 ;
  SYMMETRY X Y ;
  SITE core_site ;

  PIN A
    DIRECTION INPUT ;
    USE SIGNAL ;
    PORT
      LAYER M1 ;
        RECT 0.10 0.50 0.20 0.90 ;
    END
  END A

  PIN Y
    DIRECTION OUTPUT ;
    USE SIGNAL ;
    PORT
      LAYER M1 ;
        RECT 0.40 0.40 0.50 1.00 ;
    END
  END Y
  OBS
    LAYER M1 ;
      RECT 0.00 0.00 0.60 0.20 ;
  END
END NAND2_X1

• Inspect: every cell master in the netlist has a MACRO of exactly that name, with the pins the netlist connects.
• Representative failure: a cell is missing from the LEF because an update dropped or renamed it. The tool cannot bind the instance.
• Does not establish: the cell's function, its timing, or whether the abstract matches the real layout.

The NAND2_X1 abstract on its site

The LEF numbers drawn to scale on one core row

What to notice: The pin rectangles sit exactly at the RECT coordinates of the excerpt. The track pitch equals the site width here, which is a property of this teaching example. With no OFFSET in the excerpt, the tracks sit at half a pitch (0.10, 0.30 ... µm), not on the site edges.

4.4  Macro LEF

A memory or analog block is also a MACRO in LEF, usually with CLASS BLOCK. The structure matches a standard cell, but the abstract is larger and the pins sit on its edges. A different team or vendor usually provides it, often with its own timing library. So it is the cell most likely to arrive with one model and not the other. Table 5 lists the three cases.

Large blocks are delivered late and in pieces, so gaps appear there. Let us consider a representative failure with the SRAM (static RAM) macro SRAM_64X8. It has a LEF in the release, but the vendor's Liberty file was never added to the library set. The import may complete. The post-import checks are how you see that the macro has no timing entry.

In the baseline demo_top no instance uses a macro. Treat SRAM_64X8 throughout this chapter as an extension scenario, used to practice the missing-model case.

4.5  Abstract versus layout

A physical abstract is not the layout. Pin rectangles may be simplified, and internal wiring becomes obstructions. The real geometry lives in the layout database of the foundry flow. Finding a cell in the LEF means it can be treated as a placed object. It does not mean the size or the timing is right.

5  Timing libraries, RC technology data, and power and ground names

Liberty libraries provide cell behavior, RC data provides the cost of wires, and supply names tell the tool which nets are global. Each is easy to deliver, and each can quietly disagree with the others.

5.1  Liberty timing libraries

library (stdcells_slow) {
  time_unit : "1ns";
  capacitive_load_unit (1, pf);
  cell (NAND2_X1) {
    area : 0.96;
    pin (A) { direction : input; capacitance : 0.0021; }
    pin (B) { direction : input; capacitance : 0.0021; }

    pin (Y) {
      direction : output;
      function : "!(A & B)";
      timing () {
        related_pin : "A";
        timing_sense : negative_unate;
        cell_rise (delay_template_3x3) {
          index_1 ("0.01, 0.05, 0.20");   /* input transition */
          index_2 ("0.001, 0.005, 0.02"); /* output load */
          values ("0.04, 0.05, 0.09", \
                  "0.05, 0.06, 0.10", \
                  "0.08, 0.09, 0.13");
        }
      }
    }
  }
}

Three quantities are different. The rows of the table are indexed by the transition time at the input A. The columns are indexed by the load on Y. The transition of Y itself has its own table.

5.2  RC technology information

5.3  Power and ground names

5.4  One cell across three files

Figure 7, below, puts the three descriptions of u_nand side by side.

For u_nand, the netlist names NAND2_X1 with pins A, B and Y on named nets. The LEF needs MACRO NAND2_X1 with those pins and a whole number of sites. The Liberty file needs cell (NAND2_X1) with the same pins, a function, and an arc from each input to Y.

• All three exist: the name is bound everywhere.
• One missing: the reference is unresolved in that view.
• All exist but pins differ: the disagreement is quiet, and the post-import checks find it only partly.

One cell, three descriptions

The netlist drawn as a NAND2 symbol; the LEF and Liberty entries for the same name

What to notice: A shared name is a binding, not proof that pins, function, arcs or geometry agree.

6  Constraints: telling the tool what "correct timing" means

A timing tool measures what it has been told to measure. The netlist and libraries say what the circuit is. The constraints say what it must achieve: how fast the clock runs, and when input data arrives and output data is needed. A constraint file that loads without a message is not the same claim as a constraint file that is right.

Constraints are written in SDC, a Tcl-based format. This section covers enough SDC to judge whether a constraint set is ready for import. It is not a full treatment of static timing analysis.

6.1  Where constraints come from, and what they assume

6.2  The four classes of path

Every timing path starts at a startpoint and ends at an endpoint. The constraints that matter depend on both ends. Four classes cover most designs, and Figure 8 marks each one in demo_top.

Four classes of timing path in demo_top

Registers drawn as D flip-flops, each alu_slice as a NAND2 and an inverter

What to notice: A clock constrains the register-based classes. Input and output delays describe the world outside the block.

6.3  A small constraint file, read line by line

# Primary clock: 10 ns period, rising edge at 0, falling edge at 5.
create_clock -name clk -period 10 -waveform {0 5} [get_ports clk]
# Data arrives 2 ns after the clock edge at these inputs.
set_input_delay 2.0 -clock clk [get_ports {din sel}]
# Outside logic needs 3 ns before the next clock edge at these outputs.
set_output_delay 3.0 -clock clk [get_ports {dout ybyp}]
# Assumed input slew and output load at the block boundary.
set_input_transition 0.2 [get_ports {din sel}]
set_load 0.05 [get_ports {dout ybyp}]

6.4  Clocks derived from clocks

A cell that changes the frequency or waveform of a clock, such as a divider, produces a new clock. You declare it with create_generated_clock. A simple gating cell that passes the clock with the same waveform does not automatically need one. Whether a gated clock needs its own definition depends on the cell and your flow's rules. Follow the project's constraint guidelines.

create_generated_clock -name clk_div2 -source [get_ports clk] \
    -divide_by 2 [get_pins u_div/Q]

• Arguments used: -⁠name names the new clock. -⁠source names the pin where the master clock is found.
• -⁠divide_by 2 halves the frequency. The pin u_div/Q is where the new clock appears.
• Optional: -⁠multiply_by for a faster clock, and -⁠edges to list which source edges form the waveform.
• Limit: if the master clock never reaches the -⁠source pin, the generated clock cannot be built.
• If several clocks reach it, the tool chooses the master in a defined order unless you name it with -⁠master_clock.

6.5  Constants and exceptions

set_case_analysis 0 [get_ports test_mode]

# Claim: this path has two cycles for setup.
set_multicycle_path 2 -setup -from [get_pins u_reg0/CK] \
    -to [get_pins u_reg1/D]

The claim needs the design to hold u_reg0's data stable for two cycles, and u_reg1 to capture only every second cycle. Nothing in the file proves that. A setup multicycle is usually paired with a hold assertion, because moving the setup relationship also moves the hold check. Check your project's convention.

6.6  The arithmetic of setup and hold

These are teaching assumptions, not project values. The period is 10 ns, the launch edge is at 0 ns and the capture edge at 10 ns. Figure 9 draws all three calculations on one time axis.

This is a sketch. It assumes zero skew, no uncertainty margin, no on-chip-variation derating, no common-path correction and a single-cycle clock relationship. A real report includes all of those. Use the arithmetic to understand the report, and use the report to decide.

Setup and hold arithmetic on one time axis

Period 10 ns; three teaching calculations

What to notice: On the bypass row the two amber boundary delays take 5.0 ns of the 10 ns period before the gate delay of u_alu2 is counted.

6.7  What goes wrong: three cases

Each case below can pass without stopping the import. Depending on the statements and the release, you may get a warning, an error, an ignored constraint or an unintended virtual clock. So the log and the clock report must be read. For each case, we state what the tool does, what you would see and what you conclude.

6.8  What early slack does and does not tell you

Early slack is informative, and a path with large negative slack deserves attention. But early slack is not closure, because nothing is placed or routed and wires are estimates. It is not proof of coverage either. Slack is reported only for constrained paths, and an unconstrained path looks the same as one with no problem.

Favorable slack answers none of them.

7  MMMC, command by command

An MMMC configuration looks like a list of commands. Read it as a small graph in which every object is created from objects made earlier. Once you can trace one view down to its files, missing objects, wrong pairings and dropped views become easy to see.

The objects and what points at what are drawn in Figure 10. The terms are defined just below it.

MMMC objects and what points at what

Files feed objects; objects feed views; activation picks views

What to notice: Every arrow is a name reference, and a name that was never created is the commonest MMMC error.

The Legacy UI builds the description from five kinds of object and one activation step. Each object is made by one command, in dependency order.

7.1  A consistent example

func_slow and test_slow share a delay corner, and func_slow and func_fast share a constraint mode. That sharing is the point: define each corner and mode once, then combine them.

The memory libraries appear in each library set so that the trace has two libraries per corner. The baseline demo_top does not instantiate the memory, so the macro scenario is an extension.

7.2  Step 1: create_library_set

innovus> create_library_set -name libs_slow \
    -timing [list data/stdcells_slow.lib data/sram_slow.lib] ;# slow-corner libs

A library set is a named group of timing libraries.

• Purpose: let later steps refer to several Liberty files as one object.
• Arguments: -⁠name libs_slow names it. -⁠timing takes a Tcl list of Liberty files, built with list so each file stays a separate element.
• Order matters: the first library is the master, and each later one has lower priority.
• Scope: it refers to files only. It is created first because delay corners need it. A second command makes libs_fast.
• Verify: the active-view report lists each library set with its files.
• Wrong reference: data/sram_fast.lib listed under libs_slow can load without a corner-intent error. The tool cannot judge project intent from a file name.
• The library report shows the path, which is where a reviewer sees it. Other messages may appear.

7.3  Step 2: create_rc_corner

innovus> create_rc_corner -name rc_slow -cap_table data/rc_slow.captbl ;# wire RC data

7.4  Step 3: create_delay_corner

innovus> create_delay_corner -name slow -library_set libs_slow \
    -rc_corner rc_slow ;# delay corner slow

7.5  Step 4: create_constraint_mode

innovus> create_constraint_mode -name func -sdc_files [list data/func.sdc] ;# func mode
innovus> create_constraint_mode -name test -sdc_files [list data/test.sdc] ;# test mode

7.6  Step 5: create_analysis_view

# The fast corner objects follow the pattern of the slow ones;
# the complete file below shows them.
innovus> create_analysis_view -name func_slow -constraint_mode func \
    -delay_corner slow ;# functional mode, slow corner
innovus> create_analysis_view -name func_fast -constraint_mode func \
    -delay_corner fast ;# functional mode, fast corner
innovus> create_analysis_view -name test_slow -constraint_mode test \
    -delay_corner slow ;# test mode, slow corner

Figure 11 traces one view, func_slow, down to the files it uses.

Four kinds of file support one view, and checking each of them is the review. Diagnose a missing or wrong view by walking this trace. Find the first name that does not resolve, or the first file that is not the intended one.

Tracing func_slow to its source files

A view reaches its files through a constraint branch and a corner branch

What to notice: Every gray leaf is a file you can open, and the review of a view ends there.

7.7  Step 6: set_analysis_view

innovus> set_analysis_view -setup {func_slow test_slow} \
    -hold {func_fast} ;# the first view in each list is the default

Three terms are easy to blur. The tables in Figure 12 show all three, before and after a narrower second call.

set_analysis_view is not incremental

The same three views before and after a narrower second call

What to notice: The defaults (the first name in each list) did not change, so a check of the defaults alone would miss the dropped view.

• Defined: the view exists as an object. All three of ours are defined.
• Active: the tool analyzes it. func_slow and test_slow are active for setup, and func_fast for hold. test_slow is not active for hold.
• Default: the first in each list, here func_slow for setup and func_fast for hold.

set_default_view can change the default among already active views without a timing reset, but it is rarely needed. A sorted membership comparison cannot show which view is the default. There is no query for the default itself. Establish it from the activation statement (the first name in each list) and from the absence of a later set_default_view. Then compare it with the project's intent.

Setup and hold are separate lists. Setup is often checked at the slow corner and hold at the fast one. That is where each check tends to fail. That is a tendency, not a rule. The project chooses from the technology and signoff plan. A hold list that repeats the setup views is not wrong, but it is a decision to confirm.

Our hold list has no test view. Hold in test mode is therefore not checked, because no active hold view uses the test mode. Whether that is acceptable is the project's call, and the review must make sure someone made it.

7.8  The complete example file

# Library sets: one per corner, each holding every library that corner needs.
create_library_set -name libs_slow \
    -timing [list data/stdcells_slow.lib data/sram_slow.lib]
create_library_set -name libs_fast \
    -timing [list data/stdcells_fast.lib data/sram_fast.lib]
# RC corners: wire estimates for each corner.
create_rc_corner -name rc_slow -cap_table data/rc_slow.captbl
create_rc_corner -name rc_fast -cap_table data/rc_fast.captbl
# Delay corners: one library set plus one RC corner.
create_delay_corner -name slow -library_set libs_slow -rc_corner rc_slow
create_delay_corner -name fast -library_set libs_fast -rc_corner rc_fast
# Constraint modes: one per mode, each naming its SDC file.
create_constraint_mode -name func -sdc_files [list data/func.sdc]
create_constraint_mode -name test -sdc_files [list data/test.sdc]
# Analysis views: one mode seen at one corner.
create_analysis_view -name func_slow -constraint_mode func -delay_corner slow
create_analysis_view -name func_fast -constraint_mode func -delay_corner fast
create_analysis_view -name test_slow -constraint_mode test -delay_corner slow
# Activation: setup views first, then hold views.
set_analysis_view -setup {func_slow test_slow} -hold {func_fast}

Relative names such as data/func.sdc resolve from the session's working directory. Use absolute paths when in doubt, and record the launch directory, as the previous chapter taught.

7.9  Verifying the relationships: report_analysis_views

innovus> report_analysis_views -type active ;# active views and the objects they use

all_analysis_views -⁠type setup and -⁠type hold return the same lists as Tcl lists for scripting. Comparing them after sorting proves the memberships match. It does not prove the intended default views, because the sort discards order. The post-import checks return to this report as the most direct evidence that the configuration says what you meant.

8  Conditional inputs, alternatives, and reviewing a package

Not every design uses every input. Recognizing the alternatives avoids two mistakes: demanding an input that does not apply, and missing one that does.

8.1  Conditional inputs

Scan information. A separate input for later steps. At import you only need to know whether the chains are stitched. That changes what the constraints should say about the test mode.

Power intent. A design with several power domains describes them in a separate format. One route derives the MMMC configuration from a Common Power Format (CPF) file through init_cpf_file. Use it only if your project requires it.

OpenAccess. A project may store libraries and design in OpenAccess instead of LEF and Verilog. The import then uses OA-specific settings, including init_design_netlisttype set to OA. This chapter does not develop that route.

A missing conditional input is not a defect. A conditional input the project requires and nobody delivered is.

8.2  Reviewing an input package: a worked example

The invented package in Table 9 is reviewed as you would before launching, with a decision for each item. Read the findings as the notes you would write.

Several of these items could have been waved through. Each stop or hold would have become a confusing problem after the import. You reached all of them without a tool, by reading files, comparing names and asking questions.

9  The init_design import flow

init_design is one command, but everything it needs is set beforehand through global settings and a view definition. If you can say what each setting selects, you can read any import script. You will also know which setting to suspect when the result is wrong.

9.1  Before, during and after

Figure 13 compares the session before and after the command.

Afterwards there is a design in memory. It has a top module, instances linked to library cells, loaded physical and timing libraries, active views and a default floorplan. Nearly everything that matters is still unverified: the loaded top, the model binding of every cell, the clocks and the active views.

The session before and after init_design

What the command builds, and what it leaves for you

What to notice: The amber card is everything the command does not verify. The post-import checks exist for that list.

9.2  The Tcl you need to read the configuration

% set top_name demo_top ;# assign a value: the text after the name
% puts "the top is $top_name" ;# $top_name is replaced by its value
% set lef_files [list data/tech.lef data/stdcells.lef] ;# brackets run list
% set files [list {data/my file.v} data/b.v] ;# braces group a path with a space
% puts [llength $files] ;# prints 2: two elements
% set literal {$top_name stays as typed} ;# braces: no substitution
% puts $literal ;# prints the dollar sign as typed
% puts [llength $lef_files] ;# llength counts list elements
% set long_list [list data/a.lib \
    data/b.lib] ;# a trailing backslash continues the command
% if {[info exists never_set]} { puts "set" } else { puts "not set" } ;# test

• set name value: creates or changes a variable. Every init_ setting is made this way.
• $name: inserts the value. It is substituted inside double quotes and not inside braces. That is why {$top_name stays as typed} prints the dollar sign.
• [ ... ]: runs the command inside and inserts its result.
• list: each argument becomes one element. It does not group an unquoted multiword path by itself.
• So [list data/my file.v] yields two elements, while [list {data/my file.v}] yields one.
• Braces and quotes: a braced group is literal and a quoted group allows substitution. Braces are the safe habit for hand-typed paths.
• source file: runs a file's commands in the current session. The view definition file is used this way.
• puts: prints text, which is how a script writes a value into the log.
• Grouping and newlines: braces group text and may contain newlines. Square brackets evaluate a Tcl script, so a newline inside brackets can end one command and begin another.
• Trailing backslash: a backslash immediately followed by a newline joins the physical lines into one command. A space after the backslash breaks it, because the backslash then escapes the space.
• info exists name: tells whether a variable exists, so a script can report a value without raising an error.

# Works: the backslash joins the two physical lines.
set long_list [list data/a.lib \
    data/b.lib]
# Fails: the newline ends the command inside the brackets, and
# the second line is read as a command named data/b.lib.
set long_list [list data/a.lib
    data/b.lib]

9.3  Defaults, effective settings and optional globals

9.4  The settings, one at a time

Each entry gives the meaning first. Observe every setting by printing it, as the script in this section does. They are collected in Table 10.

9.5  The configuration in small readable blocks

innovus> set init_design_netlisttype Verilog ;# state the netlist source explicitly
innovus> set init_verilog [list data/demo_top.v] ;# one netlist file, one element
innovus> set init_design_settop 1 ;# 1: we name the top ourselves
innovus> set init_top_cell demo_top ;# spelled exactly as in the Verilog
innovus> set init_lef_file [list data/tech.lef data/stdcells.lef \
    data/sram.lef] ;# technology LEF first, then cell, then macro

innovus> set init_pwr_net VDD ;# global power name; must agree with LEF and netlist
innovus> set init_gnd_net VSS ;# global ground name
# 1: uniquify while reading. Chosen because this flow will run clock tree synthesis and
# optimization on one design. A master-and-clone flow would use 0.
innovus> set init_design_uniquify 1 ;# uniquify during read

innovus> set init_mmmc_file data/viewDefinition.tcl ;# the view definition file

9.6  The complete configuration for Path A

# Record the release the session is running (the command returns a value).
puts "release: [getVersion]"
# What to read.
set init_design_netlisttype Verilog
set init_verilog [list data/demo_top.v]
set init_design_settop 1
set init_top_cell demo_top
set init_lef_file [list data/tech.lef data/stdcells.lef data/sram.lef]
# Supplies and uniqueness.
set init_pwr_net VDD
set init_gnd_net VSS
set init_design_uniquify 1
# Timing configuration: the view definition file.
set init_mmmc_file data/viewDefinition.tcl

# Record the effective configuration before importing.
foreach g {init_design_netlisttype init_verilog init_design_settop \
           init_top_cell init_lef_file init_pwr_net init_gnd_net \
           init_design_uniquify init_mmmc_file init_io_file} {
    if {[info exists $g]} {
        puts "$g = [set $g]"
    } else {
        puts "$g is not set"
    }
}
# Build the database.
init_design

Block by block, the script records the release, sets the configuration, prints the effective settings, then imports.

9.7  Path B: creating the MMMC objects inline

Path B creates the MMMC objects in the import script, with no view file. That creates a circular dependency. set_analysis_view cannot be issued until the design is initialized, and init_design needs the active views. The way out is to pass the lists to init_design with -⁠setup and -⁠hold, and not to call set_analysis_view first.

On Path B, leaving init_mmmc_file out of the script is not proof that no inherited view file is active. Print init_mmmc_file with the same loop and confirm the required effective state. Do not blindly unset an approved project setting. Select one initialization route per session. On Path A, init_design sources the view file. So its set_analysis_view runs as part of the import, not before it. Figure 14 compares the routes.

The timing-enabled routes and the physical-only route

Where the views are activated in each route

What to notice: No route calls set_analysis_view before init_design. On Path A it runs inside the import, and on Path B the view lists travel with the command itself.

# Same data settings as Path A, except no init_mmmc_file.
set init_design_netlisttype Verilog
set init_verilog [list data/demo_top.v]
set init_design_settop 1
set init_top_cell demo_top
set init_lef_file [list data/tech.lef data/stdcells.lef data/sram.lef]
set init_pwr_net VDD
set init_gnd_net VSS
set init_design_uniquify 1

# The MMMC objects, created inline in dependency order.
create_library_set -name libs_slow \
    -timing [list data/stdcells_slow.lib data/sram_slow.lib]
create_library_set -name libs_fast \
    -timing [list data/stdcells_fast.lib data/sram_fast.lib]
create_rc_corner -name rc_slow -cap_table data/rc_slow.captbl
create_rc_corner -name rc_fast -cap_table data/rc_fast.captbl
create_delay_corner -name slow -library_set libs_slow -rc_corner rc_slow
create_delay_corner -name fast -library_set libs_fast -rc_corner rc_fast
create_constraint_mode -name func -sdc_files [list data/func.sdc]
create_constraint_mode -name test -sdc_files [list data/test.sdc]
create_analysis_view -name func_slow -constraint_mode func -delay_corner slow
create_analysis_view -name func_fast -constraint_mode func -delay_corner fast
create_analysis_view -name test_slow -constraint_mode test -delay_corner slow
# Activation happens here, through init_design.
init_design -setup {func_slow test_slow} -hold {func_fast}

Two more routes exist and are not developed here. A CPF-based route derives the MMMC configuration through init_cpf_file, for designs with power intent. You can also source a saved globals file and then call init_design, provided that file is configured for MMMC.

9.8  Start clean, and do not repair by calling it again

init_design also does not repair inputs. A missing cell is reported or stops the import, and no model is substituted.

9.9  Timing-enabled versus physical-only

With no MMMC configuration at all, the Legacy UI initializes into physical-only mode. This mode gives no access to the timing part of the system, and reinitializing requires exiting the software. You cannot add timing to the same session.

A physical-only import still has uses. You can inspect geometry, check how a netlist binds to the LEF files, or work on a floorplan without timing libraries. Its inputs are typically the netlist, the top, the LEF files and the supply names. Table 12 compares the two imports.

In a physical-only import, call the timing checks "not applicable to this branch", not "skipped". Skipped means a possible check was not done. And never describe a physical-only import as timing-ready.

9.10  The default geometry is not a floorplan

These make the database complete. They are not an approved floorplan. Die size, aspect ratio, macro positions and pin placement belong to the next stage. A die and rows after import say nothing about your project's target.

9.11  What happens during the import, as concepts

Use these phases as headings when you read the log. A warning in the netlist phase and one in the constraints phase have different owners.

10  Judging the imported database: post-import sanity checks

An import ends and the tool is quiet. You must now decide whether to trust what is in memory. The skill is reading reports against what you intended. You judge whether the evidence is enough, and you know what to do when it is not.

10.1  A way to think about every check

If the decision is not accept, name the likely cause, the owner and the fix. The fix goes into the inputs or configuration for a new run, never into the database under judgment.

The investigation behind every check

Concern, command, evidence against intent, decision

What to notice: The comparison with a written intent turns a report into a judgment. Fixes go back to the inputs and start a new run.

Two limits apply to every check. A passed check says only what that command can see. And evidence has a scope and a date. A report from an earlier run, for a different view, or cut short is not evidence about this database (check I).

10.2  The checking commands are not aliases

Similar names ask different questions.

10.3  Which check_design categories fit this stage

Do not use -⁠type all to feel thorough. Categories for placement, optimization, clock tree synthesis, routing and signoff check preconditions for stages that have not started. A freshly imported design fails them for reasons that are not problems yet.

The checks below are labeled A to I, from "what is this database" to "can I trust the evidence". The evidence blocks are illustrative imitations for practicing reading, not tool transcripts.

10.4  A. Is the loaded design the one I meant, and is its content plausible?

Concern. The import may have loaded the wrong top, or a hierarchy much smaller or larger than intended.

innovus> puts [dbGet top.name] ;# print the top module the database holds

dbGet top.name returns the top design's name, and puts prints it, since a script does not print a returned value on its own.

Inspect. The name equals init_top_cell and the manifest. The size is plausible against the synthesis report. The netlist report's design statistics give counts to compare.

declared top : demo_top
loaded top   : demo_top_v2

A different module was loaded, or the evidence does not come from the session you think it does.

If settop was 0, the tool chose the top itself. An older netlist in the list that defines both demo_top and demo_top_v2 can explain wrong contents or a wrong revision. It does not by itself explain why an explicit top selection was ignored. The owners are you (configuration) and the design owner.

Decision. A name mismatch is a stop: fix the configuration and start a new run. A matching name with an implausible size is an investigation, since black boxes shrink a design and extra test-bench files enlarge it.

Limit. A matching name is not a matching netlist revision, a plausible hierarchy, or a correct design. Each is a separate question.

10.5  B. Is every cell bound to a physical and a timing model?

innovus> checkDesign -physicalLibrary -timingLibrary -noHtml \
    -outfile checkdesign.rpt ;# physical and timing binding, one text report
innovus> check_design -type library \
    -out_file check_design_library.tcl ;# binding as a prerequisite, as Tcl data

• -⁠physicalLibrary: cells have LEF views. It reports cells not defined in LEF, missing dimensions, and pins without direction or geometry. It also reports cell dimensions that are not a multiple of the core site.
• -⁠timingLibrary: cells used in the design are defined in the timing library.
• -⁠noHtml: text report only. -⁠outfile names it and is allowed only with -⁠noHtml.
• check_design -⁠type library: binding of all instances to library cells, and cells present in only one of the physical and logical descriptions. Keep the -⁠out_file as data.

Inspect. No cell used by the design is undefined in either library, and every reported difference can be explained.

checkDesign -timingLibrary
  cell SRAM_64X8 used by 1 instance: not defined in any timing library
check_design -type library
  libcell SRAM_64X8: LEF view present, no .lib view

This is the macro extension scenario, since the baseline demo_top does not instantiate SRAM_64X8. Both commands report one finding: a physical model and no timing model. The likely cause is a Liberty file missing from a library set. The owner is the library or macro provider. The fix is to provide the file and rebuild the configuration.

Limit. A passed binding check says names were found. It does not show that every arc exists, that the function is right, or that the characterization is correct.

10.6  C. Is the netlist well formed?

innovus> checkNetlist -outfile checknetlist.rpt ;# summary, statistics, rule checks
innovus> checkNetlist -includeSubModule \
    -outfile checknetlist_sub.rpt ;# also check submodule port definitions

innovus> set uniq [checkUnique -verbose] ;# capture the return value
innovus> set fp [open checkunique_return.txt w] ;# open a record file
innovus> puts $fp "checkUnique returned $uniq" ;# write the return value
innovus> close $fp ;# close the record file
innovus> redirect checkunique_verbose.txt {checkUnique -verbose} ;# shared-module list

• checkNetlist -⁠outfile: writes the report. Without a name it uses checknetlist.rpt.
• checkUnique: returns 1 if every non-leaf module is instantiated only once, otherwise 0. -⁠verbose lists modules instantiated more than once.
• Record the return value explicitly. Redirected text does not necessarily contain it, so the script stores it in checkunique_return.txt.
• Link to the netlist section: with init_design_uniquify at 1, expect 1. A 0 with alu_slice listed means the three instances still share a definition.

Number of Floating Ports *: 1
Number of undefined Floating Pins ?: 2
Number of Ports Connect to Core Cells *: 0

Investigate. The first line says one port floats. Find its name in the report body. Ask whether it is an input nothing uses, an output nothing drives, or a port the netlist forgot to connect. A floating input of a spare function is expected. A floating output that should carry ybyp is a netlist bug.

Decision. The netlist owner answers. An unexplained marked statistic is a stop. An explained one is an accept with a note.

Limit. The report shows structural properties. It does not show that the logic is correct, and it is not an equivalence check.

10.7  D. Are the MMMC relationships and the active roles what I intended?

innovus> redirect views_setup.rpt {report_analysis_views -type setup} ;# setup views
innovus> redirect views_hold.rpt {report_analysis_views -type hold} ;# hold views
innovus> redirect views_all.rpt {report_analysis_views -type all} ;# every defined view

innovus> puts "setup: [lsort [all_analysis_views -type setup]]" ;# setup names
innovus> puts "hold: [lsort [all_analysis_views -type hold]]" ;# hold names

• redirect runs the command in braces and sends its output to the file.
• report_analysis_views -⁠type setup and -⁠type hold: for each view in that role, its delay corner, then the RC corner and library sets with their files.
• all_analysis_views -⁠type setup and -⁠type hold: the names for each role.
• Compare setup and hold separately with the manifest. One combined list cannot show that a view sits in the wrong role.
• What the sorted comparison proves: the required setup and hold memberships match. It does not establish the intended default views, because sorting discards the order.

SETUP views
  view func_slow
    delay corner slow
      rc corner rc_slow : data/rc_slow.captbl
      library set libs_slow
        data/stdcells_slow.lib
        data/sram_slow.lib
    constraint mode func : data/func.sdc

HOLD views
  view func_fast
    delay corner fast
      rc corner rc_fast : data/rc_fast.captbl
      library set libs_fast
        data/stdcells_fast.lib
        data/sram_fast.lib
    constraint mode func : data/func.sdc

Defaults. Review the defaults separately, because there is no query for the default itself. Read the activation statement that ran: the first view in each list is the default. Confirm that no later set_default_view call changed it. Compare the result with the project's intent.

Decision. The role lists must have the manifest's membership. Here they do not, so this is a stop. Find the second activation, usually a script sourced after the view file. Correct it and run again.

Limit. The report shows that the configuration says what you meant, not that the corners are right for the technology.

10.8  E. Are the clocks the ones I intended?

innovus> report_clocks -view func_slow > clocks_func_slow.rpt ;# clocks of one view
innovus> report_clocks -view test_slow > clocks_test_slow.rpt ;# clocks of the test view

report_clocks lists clocks created by create_clock and create_generated_clock, with waveforms, arrival points and uncertainties. -⁠view limits it to one view. Generated clocks are reported by default.

view func_slow
  clock clk   period 100   waveform {0 50}   source port clk

The period is 100 where the specification says 10. This is the wrong-period case from the constraints section, a factor-of-ten error in the value. It need not stop the import, and the evidence is a number you compare with the specification.

Scope. A clock exists within a constraint mode. A clock in func.sdc appears in the functional views. It does not appear in the test mode unless test.sdc defines it too. So "the clock is listed" must be followed by "in which views?" The per-view reports answer that.

Generated clocks. A listed clk_div2 shows only that the clock exists. Compare its period and waveform with what the divider should produce. A wrong master, ratio or source pin gives a plausible name and a wrong waveform.

Decision. A missing, misattached or wrongly timed intended clock is a stop, owned by the constraint owner. An unexpected extra clock is an investigation.

Limit. The report lists defined clocks. It does not prove that a clock reaches every register it should.

10.9  F. Are the constraints consistent with each other and with the netlist?

innovus> check_timing -verbose -view func_slow \
    > check_timing_func_slow.rpt ;# one view, output to a file

warning no_input_delay  : port sel has no input delay
warning uncons_endpoint : port dout has no constraint

We read the two warnings independently, because the example does not establish that one causes the other.

Decision. Neither warning is accepted until the constraint owner explains it. The early and late values come from the interface specification. Fixes go into func.sdc, then a new run. After each fix, run check_timing again in the new run.

The distinction to keep: an optimistic assumption still produces a number, and an unperformed check produces none.

Limit. A clean check_timing means the checks it performs found nothing, not that the constraints are right. Warnings do not stop the script, so no stop is not a pass.

10.10  G. How much of the design is actually analyzed?

innovus> report_analysis_coverage -view func_slow \
    > coverage_func_slow.rpt ;# met, violated or untested, per check type
innovus> report_analysis_coverage -view func_slow -verbose untested \
    -sort reason > untested_func_slow.rpt ;# untested checks grouped by reason

• Report: per check type, how many checks are met, violated or untested. Details give the signal pin, reference pin, check type, slack and reason.
• -⁠view: scopes to one view, in multi-mode multi-corner analysis only.
• -⁠verbose untested: details for untested checks only. -⁠sort reason: groups by reason.
• Reading a row: a tested check shows a slack number and no reason. An untested one shows UNTESTED in the slack column and a reason.

A reason is a prompt for a question, not a justification. false_path says a path was excluded, not that excluding it was correct. For each group of untested checks, find the SDC line or netlist feature behind it. Then ask the owner whether the design needs that.

view test_slow   (active for setup in this case; counts illustrative)
check type   met   violated   untested
setup        0     0          2
untested checks (signal pin, reference pin, check, reason):
  u_reg0/D   u_reg0/CK   setup   no_endpoint_clock
  u_reg1/D   u_reg1/CK   setup   no_endpoint_clock

The setup checks in this view are untested, for a missing-clock reason. This matches the package review: test.sdc creates tclk with a source selection that matches no port. So the clock is not attached, and the registers carry no clock in the test mode. The checks that depend on one are not performed.

The illustration shows a setup row only. In the baseline configuration, test_slow is not an active hold view. So this report is no evidence about test-mode hold. How a coverage report treats a view that is not active in a role is not defined. So this chapter does not show one.

• Reporting limits: console output may be limited by the tool's message display limit. For check_design the complete list goes to -⁠out_file. Treat the file as the record.
• Views: an unscoped report does not prove every view was analyzed. Run each report for each required view: func_slow, func_fast and test_slow, not just the first.
• Limit: coverage counts the checks that exist. Only a comparison with the design's structure and intent shows that a missing check should have existed.

10.11  H. What did the import log say?

Concern. The log holds warnings and errors that no report repeats, such as unreadable constraint lines, ignored syntax and library problems.

A warning is a question, and the record shows it was answered. A good import is not required to have none.

Limit. The log contains what was logged. A condition that raised no message does not appear.

10.12  I. Is the evidence fresh and in scope?

Limit. Freshness and scope are properties of how you ran the checks, so your process answers them.

10.13  A worked review: clean-looking, but not acceptable

The comparison with the manifest at check D already exposes the failure. The other reports look clean because they never looked at the missing view.

Trace.

1. Compare views_all.rpt with views_setup.rpt and views_hold.rpt: test_slow is defined and not active.
2. Search the scripts that ran after the view file for a second activation.
3. A site setup script sourced after init_design calls set_analysis_view -⁠setup {func_slow} -⁠hold {func_fast}, and the call is not incremental.
4. After the activation is corrected and test_slow is active for setup, run the three reports for it.
5. Read its coverage report: it shows the picture of Case G1.
6. These reports are not run before the fix, because their behavior for an inactive view is not defined.
7. A second, independent fault appears: test.sdc creates tclk with a source selection that matches no port.

• Decision: not accepted.
• Owners: you for the activation, the constraint owner for test.sdc.
• Fix: a corrected activation and a corrected test.sdc, then a new run in a new folder. Nothing is repaired in the session under judgment.

10.14  The acceptance decision

Table 14 is the acceptance table for the nine checks.

11  Saving, restoring and exporting

The imported database lives in memory and disappears with the session. Saving, restoring and exporting are different acts for different readers. Mixing them up is how a team hands over a netlist and believes it handed over a design.

11.1  Five things that are easy to confuse

For every artifact, ask the same questions. What does it contain and omit? Who reads it? What does it depend on? How is the write verified? What can still not be inferred from it?

The native checkpoint is the intended way to continue work in Innovus. It is not the only artifact Innovus can read, and the exports below have their own readers.

Import, checkpoint, restore and exports

A checkpoint is read back by Innovus; exports go to other readers

What to notice: Only the checkpoint is meant to continue the work in Innovus. A layout stream is a later-stage product.

11.2  Saving a checkpoint: saveDesign

innovus> saveDesign accepted.enc ;# native format, under a deliberate name

• Purpose. A restart point for the next session.
• Arguments. The name, here accepted.enc. Optional -⁠user_path stores external references as you entered them. Optional -⁠libs copies library files into the saved directory.
• Optional -⁠tcon copies the SDC files. Optional -⁠timingGraph includes the timing graph. -⁠rc includes extraction data, which does not exist at this stage.
• Contains. The database, plus references to the LEF, Liberty and SDC files it was built from.
• Depends on. Those external files. By default, external references such as library files are stored as absolute paths without symbolic links.
• So the checkpoint is portable anywhere on the same network where those paths are accessible. The spelling you typed in the import scripts is not necessarily the spelling the checkpoint keeps.
• With -⁠libs or -⁠tcon, a later restore and save refers to the copies. So the saved directory must be kept for as long as anything refers to it.
• Does not replace. A judgment of the database. A save of a bad import is a bad checkpoint.
• Verify. Restore it in a fresh session and compare facts (below).
• Limit. A completed save is not automatically self-contained. The checkpoint directory and its actual dependencies must stay intact.
• What a restore brings back depends on what was saved, so some timing or extraction results may have to be repeated.

accepted.enc         small file containing a restoreDesign command
accepted.enc.dat/    directory with the saved database files

A directory listing shows that something was written. It does not show that the save completed, that every dependency is reachable, or that a restore will work. The saved contents should not be edited by hand. Saving to the location you restored from overwrites the data there.

Debug saves and accepted saves. Save a failing state when someone else needs to see it. Give the two kinds different names, such as debug_before_fix.enc and accepted.enc. The name is a policy, not a property of the format. It stops a debug state being mistaken for an approved handoff. It also stops a later save from silently replacing the accepted one.

Only the third supports "this checkpoint is ready for the next stage". A saved checkpoint does not establish a successful restore.

11.3  Restoring: restoreDesign

innovus> restoreDesign accepted.enc.dat demo_top ;# saved directory, then the top cell

• Purpose. Bring a saved database into a session.
• Arguments. The .dat directory, then the top cell. An OpenAccess database uses -⁠cellview instead.
• Inspect. The top name, the views and the log of the restore.
• Limit. Innovus does not support loading another database while a design is in memory, so restore in a fresh session.

By default, B holds absolute references, so C matters little for them. The original spelling in A is not necessarily what B retains. A source path that is relative to the import folder need not be re-resolved as written from the restore folder.

Inspecting the dependencies. Do not edit anything inside the saved directory. A read-only look at the .globals file in it shows which file references the checkpoint retained. Its layout is release-specific. The restore log is the evidence of which dependencies actually resolved, so read it after every restore, together with the comparison below.

Setup and hold lists are compared separately. One combined active list cannot show that a view moved from one role to the other. Write each attempt's evidence into a new folder. A file left by an earlier attempt can look like a match. A stale match after a failed restore is more dangerous than no evidence.

A restore without an error is necessary, not sufficient. A matching top and matching view lists are stronger. They still do not prove that every library, constraint file and database detail came back as before.

11.4  Exporting a logical netlist: saveNetlist

innovus> saveNetlist demo_top_export.v ;# logical netlist as Verilog

• Purpose. Connectivity for other tools or for review.
• Arguments. The file name. The default is hierarchical Verilog, from the top down. -⁠flat flattens it. -⁠topCell saves one module with its submodules.
• -⁠includePhysicalInst, -⁠includePowerGround and -⁠phys add physical content for consumers such as layout-versus-schematic checks.
• A -⁠phys netlist should not be read back into Innovus. None of these options are used at this stage.
• Contains. Hierarchy, cell masters, instances and nets.
• Does not replace. The checkpoint. It has no positions, routing, constraints or timing.
• Verify. Quick inspection: the file is not empty, is not cut off, and the module names are those you expect.

11.5  Exporting floorplan data: defOut

innovus> defOut -floorplan -netlist -unplaced \
    demo_top_import.def ;# floorplan and the still unplaced netlist

• Purpose. Hand geometry and connectivity to a review or another tool.
• Arguments. -⁠floorplan writes rows, chip size, pad and block instances. -⁠netlist writes connectivity and is typically used after placement.
• So on an unplaced design -⁠netlist is paired with -⁠unplaced, which writes the unplaced standard cells.
• Other options select routing, special nets and scan chains. Some produce a DEF that cannot be read back into Innovus.
• Contains. After a first import, the default die, rows and tracks, plus unplaced components and nets. The physical library abstracts are already in use.
• Does not replace. The checkpoint. There is no timing setup, library or constraint.
• Verify. Quick inspection: a header, a DESIGN statement with the top name, die area, rows and tracks, and unplaced components.
• Limit. The first import has no approved placed or routed implementation and no extracted parasitics. The DEF is a record of default geometry, not an approved floorplan.

11.6  Exporting constraints: writeTimingCon

innovus> writeTimingCon func_slow_out.sdc -view func_slow ;# one view to an SDC file

• Purpose. Review what the tool applied, or feed another tool.
• Arguments. The file name, then -⁠view naming the view. Naming the view is a good habit in a multi-mode configuration.
• Optional switches select clocks, pins and commands, and leave out annotated delays, checks or transitions.
• Contains. The constraints as the database holds them, not the source text. Order, comments and style can change.
• Does not replace. The source SDC, or a check that the source was right.
• Verify. Write one file per view. Then compare each exported view with its own source constraint set. For example, compare a func view with func.sdc and a test view with test.sdc.
• Compare meaning, not text order: effective clocks, periods and waveforms, boundary delays, exceptions, case analysis and the files sourced.
• Limit. A difference may be a change of form, or evidence that a statement was dropped or ignored. Understand it before accepting it.

11.7  Later-stage outputs, as context

Layout streams belong to later stages, for example GDSII (Graphic Design System) and OASIS (Open Artwork System Interchange Standard). So do parasitic files and signoff artifacts. A first import has no layout, routing or extraction to write, so none of them is run here.

11.8  Summary of the artifacts

12  Lab: one controlled import, judged, saved, restored and exported

Goal. Review an approved input package and import it once through one timing-enabled route. Judge the result with the nine checks. Save an accepted checkpoint only if the judgment allows it. Restore it in a fresh session, compare it with the saving run, and try the three small exports.

12.1  Where each thing runs

The lab in eight steps

Which place each step uses, and where a failed check sends you

What to notice: A check left at investigate or stop sends you back to Step 2, in a new folder, not forward to the save.

The restore is a separate, fresh session, started later in a new folder. When Innovus runs interactively, the exit status of the process is not available until the process ends. While the session is open, its status is pending, which is not a failure. The launch commands below capture it automatically when the process returns.

Steps 1 to 4 run in one Bash session, the launch terminal, so the variables set in Step 1 stay available. The reading terminal is a separate shell and needs none of them.

12.2  Step 1. Review the inputs

This is the package review from "Conditional inputs, alternatives, and reviewing a package", applied to your package. The paths below are examples. Replace them with your own absolute paths, then run the block in the launch terminal. A path that contains spaces needs quotes in Bash and braces in Tcl.

$ TOP="demo_top"   # example top name; use yours
$ NETLIST="/proj/demo/inputs/demo_top.v"   # example absolute netlist path
$ VIEWFILE="/proj/demo/inputs/viewDefinition.tcl"   # the view definition file
$ LEFS=("/proj/demo/inputs/tech.lef" "/proj/demo/inputs/stdcells.lef")   # tech first
$ D=/proj/demo/inputs   # the example input folder
$ NESTED=("$D/stdcells_slow.lib" "$D/stdcells_fast.lib")   # Liberty files
$ NESTED+=("$D/sram_slow.lib" "$D/sram_fast.lib")   # macro Liberty files
$ NESTED+=("$D/rc_slow.captbl" "$D/rc_fast.captbl")   # RC data
$ NESTED+=("$D/func.sdc" "$D/test.sdc")   # constraint files

$ unusable=0   # count of inputs that fail the check
$ for f in "$NETLIST" "${LEFS[@]}" "$VIEWFILE" "${NESTED[@]}"; do   # check each input
    if [ -f "$f" ] && [ -r "$f" ] && [ -s "$f" ]; then
      echo "ok       $f"
    else
      echo "UNUSABLE $f"; unusable=$((unusable+1))
    fi
  done
$ echo "unusable inputs: $unusable"   # must print 0
$ for f in "$NETLIST" "$VIEWFILE"; do echo "== $f"; head -n 3 "$f"; done   # first lines
$ grep -n -w "module $TOP" "$NETLIST"   # hint only: possible top definitions
$ grep -n -E "sdc_files|timing|cap_table|qx_tech_file" "$VIEWFILE"   # hint: references

• NESTED holds every file named inside the view file and the SDC files. Here that is four Liberty files, two capacitance tables and two SDC files. Add yours, and add an I/O file if your project has one, so that each gets the same check.
• If the count is not 0, or any line says UNUSABLE, do not continue. Fix the input with its owner.
• The macro LEF is left out of LEFS because the package review held it (Table 9). Its Liberty files stay in the library sets.

What the file check proves: each path resolves to a regular file, the account can read it, and it is nonempty. It does not prove correct syntax, the correct revision, a correct model, mutual consistency, or that Innovus parses it. A directory or an empty file fails the check, which a plain -⁠r or -⁠s test alone would not catch.

12.3  Step 2. Make a fresh run folder

$ RUN="$HOME/import_run_$(date +%Y%m%d_%H%M%S)"   # a new name from date and time
$ if [ -e "$RUN" ]; then   # refuse to reuse an existing folder
    echo "STOP: $RUN exists; wait a second and run this block again"
  elif mkdir "$RUN" && cd "$RUN"; then
    echo "working in $(pwd)"
  else
    echo "STOP: could not create $RUN"
  fi

12.4  Step 3. Write the import script

Create import.tcl in the run folder with your editor. The configuration is Path A from "The init_design import flow". Only the lines between the EDIT markers change. The values must be the same absolute paths that Step 1 checked. The paths and view names below are examples.

If you start from a project template, its values are written as REPLACE_NETLIST_PATH and similar. The guard and the grep below catch any you forgot to edit. With the example values shown here, both find nothing.

# ---- EDIT: values from your approved handoff, absolute paths ----
set init_design_netlisttype Verilog
set init_verilog [list /proj/demo/inputs/demo_top.v]
set init_design_settop 1
set init_top_cell demo_top
set init_lef_file [list /proj/demo/inputs/tech.lef /proj/demo/inputs/stdcells.lef]
set init_pwr_net VDD
set init_gnd_net VSS
set init_design_uniquify 1
set init_mmmc_file /proj/demo/inputs/viewDefinition.tcl
# If your project has an I/O file, add: set init_io_file /proj/demo/inputs/demo.io
# The views the manifest says must be active, by role.
set want_setup [list func_slow test_slow]
set want_hold [list func_fast]
# ---- END EDIT ----

# Refuse to run with a template marker left in any setting.
foreach g {init_verilog init_top_cell init_lef_file init_pwr_net \
           init_gnd_net init_mmmc_file init_io_file \
           want_setup want_hold} {
    if {[info exists $g] && [string match {*[R]EPLACE_*} [set $g]]} {
        error "placeholder left in $g"
    }
}
# Policy check: every input path, including an I/O file, must be absolute.
set path_list [concat $init_verilog $init_lef_file [list $init_mmmc_file]]
# An optional I/O file, set here or inherited, gets the same check.
if {[info exists init_io_file] && $init_io_file ne ""} {
    lappend path_list $init_io_file
}
foreach f $path_list {
    if {[file pathtype $f] ne "absolute"} {
        error "relative input path: $f"
    }
}

• Guards. Stop before init_design if a template marker such as REPLACE_ survives in any setting, or if an input path is relative. The path check also covers an optional init_io_file, whether you set it or the session inherited it. An inherited value is not cleared; it is reported and checked. The first letter of the marker pattern is in square brackets. That way the guard line itself does not match the search below.

# Record the release and the effective configuration.
puts "release: [getVersion]"
foreach g {init_design_netlisttype init_verilog init_design_settop \
           init_top_cell init_lef_file init_pwr_net init_gnd_net \
           init_design_uniquify init_mmmc_file init_io_file} {
    if {[info exists $g]} {
        puts "$g = [set $g]"
    } else {
        puts "$g is not set"
    }
}
# Record the check settings the import runs with.
getCheckMode -netlist -library
# Build the database.
init_design

• Effective configuration. Prints what the session will use, including the uniquify choice and the I/O file state. getVersion returns its value, so puts logs it.
• Import. getCheckMode records the check settings, then init_design builds the database.

# Baseline: the identity and views this run actually holds.
set fp [open baseline_top.txt w]
puts $fp [dbGet top.name]
close $fp
redirect views_setup.rpt {report_analysis_views -type setup}
redirect views_hold.rpt {report_analysis_views -type hold}
redirect views_all.rpt {report_analysis_views -type all}
# Compare setup and hold membership separately with the manifest.
set got_s [lsort [all_analysis_views -type setup]]
set got_h [lsort [all_analysis_views -type hold]]
set fp [open views_match.txt w]
foreach {role got want} [list setup $got_s $want_setup \
                             hold $got_h $want_hold] {
    if {$got eq [lsort $want]} {
        puts $fp "MATCH-MEMBERS $role $got"
    } else {
        puts $fp "MISMATCH $role active=$got wanted=[lsort $want]"
    }
}
close $fp

• Baseline. Records the top and the setup and hold lists of this run. views_match.txt says whether the membership of each role matches the manifest. It does not establish the default, because the lists are sorted first.

# Library, netlist and uniqueness evidence.
checkDesign -physicalLibrary -timingLibrary -noHtml \
    -outfile checkdesign.rpt
checkNetlist -outfile checknetlist.rpt
set uniq [checkUnique -verbose]
set fp [open checkunique_return.txt w]
puts $fp "checkUnique returned $uniq"
close $fp
redirect checkunique_verbose.txt {checkUnique -verbose}

# Per-view clock, constraint and coverage evidence.
set active_all [concat $got_s $got_h]
foreach v [lsort -unique [concat $want_setup $want_hold]] {
    if {$v ni $active_all} {
        puts "SKIPPED $v: not active, see views_match.txt"
        continue
    }
    redirect clocks_$v.rpt "report_clocks -view $v"
    redirect timing_$v.rpt "check_timing -verbose -view $v"
    redirect coverage_$v.rpt "report_analysis_coverage -view $v"
    redirect untested_$v.rpt \
        "report_analysis_coverage -view $v -verbose untested -sort reason"
}

# Prerequisite checks last: errors found here stop the script.
check_design -type {library netlist timing} -out_file check_design.tcl
puts "evidence written to [pwd]"

• Last check. check_design runs last, because errors found there stop the script.

• Evidence. Checks B to G, one file per view where the check is view-scoped. The checkUnique return value goes in its own file. A required view that is not active is skipped with a message, because the per-view reports are not defined for it. views_match.txt records the mismatch, which is a stop.

$ grep -n REPLACE_ import.tcl   # prints any line still holding a marker; expect none

If lines print, edit them. If a wanted view is not created by your view definition, views_match.txt will say so.

12.5  Step 4. Launch Innovus

$ if command -v innovus; then   # launch only if the executable is found
    # Record the launch context for the run.
    echo "cwd=$(pwd)" > launch_record.txt
    echo "date=$(date)" >> launch_record.txt
    echo "tmpdir=${TMPDIR:-unset}" >> launch_record.txt
    # Start the Legacy UI without the GUI; capture the exit status.
    innovus -legacy_ui -no_gui -abort_on_error -log import \
      -files import.tcl; rc=$?; printf '%s\n' "$rc" > import_exit_status.txt
  else
    echo "STOP: innovus not found; nothing was launched"
  fi

• -⁠legacy_ui selects the Legacy UI, which must not be mixed with Common UI commands (the newer command set).
• -⁠no_gui runs without the window. -⁠log import names the log. -⁠files import.tcl runs the script after startup.
• -⁠abort_on_error makes the process exit if an applicable error occurs. That includes a Tcl error that reaches the top level, not only the script.
• The status capture sits on the same command line, so that pasted lines are not typed into the Innovus prompt.
• Bash waits while the process is open. The capture runs when the process returns, by exit or by an error.

The tool creates a temporary directory per session. When TMPDIR is set, the directory goes inside it. Otherwise it goes in the current directory if writable, else in /tmp. The launch record above notes TMPDIR. Other tools may use a different order, so do not carry this rule over.

12.6  Step 5. Read the evidence

$ ls -l --time-style=full-iso   # every file should be from this run
$ cat baseline_top.txt views_match.txt checkunique_return.txt   # baseline facts

For each check, write the evidence, your intent and a decision, as in Table 14. For check D, also compare the first view of each activation list with the defaults your project intends. A keyword search through import.log helps you find where to read. It does not replace reading.

If a check is at investigate or stop, do not save an accepted checkpoint. A deliberately named debug checkpoint is a separate, project-approved action. It is not always possible after an aborting error. Exit, fix the cause at its owner, and begin again from Step 2 in a new folder.

12.7  Step 6. Save the checkpoint, only if the checks allow it

innovus> saveDesign accepted.enc ;# save the accepted database under a deliberate name
innovus> exit ;# end the session; the launch command then records the status

$ cat import_exit_status.txt   # the status of the Innovus process
$ ls -l accepted.enc   # the small restore file; not proof the save worked
$ ls accepted.enc.dat | head   # the saved directory, first entries

A zero status is necessary and is not proof of an accepted import. A nonzero status needs an explanation before you rely on any evidence. The listing shows that something was written. The checkpoint is attempted, and it is not yet verified.

12.8  Step 7. Restore in a fresh session and compare

$ if mkdir restore_try1 && cd restore_try1; then   # a new, empty folder
    echo "restoring from $(pwd)"
  else
    echo "STOP: could not create restore_try1"
  fi

Where the saved references point. Under the path policy, the default saveDesign stored absolute external references. So the restore folder's location does not matter for them. The checkpoint's real dependencies are what the save retained, not the strings typed in Step 1. Look at them read-only, without editing anything.

$ ls ../accepted.enc.dat   # list the saved directory; edit nothing inside it
$ grep -n -i -E "lef|lib|sdc" ../accepted.enc.dat/*.globals | head -n 20   # references

The .globals layout is release-specific, so this look is a hint. The restore log is the evidence of which dependencies resolved.

Your project may instead keep relative paths under a working-directory convention. That is a different, separately defined procedure. Save with -⁠user_path and restore from a directory with the same structure. Or use setImportMode -⁠syncRelativePath true, which synchronizes the relative paths in the saved .globals file to the current directory. It copies nothing and repairs nothing, so read the restore log afterwards. This lab does not use that branch.

# The saving run is the folder above this one.
set saved_run [file dirname [pwd]]
# The baseline recorded by the saving run is the source of intent.
set fp [open $saved_run/baseline_top.txt r]
set top [string trim [read $fp]]
close $fp
puts "restoring $saved_run/accepted.enc.dat as $top"
restoreDesign $saved_run/accepted.enc.dat $top
# Evidence from this attempt only.
set fp [open restored_top.txt w]
puts $fp [dbGet top.name]
close $fp
redirect restored_setup.rpt {report_analysis_views -type setup}
redirect restored_hold.rpt {report_analysis_views -type hold}
puts "restore evidence written to [pwd]"

$ innovus -legacy_ui -no_gui -abort_on_error -log restore \
    -files restore.tcl; rc=$?; printf '%s\n' "$rc" > restore_exit_status.txt   # status

The same two paths apply. On success the session stays open at its prompt, and Step 8 uses it. On failure the process has ended, so keep the folder and read restore.log first. Do not compare leftover files.

$ head -n 40 restore.log   # read the log from the top
$ grep -n -i -E "error|warn" restore.log | head -n 20   # helps you find where to read

$ for pair in "baseline_top.txt restored_top.txt" \
    "views_setup.rpt restored_setup.rpt" \
    "views_hold.rpt restored_hold.rpt"; do   # three separate pairs
    set -- $pair
    if [ -s "../$1" ] && [ -s "$2" ]; then
      diff "../$1" "$2" > "diff_${2%.*}.txt"
      rc=$?
      echo "$1 vs $2: diff status $rc (0 same, 1 differs, 2+ error)"
    else
      echo "UNKNOWN: $1 or $2 is missing or empty"
    fi
  done

Comparing a restore with its saving run

Three file pairs, compared one by one

What to notice: A status of 2 or a missing file means no comparison happened, which is not a match.

12.9  Step 8. Try the three exports

innovus> saveNetlist export_netlist.v ;# logical netlist, as Verilog
innovus> defOut -floorplan -netlist -unplaced \
    export_early.def ;# floorplan and unplaced netlist
innovus> writeTimingCon export_func_slow.sdc -view func_slow ;# constraints of one view
innovus> exit ;# end the session; the launch command then records the status

$ cat restore_exit_status.txt   # the status of the restore session
$ head -n 5 export_netlist.v   # netlist: not empty
$ tail -n 3 export_netlist.v   # netlist: not cut off
$ grep -n -w "module" export_netlist.v | head   # module statements appear somewhere
$ grep -n -E "^DESIGN|^ROW|^UNITS" export_early.def | head   # DEF: design and rows
$ tail -n 3 export_early.def   # DEF: the end text
$ grep -n -E "create_clock|set_input_delay|set_output_delay" \
    export_*.sdc   # constraints: clocks and boundary delays

12.10  What the lab does not establish

The lab does not show timing closure, routability, power connectivity or signoff readiness. It does not show that the constraints, corners or libraries are right. It does not run floorplanning, placement, clock tree synthesis, routing, extraction or signoff.

When you report the result, say which claim you earned. The claims are: inputs reviewed; import observed and judged; checkpoint saved; checkpoint restored and compared. Each is a different claim.

13  Evidence-reading exercises, with answers

These exercises need no tool. Each gives a short piece of illustrative evidence, like the ones in the post-import checks, and asks for a judgment. Cover the answer and decide first. The answers give a conclusion, a reason and the action or evidence needed.

13.1  Exercise 1: a package review

Proceed or stop?

13.2  Exercise 2: reading a configuration

set init_verilog [list data/demo_top.v]
set init_design_settop 0
set init_top_cell demo_top
set init_lef_file [list data/stdcells.lef data/tech.lef]
create_library_set -name libs_slow -timing [list data/stdcells_slow.lib]
create_delay_corner -name slow -library_set libs_slow \
    -rc_corner rc_slow
create_analysis_view -name func_slow \
    -constraint_mode func -delay_corner slow
set_analysis_view -setup {func_slow} -hold {func_slow}
init_design

13.3  Exercise 3: identity and views

declared top   : demo_top
loaded top     : demo_top
manifest setup : func_slow test_slow
manifest hold  : func_fast
active setup   : func_slow
active hold    : func_fast
defined views  : func_slow func_fast test_slow

Can you accept this database for the functional mode? For the test mode?

13.4  Exercise 4: a coverage report

view func_slow   (rows illustrative)
signal pin   reference pin   check   reason
u_reg1/D     u_reg1/CK       setup   const
u_reg0/D     u_reg0/CK       hold    false_path
u_reg0/D     u_reg0/CK       setup   no_startpoint_clock

Each row is one untested timing check. It gives the data pin, the clock pin it is checked against, the check type and the reason. For each reason, say what you would ask and of whom.

13.5  Exercise 5: a restore comparison

After a restore attempt, diff of the top names ends with status 0. The diff of a view report prints "No such file" and ends with status 2. A colleague says "the restore matched". Is that right?

13.6  Exercise 6: choosing an artifact

14  Troubleshooting and common mistakes

Look first, then change one thing at a time, and ask the right owner. The first-observation column of Table 18 only inspects. The fix column changes something, and it belongs after you have written the first observation down. A failed run keeps its folder.

15  Interview preparation

16  Chapter close

Compact glossary

One-page summary

Figure 1 at the start of the chapter is the whole chapter on one page. The summary below puts it in words.

Purpose. This chapter takes a delivered design package to a first checkpoint you can defend. It teaches what each input contributes and how the netlist, LEF and Liberty descriptions of a cell must agree. It shows how constraints and MMMC views are built and traced, and how the import is configured and followed. It closes with judging the database, and with what a checkpoint and each export can carry.

Key concepts.

• A successful import is the first rung of readiness, not proof of quality, closure or signoff.
• A bound name is not a correct model. Liberty cell presence is not arc correctness.
• LEF MACRO is a library cell definition, large or small, and an abstract is not a layout.
• Uniquification makes definitions independent, so implementation can change one instance without changing the others.
• Parsed SDC is not correct SDC. A listed clock needs its period, waveform and relationships checked.
• Defined, active and default views are three different things, and set_analysis_view is not incremental.
• Path A activates views in the view file. Path B activates them through init_design -⁠setup -⁠hold.
• A physical-only import has no timing system. Adding timing means a new session.
• The check commands are not aliases, and a settings query is not a result.
• A checkpoint is the handoff. Exports are views of it for other readers.

Common mistakes.

• Reading "no errors" as "ready".
• Accepting a text hit for the top name, or assuming a global's value without printing it.
• Calling init_design a second time to repair the first.
• Treating an untested reason as a justification.
• Trusting an unscoped or stale report.
• Comparing a restore with today's configuration, or setup and hold as one combined list.
• Handing over an exported netlist or DEF as if it were the design, or reading a directory listing as a verified save.

One-page command cheat sheet

innovus> set init_verilog [list a.v b.v] ;# netlist files
innovus> set init_design_settop 1 ;# we name the top
innovus> set init_top_cell demo_top ;# the top module
innovus> set init_lef_file [list tech.lef cells.lef] ;# technology LEF first
innovus> set init_pwr_net VDD ;# global power net
innovus> set init_gnd_net VSS ;# global ground net
innovus> set init_design_uniquify 1 ;# uniquify while reading
innovus> set init_mmmc_file view.tcl ;# Path A: the view file activates views
innovus> init_design ;# build the database
# Path B instead (abbreviated): objects created first, then
# init_design -setup {func_slow} -hold {func_fast}

innovus> puts [dbGet top.name] ;# identity
innovus> report_analysis_views -type setup ;# setup views
innovus> report_analysis_views -type hold ;# hold views
innovus> checkDesign -physicalLibrary -timingLibrary -noHtml \
    -outfile a.rpt ;# library binding
innovus> checkNetlist -outfile b.rpt ;# netlist structure
innovus> redirect c.rpt {check_timing -verbose -view func_slow} ;# per-view check
innovus> saveDesign accepted.enc ;# only after the evidence is read

innovus> restoreDesign accepted.enc.dat demo_top ;# then compare top, setup, hold
innovus> saveNetlist n.v ;# logical netlist
innovus> defOut -floorplan -netlist -unplaced e.def ;# default geometry
innovus> writeTimingCon c.sdc -view func_slow ;# constraints of one view

Rules. Use a new session for every retry. Print the globals you depend on. Read each report for its view and run. Save only after the checks are read. Call the save verified only after a fresh restore matches.

Where the next chapter goes, and why

You now hold a checked, saved first database and a precise list of what it does not prove. Its die, rows and tracks are only defaults from init_design. Floorplanning replaces them with deliberate choices: die and core size, aspect ratio, macro positions and pin placement. Those choices only make sense on a database whose identity, models, views and constraints you have already judged. That is why this chapter comes first.