Setting Up an STA Session

Part II · Module 22 · Chapter 22.1 · Setting Up an STA Session

Static timing analysis is where a design is signed off. The numbers it produces are the ones people commit to, which makes one question more important here than anywhere else in the flow:

Could somebody else reproduce this result?

That starts before any timing command, with where the run's inputs are written down.

1. What a timing session needs

Four things, and all of them are paths or names:

• The netlist — the gate-level design to analyse.
• The libraries — timing data for the corner being analysed (Chapter 22.3).
• The parasitics — extracted wire delay for that corner, if available.
• The constraints — the SDC (Chapter 22.4).

Plus the two decisions that tie them together: which design and which corner.

2. One file, no tool commands

# setup.tcl — everything the run depends on, in one place.
set ROOT    /private/tmp/m22
set TOP     cpu_top
set CORNER  slow
set CORNERS {slow typ fast}

set NETLIST [file join $ROOT synth_run netlist ${TOP}_mapped.v]
set SDC     [file join $ROOT sdc constraints.sdc]
set LIBDIR  [file join $ROOT lib]
set SPEFDIR [file join $ROOT spef]

proc lib_for  {c} { return [file join $::LIBDIR ${c}.lib] }

  top     : cpu_top
  corner  : slow   (of: slow typ fast)
  netlist : cpu_top_mapped.v
  sdc     : constraints.sdc
  lib slow  present
  lib typ   present
  lib fast  present

Four things that file gets right, and each is a Part I habit:

• $TOP appears once and everything else derives from it, so the netlist cannot be named after a different design — Chapter 21.3 §6.
• Paths built with file join, not concatenation (Chapter 12.10).
• lib_for derives a path from a corner name, so adding a corner is one entry in $CORNERS rather than four new variables. That is what makes Chapter 22.8's loop possible.
• show_setup prints what the run will use, including whether each library is actually there.

3. It contains no tool commands — deliberately

Notice what is not in that file: no read_netlist, no session variables, nothing tool-specific.

That is the point. A setup file of plain Tcl can be sourced in a plain tclsh and checked — paths resolved, files confirmed present, the corner list validated — with no licence and no session.

4. Tool variables, where they do belong

Real tools have their own session variables — search paths, library lists, analysis-mode settings. They differ by vendor and I will not guess at names; find yours once with the discovery technique from Chapter 17.1 §3:

info commands *search*
info commands *link*

and the reference (Chapter 17.6).

Set them in one place, derived from the plain variables above:

# tool_setup.tcl — the only file with tool-specific settings in it
source [file join $here setup.tcl]
set <tool_search_path>  [list $LIBDIR $SPEFDIR]
set <tool_link_library> [lib_for $CORNER]

Two files: one portable and checkable, one tool-specific and short. Changing tools then means rewriting the short one.

5. Print it, every run

show_setup

Four lines of output at the top of every log, and they answer the first question of every disagreement — exactly Chapter 17.4 §5's argument, which applies with more force here because these numbers get signed off.

Worth including beyond the paths:

• The tool and version — info patchlevel plus whatever the tool reports.
• The corner, prominently. A report that does not say which corner it came from is not interpretable.
• The netlist's provenance — Chapter 22.2 §3 reads the record Module 21 wrote beside it.

6. Settings that change the answer

One category deserves naming now, because it is the source of the most confusing disagreements: analysis-mode settings.

Tools have options that change how pessimistically timing is computed — how much of the clock-path uncertainty is shared between launch and capture, whether certain derating is applied, which checks are enabled. Two runs with different settings produce different numbers from the same netlist, constraints and libraries.

Three rules, and they are the same shape as Chapter 21.7 §3's for compile options:

• Set them explicitly rather than relying on the tool's default, which can change between versions.
• Set them in the one setup file, so they are not scattered.
• Print them, so the log records what analysis the numbers came from.

A signoff number whose analysis settings are unrecorded is a number nobody can defend when it is questioned — and at signoff it will be questioned.

7. Exercises

Exercise 1. Name the four inputs a timing session needs, plus the two decisions.

Exercise 2. Why does $TOP appear only once in the setup file?

Exercise 3. Why write lib_for as a procedure rather than three library variables?

Exercise 4. Why does the setup file deliberately contain no tool commands?

Exercise 5. Why does licence-free checking get run more than licence-requiring checking?

Exercise 6. What should be printed at the top of every STA log?

Exercise 7. Why set analysis-mode options explicitly rather than taking the defaults?