Design Import: Building a Clean Timing Database

Chapter overview

In Getting Started with Tempus we launched the tool and reached the tempus> prompt. The session is still empty. Before any timing number means anything, the tool must hold four inputs – libraries, netlist, constraints and parasitics – linked into one database.

This step is called design import. It looks simple, just a handful of read commands. However, the order of those commands matters. A wrong order can fail loudly or, worse, load a design that is only partly correct.

Let us consider a common case. A designer reads the DEF file before the netlist. The DEF refers to instances that do not exist yet, so the read fails or matches nothing. That one is easy to spot. A missing library cell or a skipped check is much harder to spot. The import finishes, the reports print, and the numbers are quietly wrong.

This chapter shows how to avoid both kinds of problem. We first list what the tool needs. Then we read libraries, load the design in a safe order, check it, and save it for later runs.

Learning objectives

1. List the required and optional inputs for a timing run, and the command that reads each one.
2. Explain what it means that the database is MMMC-configured by default.
3. Read libraries with read_lib, and choose between its -⁠min, -⁠max, -⁠cdb, -⁠lef and -⁠pgv options.
4. Load a non-MMMC design, with and without physical data, in the correct order.
5. Load an MMMC design for a logical, a LEF/DEF and an OA database.
6. Explain what set_top_module does and why the netlist must link cleanly.
7. Recognize the default_emulate_* names in a non-MMMC report.
8. Run check_design, check_library and check_timing at the right moments.
9. Save a session with save_design and restore it with read_design.

Chapter roadmap

The chapter moves from what the tool needs, to how to load it, to how to keep it. Figure 1 shows the order. Come back to it whenever you lose your place.

Design import on one page

Five steps from the list of inputs to a saved session

Key commands

Table 1 lists the commands in this chapter, grouped by section. Each one is explained where it is first needed.

1  What the tool needs to import

1.1  The concept

The tool times a design database. This is one linked structure that holds every cell, net, library model, constraint and wire parasitic. Every report in this series is read from it.

A useful picture is a workshop. The netlist is the wiring diagram. The libraries are the catalog that says how fast each part is. The constraints are the job sheet that says how fast the whole machine must run. The parasitics describe the real wires between the parts. Only when all four sit on one bench can anyone answer "is it fast enough?"

The database can be one of two kinds:

• Logical – built from the netlist, libraries, constraints and parasitics alone. This is typically enough for timing reports that need no layout information.
• Physical – the same, plus physical data. This can come from LEF and DEF files, from an Innovus database, or from an OpenAccess (OA) database.

Why would a timing run need physical data at all? Some analyses use the size or layout of the chip. For example, AOCV can look up derates by chip or core size, taken from physical data. Analysis Modes, CPPR and AOCV shows this case.

1.2  MMMC-configured by default

By default, the database is MMMC-configured. MMMC stands for multi-mode multi-corner. A corner is a set of process, voltage and temperature conditions, such as "slow silicon, 0.9 V, 125 °C". A mode is a set of constraints, such as "functional" or "test". One corner plus one mode is called an analysis view. Strictly, the corner of a view is a delay corner, which also includes an RC corner for the wires. Multi-Mode Multi-Corner Analysis builds on this.

An MMMC-configured database is ready to hold several views, even when you load only one. Thus, the tool always thinks in views. When you load a single corner without naming any views, the tool still builds one view for you. We look at that view in Section 3.

1.3  Required and optional inputs

Table 2 lists the four inputs that every run needs, and the inputs that some flows add.

Let us look at what each required input brings, and what goes wrong without it:

• Libraries give each cell its delay, output slew and timing checks such as setup and hold. Without the right library, a cell has no timing model at all.
• The netlist says which cells exist and how they connect. A stale netlist gives correct numbers for the wrong design.
• Constraints define clocks, input and output delays and exceptions. Without a clock, no register-to-register path is checked.
• Parasitics give the resistance and capacitance of every net. Without them, wire delay and the load seen by each driver are wrong.

For parasitics there are two commands. read_spef reads a SPEF (standard parasitic exchange format) file. read_parasitics reads SPEF plus an RC database, and it can also read a pre-built RC database. Both lead to the same result: every net gets its wire resistance and capacitance.

Figure 2 shows the same inputs as a picture. On the left are the required inputs; on the right, the optional ones.

From input files to a timing database

Four required inputs and three optional ones

1.4  Why SDF needs special care

SDF (standard delay format) is a file of delay numbers computed somewhere else. When the tool reads it with read_sdf, the annotated delays override its own delay calculation for those arcs. Figure 3 shows the difference on one gate.

In the left panel, the tool computes the A-to-Y delay from the library table and the parasitics. In the right panel, the same arc simply takes the number from the SDF file. Thus, any later change to the library or the parasitics has no effect on that arc.

The same arc with and without SDF

Calculated delay on the left, annotated delay on the right

1.5  Setting the process node first

Many import scripts begin with one more line, before any library is read:

tempus> set_design_mode -process 28   ;# node defaults for a 28 nm design

The -⁠process value names the technology node, here 28 nm. The tool then picks default settings that suit that node. It belongs at the very top, so every later step sees the same defaults. If it comes later, part of the setup may already have used other defaults. Base Delay Calculation returns to this setting.

Figure 4 compares the two placements in a short script. In row A, the node is set first, so every read runs with the same defaults. In row B, the libraries and netlist were already read before the node was set.

Where set_design_mode -process belongs

The same six steps in two orders

2  Reading libraries with read_lib

2.1  The concept

read_lib is the command for every kind of library: timing, noise and physical. Its plain form reads Liberty (.lib) files. Options tell the tool how to use other files.

Why one command for so many kinds? Because all of them describe cells. A Liberty file says how fast a cell is. A noise file says how the cell reacts to coupling noise. A LEF file says what the cell looks like physically. The tool attaches all three to the same cell name.

2.2  Command breakdown

The general form is:

read_lib lib_files
    [-min lib_files]
    [-max lib_files]
    [-cdb noise_lib_list]
    [-lef lef_files]
    [-pgv pgv_list]

Let us go through each part. Figure 5, after the list, maps each kind of file to the way it is read.

• lib_files – the Liberty timing libraries. Without -⁠min or -⁠max, these are used for every check, early and late. This is the usual case for a single-corner run.
• -⁠min and -⁠max – separate library groups for early (min) and late (max) analysis. In best-case/worst-case analysis, setup uses the max group and hold uses the min group. If you omit them, the same libraries serve both. Mixing them up swaps fast and slow data, so hold and setup are both checked against the wrong numbers. Analysis Modes, CPPR and AOCV shows when the tool picks each group.
• -⁠cdb – noise libraries in cdB format, used for signal-integrity analysis. Noise data can also come inside the Liberty files, as CCS-N or ECSM-SI. Without any noise data, crosstalk and glitch analysis have nothing to work with. Signal Integrity Delay Analysis builds on this.
• -⁠lef – physical LEF files. They describe cell and layer shapes for physical flows. They must be read before the netlist. A pure logical run does not need them.
• -⁠pgv – a list of PGV library files. Basic timing import does not need it. Confirm its exact use with help read_lib before you add it to a script.

One command, six kinds of library input

The option decides how the tool uses each file

The following lines show the three most common forms.

tempus> read_lib -lef tech.lef cells.lef    ;# physical libraries, before the netlist
tempus> read_lib slow.lib                   ;# Liberty timing library
tempus> read_lib typ.lib -cdb typ.cdB       ;# timing library plus noise data

The third line attaches the noise data in typ.cdB to the cells of typ.lib. Both files should describe the same cells. Otherwise, the noise data has nothing to attach to.

3  Loading the design in the right order

3.1  Why order matters

Each read command adds to what is already in the database. Later steps refer to objects created by earlier ones. Thus, a step that runs too early points at things that do not exist yet.

Let us think about the dependencies in plain words:

1. The netlist names cells, so the cell definitions should already be there when it is linked.
2. The link step ties each instance to its library cell. It needs both the netlist and the libraries.
3. Constraints name clocks, ports and pins. These typically exist only after the design is linked.
4. Parasitics describe nets of the linked design.
5. DEF describes the placement of instances, using cells and layers from LEF. It needs the LEF, the netlist and the libraries.

3.2  Non-MMMC import with physical data

Let us start with the simplest complete flow: one corner, plus LEF and DEF. Figure 6 shows the seven steps in order.

The load order for a non-MMMC import

LEF first, the link in the middle, DEF last

The same flow as a script:

tempus> read_lib -lef tech.lef cells.lef   ;# 1 physical libraries first
tempus> read_lib slow.lib                  ;# 2 timing library
tempus> read_verilog top.v                 ;# 3 gate-level netlist
tempus> set_top_module top                 ;# 4 link and consistency check
tempus> read_sdc top.sdc                   ;# 5 constraints
tempus> read_spef top.spef.gz              ;# 6 parasitics
tempus> read_def top.def                   ;# 7 physical data, last

For a logical-only run, drop steps 1 and 7. The other five steps stay in the same order. Note that the SPEF file can be read compressed, as top.spef.gz shows.

3.3  Linking with set_top_module

A netlist only names cells, such as NAND2X1. It does not say how fast they are. Linking is the step that ties each instance to its library model.

set_top_module does this job. It names the top module, links every instance to a library cell, and checks that the netlist and libraries agree. For example, an instance of a cell that no loaded library defines cannot link. Figure 7 shows a small example.

What linking checks

Each instance must find its cell in a loaded library

In Figure 7, U1 links to NAND2X1 and R1 links to DFFX1. However, U2 refers to INVX2, which no loaded library contains. The path from R1 through U2 to port Z then has no timing model for U2. The usual fix is to add the missing library to the read_lib list and import again.

3.4  MMMC import

In an MMMC flow, you describe the analysis views in a Tcl file. read_view_definition loads that file. The file names:

• the library sets – which Liberty files belong to each corner,
• the RC corners – which parasitic conditions apply,
• the delay corners – a library set paired with an RC corner,
• the constraint modes – which SDC files make up each mode,
• the analysis views – a delay corner paired with a constraint mode.

Multi-Mode Multi-Corner Analysis teaches how to write this file. Here we only need the load order, which changes slightly. Table 3 shows the three database kinds.

Figure 8 shows the same three cases as lanes. The logical core is identical in each lane. Only the physical steps, shown in amber, are added around it.

MMMC load order for each database kind

One logical core, with physical steps added around it

tempus> read_lib -lef tech.lef cells.lef         ;# physical libraries first
tempus> read_view_definition viewDefinition.tcl  ;# libs, corners, modes, views
tempus> read_verilog top.v                       ;# netlist
tempus> set_top_module top                       ;# link and check
tempus> read_def top.def                         ;# physical data, last

Notice what is missing. There is no plain read_lib for timing and no read_sdc. In MMMC, the timing libraries and constraints are named inside the view file, per library set and per constraint mode. Parasitics are read after the views exist, one file per RC corner. Both are covered in Multi-Mode Multi-Corner Analysis.

3.5  What non-MMMC looks like inside the tool

In a non-MMMC flow, read_lib takes the place of read_view_definition. However, the database is still MMMC-configured. Thus, the tool wraps your single corner in MMMC objects with fixed names. Figure 9 compares the two flows.

MMMC and non-MMMC side by side

The same kind of database, built two ways

The six names, and the MMMC object each one stands for, are:

• default_emulate_view – the single analysis view.
• default_emulate_delay_corner – its delay corner.
• default_emulate_rc_corner – its RC corner.
• default_emulate_libset_max – the late (max) library set.
• default_emulate_libset_min – the early (min) library set.
• default_emulate_constraint_mode – the constraint mode built from your SDC.

3.6  The order rules in one place

The two rules from Figure 6 carry most of the risk:

1. read_lib -⁠lef comes before the netlist. Physical libraries must exist before read_verilog.
2. read_def comes after the LEF, the netlist and the libraries. DEF refers to all three.

Why does DEF care about the netlist? A DEF file places components by instance name, such as U1 and R1. Each name must match an instance that the linked netlist already holds. Figure 10 shows this match.

Why DEF must come after the netlist

DEF places instances by name, so the names must already exist

The link step sits between them. set_top_module must run after the netlist and libraries, and before constraints and parasitics.

4  Checking the import

4.1  Why it matters

A design can load without errors and still be wrong. A library can miss a cell. A constraint can point at a renamed pin. A clock can reach no flop. None of these stops the import, yet each one changes the results.

Let us consider one case. The netlist team renames a port from clk_in to clk_core. The old SDC still creates a clock on clk_in. The import completes, but no clock reaches the flops. Every register path is now unconstrained, and the setup report looks perfect. Only a check reveals the gap.

4.2  Command breakdown

The tool provides three checks. Each one looks at a different part of the database:

• check_design – checks the design data itself, such as the netlist after linking. Typical findings are unlinked or inconsistent objects.
• check_library – checks the loaded libraries. Typical findings are missing or incomplete library data for cells in use.
• check_timing – checks the timing setup, such as constraints that do not reach their targets. Typical findings are unclocked flops or unconstrained endpoints.

Figure 11 lays the three checks side by side. Each column shows what the check looks at and one typical finding.

Three checks, three parts of the database

Each check looks at a different part of the import

tempus> check_design    ;# design data after linking
tempus> check_library   ;# loaded libraries
tempus> check_timing    ;# constraints and timing setup

The exact messages each check prints depend on the design. Read every message, and either fix it or write down why it is safe.

4.3  When to run them

Run all three after import, and again after each major data change. A major change means a new SPEF, a new SDC, a new netlist or new libraries. Figure 12 shows this loop.

The check loop after import

Run all three checks after import and after every major data change

5  Saving, restoring and file housekeeping

5.1  Saving and restoring a session

A large import can take a long time. Thus, it is wasteful to repeat it for every report. save_design writes the whole session to disk. read_design brings it back in a new session.

The forms are:

save_design session_name
read_design session_name top_cell [-physical_data]

• session_name – the saved session on disk. Pick a name that says what it holds, such as the block and the data drop.
• top_cell – the top design to restore. It is required, so a restore always names both the session and the top cell.
• -⁠physical_data – also restores the physical data. Leave it out when the run only needs logical timing.

For an OA database, add -⁠cellview: save_design -⁠cellview to save, and read_design -⁠physical_data -⁠cellview to restore.

Figure 13 shows the flow across two sessions.

Import once, restore many times

A saved session replaces the full import in later runs

tempus> save_design blkA_s1                        ;# session 1: save after checks
tempus> read_design blkA_s1 dma_mac -physical_data ;# session 2: restore with physical data

A saved session is a snapshot. If the netlist, SDC, SPEF or libraries change, the snapshot is out of date. In that case, import again from the new files and save a new session.

5.2  Redirecting auto-generated files

The tool writes some files on its own during import and analysis. Two settings control them:

• auto_file_dir – the folder for auto-generated files.
• auto_file_prefix – a prefix added to their names.

These matter most when several runs share one directory. Without them, parallel runs can overwrite each other's files. With a separate folder or prefix per run, each run keeps its own files.

Figure 14 shows both cases. In the upper half, two runs write a file with the same name into one folder. The second run overwrites the first. In the lower half, each run has its own auto_file_dir, and both sets of files survive.

Parallel runs with and without auto_file_dir

Two runs, one folder, versus one folder per run

5.3  Where temporary files go

Import also writes temporary files. The TMPDIR rules from Getting Started with Tempus apply here:

• Set TMPDIR before launch, to a large local scratch disk. The default is /tmp.
• If the folder is not writable, the tool silently falls back to /tmp. If the disk has no space, the tool does not launch.
• Each session uses its own subfolder and deletes it at the end, even after a crash.
• The same rules apply to distributed runs.

6  Worked example: importing a block with physical data

Let us import a block named dma_mac, check it, and save it. The assumptions are stated as comments where they are used.

The task. You must time dma_mac at one slow corner, with placement data. Later runs should restart from a saved session.

Step 1 – set defaults and read libraries

# Assuming a 28 nm design and one slow corner (non-MMMC)
tempus> set_design_mode -process 28        ;# node defaults, first line
tempus> set_global auto_file_dir ./dma_auto ;# keep auto files per run
tempus> read_lib -lef tech.lef cells.lef   ;# physical libraries before the netlist
tempus> read_lib slow.lib                  ;# timing library

The process node goes first, so every later step uses the same defaults. The auto-file folder comes next, before the tool writes anything. LEF is read before the netlist, as rule 1 demands.

Step 2 – read and link the netlist

tempus> read_verilog dma_mac.v             ;# netlist
tempus> set_top_module dma_mac             ;# link; read every warning

This is the moment to stop and read the log. Every instance should link to a library cell. If any cell is missing, add its library and start again from Step 1.

Step 3 – constraints, parasitics and placement

tempus> read_sdc constraints.sdc           ;# clocks and port delays
tempus> read_spef dma_mac.spef.gz          ;# parasitics
tempus> read_def dma_mac.def               ;# physical data, last

The constraints and parasitics now attach to the linked design. DEF comes last, as rule 2 demands.

Step 4 – check, then save

tempus> check_design                       ;# design data
tempus> check_library                      ;# libraries
tempus> check_timing                       ;# constraints
tempus> save_design dma_s1                 ;# save only after clean checks

Look for three things in the check output: unlinked cells, missing library data, and unclocked or unconstrained endpoints. Save only when each message is fixed or understood.

Step 5 – restore in a later session

tempus> read_design dma_s1 dma_mac -physical_data   ;# replaces the reads of steps 1 to 3

One line now replaces all the read commands of the import. Because this run is non-MMMC, reports will name the view default_emulate_view. That is expected.

7  Common mistakes and how to catch them

Table 4 gathers the mistakes from this chapter, with the symptom you would see first.

8  Interview preparation

Chapter recap

Key takeaways

• Every run needs libraries, a netlist, constraints and parasitics. SDF, LEF and DEF are optional.
• SDF delays override the tool's delay calculation for the annotated arcs.
• The database is MMMC-configured by default. Non-MMMC runs get default_emulate_* objects.
• Order: set_design_mode -⁠process, LEF, libraries, netlist, set_top_module, constraints, parasitics, DEF.
• In MMMC, read_view_definition replaces the plain timing read_lib, and the view file names the constraints.
• Run check_design, check_library and check_timing after import and every major change.
• Save with save_design after clean checks; restore with read_design.

Command recap

Compact glossary

Practical perspective

On a real project, the import script is shared by many runs and many engineers. A wrong order or a skipped check repeats everywhere. Thus, it pays to keep one reviewed import script and check it once per data drop. Every other run then restores the saved session, which saves time and keeps all runs on identical data.

What comes next

The database is now complete and checked. In Base Delay Calculation, we see how library tables and wire parasitics become the delay of each cell and net.