Updating Timing

Part II · Module 22 · Chapter 22.5 · Updating Timing

By now the session has a netlist, libraries, parasitics and constraints. None of that has computed anything.

The timing update is the step that does: it builds the timing graph, propagates arrival and required times through it, and produces the slack numbers every report then reads out. It is where the time goes, and it is the step people skip.

1. Before the update

read_netlist $NETLIST
read_libs    [list [lib_for $CORNER]]
read_sdc     $SDC
puts "    report_timing -> [catch {report_timing} e] / $e"
puts "    worst_slack   -> [catch {worst_slack} e] / $e"

=== reporting before the timing update ===
    report_timing -> 1 / timing has not been updated
    worst_slack   -> 1 / timing has not been updated

Everything is loaded and there are no numbers, because nothing has been computed. The inputs describe a design; they do not constitute an analysis.

2. After it

=== after update_timing ===
    update_timing built 5 path(s)
    worst_slack   -> -0.168

Now there are numbers. The update walked the graph once and every subsequent report is a cheap read of the result — which is why the tool separates the two: you build once and report many times.

3. What it actually does

Three steps, worth knowing because they explain what each earlier phase contributed:

• Build the graph. Every timing path through the netlist, derived from the connectivity (Chapter 22.2).
• Propagate delays. Cell delays from the libraries, wire delays from the parasitics (Chapter 22.3).
• Compare against requirements. Arrival versus required time, from the constraints (Chapter 22.4) — which is where slack comes from.

If any of those inputs was missing or wrong, this is the step that bakes it into every number. A missing parasitic file does not fail here; it gets an estimate and carries on.

4. Reading anything invalidates it

This is the half that catches experienced users.

update_timing
puts "    worst_slack -> [worst_slack]"
read_sdc $SDC                               ;# anything that changes the inputs
puts "    worst_slack -> [catch {worst_slack} e] / $e"

=== a valid report ===
    worst_slack -> -0.168

=== now something changes: more constraints are read ===
    worst_slack -> 1 / timing has not been updated
    -> reading anything INVALIDATES the graph; update again
    after re-updating: worst_slack -> -0.168

5. Tools differ, so update explicitly

Real tools vary in whether the update is implicit. Some rebuild automatically when a report is requested; some require the command; some do either depending on a setting. I cannot verify any particular tool's behaviour here.

The rule that works regardless:

Update explicitly, after the last thing that changes the inputs, and before the first report.

# load everything
read_netlist    $NETLIST
read_libs       $LIBS
read_parasitics $SPEF
source          $SDC

# then, once
update_timing

# then report
report_timing
report_all_violators

An explicit update when the tool would have done it anyway costs nothing. A missing one when the tool would not have is a stale report, and stale reports look fine.

6. It is the expensive step

On a real design the update is where the minutes or hours go — the reports afterwards are nearly free.

Two consequences for how a script is written:

Do all the cheap checking first. Everything in Chapters 22.1 through 22.4 — paths exist, netlist is fresh, corner is coherent, constraints applied — costs seconds. Doing it before the update means a run that cannot be meaningful stops before the expensive part, which is Chapter 21.7 §6's argument again.

Update once, report many times. Having paid for the graph, extract everything you need from it: the worst paths (Chapter 22.6), the all-violators report (Chapter 22.7), the summary numbers. Re-running the analysis because you forgot a report is the avoidable cost in this flow.

So the checklist for a timing phase is: check cheaply, load, update once, report everything, then move to the next corner — which is Chapter 22.8's loop.

7. Exercises

Exercise 1. What does the timing update do, in three steps?

Exercise 2. Why does a report requested before it fail or mislead?

Exercise 3. What happens to the computed timing when you read more constraints?

Exercise 4. The mock refuses a stale query. What might a real tool do instead, and why is that worse?

Exercise 5. Tools differ on implicit updates. What rule works either way, and what does an unnecessary update cost?

Exercise 6. Why should loading and reporting not be interleaved?

Exercise 7. Give two consequences of the update being the expensive step.