Tcl · Module 26

The Driver Loop

Walking the scenario list is a nested foreach. Making one scenario's failure harmless to the rest is the part that takes thought — and the obvious fix produces a confident wrong number.

Advanced22 min readtcledapart-iimcmmautomationerror-handling

Part II · Module 26 · Chapter 26.5 · The Driver Loop

Chapter 26.4 produced a list of scenarios. Walking it is three lines of Part I:

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

foreach s $scenarios {
    apply_mode   [dict get $s mode]
    apply_corner [dict get $s corner]
    report_timing [dict get $s check]
}

That loop is correct for a plan with no mistakes in it, and plans have mistakes in them. The rest of this chapter is about what the loop does when one scenario fails, which is the only interesting question it raises.

1. The plan with one typo

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

set PLAN {
    {functional ss_0p72v_125c}
    {functional tt_0p80v_25C}
    {functional ff_0p88v_m40c}
}

The middle entry ends in 25C rather than 25c. That is not a contrived defect — it is what a hand-maintained list acquires, and Chapter 26.3 argued that corner names are identifiers rather than data precisely so that a typo in one is a lookup failure rather than a silently different corner.

So the lookup fails. The question is what the loop does about it.

2. Shape A: no isolation at all

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

foreach s $PLAN {
    apply_mode   [lindex $s 0]
    apply_corner [lindex $s 1]
    puts [format "%s %s worst setup %.4f" ... [worst_slack setup]]
}

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

=== the same plan, but the failure is not caught at all ===
    functional    ss_0p72v_125c  worst setup -0.4800
    loop aborted: 1 / no such corner: tt_0p80v_25C
    scenarios completed: 1 of 3

One of three. The error propagates out of the foreach, the loop stops, and the two remaining scenarios — including ff_0p88v_m40c, which is a required hold-sign-off corner — never run.

This is bad, and it is the good failure mode. It is loud, it names the cause, it reports 1 of 3, and nobody can mistake the run for complete. In a nightly flow it costs a night. It does not cost correctness.

3. Shape B: catch, and carry on

The obvious fix is to catch the error so the loop survives:

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

foreach s $PLAN {
    set mode [lindex $s 0] ; set corner [lindex $s 1]
    catch { apply_mode $mode ; apply_corner $corner }
    puts [format "%-13s %-14s %9.4f" $mode $corner [worst_slack setup]]
}

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

=== catching the error but reporting anyway ===
    MODE          CORNER             SLACK  NOTE
    functional    ss_0p72v_125c    -0.4800  session actually holds: functional ss_0p72v_125c
    functional    tt_0p80v_25C     -0.4800  session actually holds: functional ss_0p72v_125c
    functional    ff_0p88v_m40c     1.8980  session actually holds: functional ff_0p88v_m40c

Row two reports −0.4800 for tt_0p80v_25C. That is the slow corner's number, under the typical corner's name.

apply_corner raised, so the session's corner was never changed. It still held ss_0p72v_125c from the previous iteration. worst_slack then ran happily against that stale state and returned a real, correct, completely mislabelled number.

Three rows, all plausible, one of them a lie — and the lie is the kind nobody questions, because −0.4800 at typical is worse than expected rather than better, so it reads as a legitimately bad result rather than an error.

Shape B is worse than shape A. Shape A loses data loudly; shape B fabricates it quietly. A loop that catches an error and continues without undoing what the failed iteration half-did has converted a visible failure into a wrong answer.

This is the same shape as every central finding in Part II — Chapter 24.1 §7's truncated slack, Chapter 25.4 §2's failing test exiting 0, Chapter 25.5 §3's PASSED row pointing at a FAILED log. A correct mechanism, applied to state it did not establish, producing a confident number.

Note also what made the lie visible here: the loop printed session_state beside each row. A driver that reports what the session actually holds, rather than what the plan said it should hold, turns this defect from invisible into obvious — which is the cheapest possible instrumentation.

4. Shape C: reset first, then apply

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

foreach s $PLAN {
    set mode [lindex $s 0] ; set corner [lindex $s 1]
    reset_session
    if {[catch { apply_mode $mode ; apply_corner $corner } e]} {
        puts [format "    %-13s %-14s %9s  SKIPPED: %s" $mode $corner "-" $e]
        continue
    }
    puts [format "    %-13s %-14s %9.4f" $mode $corner [worst_slack setup]]
}

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

=== with reset_session first, the failure cannot produce a number ===
    MODE          CORNER             SLACK  NOTE
    functional    ss_0p72v_125c    -0.4800
    functional    tt_0p80v_25C           -  SKIPPED: no such corner: tt_0p80v_25C
    functional    ff_0p88v_m40c     1.8980

Two scenarios ran, one was skipped by name with its reason, and nothing produced a number it was not entitled to.

The ordering is the whole fix, and it is counter-intuitive.

The instinct is to clean up after a failure — catch the error, then reset. That is too late in the wrong way: it leaves the window between the failure and the cleanup, and more importantly it assumes the failure is detectable. The thing being defended against is state surviving into the next iteration, so the reset belongs at the top of the iteration, before anything is applied.

Put another way: each iteration should assume the session is dirty and make it clean, rather than assuming the previous iteration left it clean. That is the same argument as Chapter 24.1 §4's parser clearing its accumulators on commit, and Chapter 25.5 §1's record carrying everything that identifies a run — in all three cases the defence is to make each unit of work self-sufficient rather than dependent on its predecessor's tidiness.

And continue rather than falling through: a skipped scenario must not reach the reporting code at all, because the reporting code's job is to format a result and it has no way to know there is not one.

5. The production loop

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

proc run_scenarios {scenarios} {
    set results {} ; set failures 0
    foreach s $scenarios {
        set mode   [dict get $s mode]
        set corner [dict get $s corner]
        set check  [dict get $s check]

        reset_session
        if {[catch { apply_mode $mode ; apply_corner $corner } e]} {
            incr failures
            lappend results [dict merge $s [dict create status SETUP-FAILED reason $e worst ""]]
            puts stderr "  $mode / $corner / $check — setup failed: $e"
            continue
        }
        if {[catch { worst_slack $check } w]} {
            incr failures
            lappend results [dict merge $s [dict create status ANALYSIS-FAILED reason $w worst ""]]
            puts stderr "  $mode / $corner / $check — analysis failed: $w"
            continue
        }
        lappend results [dict merge $s [dict create status OK reason "" worst $w]]
    }
    return [list $results $failures]
}

Five decisions, each one a lesson from an earlier module.

reset_session first, per §4.

Setup failure and analysis failure are separate statuses. SETUP-FAILED means the scenario could not be established — a typo, a missing library, a mode that does not exist. ANALYSIS-FAILED means it was established and the analysis broke. Those go to different people, which is Chapter 25.4 §7's argument about distinct exit statuses applied to a results table.

Every scenario produces a row, including the failed ones. A results list with the failures missing is a list whose length no longer matches the plan — and Chapter 26.6 depends on being able to compare those two numbers.

dict merge $s ... keeps the scenario's own identity in the result rather than rebuilding it. The row is the scenario plus what happened to it, so nothing downstream has to re-derive which mode a number came from.

Errors go to stderr, results to the returned list. A log and a data structure are different audiences, per Chapter 15.4.

6. What `catch` does not isolate

Being honest, because §4 reads like a solution and in a real tool it is a partial one.

The mock's reset_session clears two variables. A real tool session accumulates far more, and the things that leak between scenarios are:

Constraints. set_false_path and set_multicycle_path from the previous mode do not vanish because you sourced a different SDC. Most tools need an explicit reset_design or equivalent, and some exceptions survive even that.
Derates and operating conditions. A set_timing_derate applied for one corner stays applied. This one is particularly nasty because it changes numbers without changing anything a report prints about the configuration.
The timing graph. Even with constraints replaced, the previously computed graph may be reused unless invalidated — Chapter 22.5's entire subject, arriving as a cross-scenario hazard rather than a within-scenario one.
The design database itself. If a scenario modified the netlist — an ECO, a sizing experiment — nothing in a constraint reset undoes that.

The only complete isolation is a fresh process per scenario.

One tool invocation per scenario, each reading the design from disk, each writing to its own directory, each exiting. Nothing can leak because nothing is shared.

The cost is real and worth stating plainly: re-reading the netlist and the libraries for every scenario is minutes of setup per run, and with hundreds of scenarios that is the dominant cost of the whole flow. Which is exactly why people run many scenarios in one session, and exactly why §3's defect is common.

The usual compromise is one process per corner, looping over modes inside it — because the corner is what selects the libraries and parasitics, which is the expensive part, while the mode is constraints, which is the cheap part to reset. That is a defensible engineering trade and it is worth recognising it as a trade: it isolates the expensive leak and accepts the risk of the cheap one. If you take it, the constraint reset between modes is the thing that must be right, and it is worth testing deliberately rather than assuming.

Parallelism follows the same line. Scenarios are independent by construction, so the loop is embarrassingly parallel — but only across processes. Two scenarios in one interpreter are not independent at all, which §3 demonstrated.

7. Exercises

Exercise 1. Why is a typo'd corner name a lookup failure rather than a different corner?

Exercise 2. Shape A aborts after 1 of 3. Why is that the good failure mode?

Exercise 3. Shape B reported −0.4800 for the typical corner. Trace exactly how.

Exercise 4. Why is shape B worse than shape A?

Exercise 5. Why is the mislabelled row particularly unlikely to be questioned?

Exercise 6. What made the lie visible in the §3 output?

Exercise 7. Why does the reset belong at the top of the iteration rather than after the failure?

Exercise 8. Why continue rather than letting a skipped scenario fall through?

Exercise 9. Why are SETUP-FAILED and ANALYSIS-FAILED separate statuses?

Exercise 10. Why does every scenario produce a row, including the failures?

Exercise 11. Name three things that leak between scenarios in one tool session.

Exercise 12. What is the only complete isolation, what does it cost, and what is the usual compromise?

Answers.

1. Because the name is an identifier used to look up a dict entry, not the data itself. A name that does not match any entry has no data, so the lookup raises rather than silently selecting something.

2. Because it is loud: it names the cause, reports 1 of 3, and nobody can mistake the run for complete. It costs a night, not correctness.

3. apply_corner raised, so the session's corner was never updated and still held ss_0p72v_125c from the previous iteration. worst_slack then analysed that stale state correctly and the loop printed the result under the new scenario's name.

4. Because shape A loses data loudly while shape B fabricates it quietly. Catching an error and continuing without undoing what the failed iteration half-did converts a visible failure into a wrong answer.

5. Because −0.4800 at the typical corner is worse than expected, so it reads as a legitimately bad result rather than as an error. A number that is implausibly good invites scrutiny; one that is plausibly bad does not.

6. The loop printed the session's actual state beside each row, so the mismatch between the claimed corner and the held corner was visible.

7. Because the thing being defended against is state surviving into the next iteration. Resetting afterwards assumes the failure was detectable and leaves a window; resetting first makes each iteration assume the session is dirty and make it clean.

8. Because the reporting code's job is to format a result, and it has no way to know there is not one. A skipped scenario must not reach it.

9. Because they go to different people: a setup failure is a typo, a missing library or an undeclared mode — a flow problem — while an analysis failure is a problem with the analysis itself.

10. So the results list length still matches the plan, which is what lets the aggregation in Chapter 26.6 detect a missing scenario.

11. Any three of: constraints such as false paths and multicycles; derates and operating conditions; the previously computed timing graph; and the design database itself if a scenario modified it.

12. A fresh process per scenario. It costs re-reading the netlist and libraries every time, which dominates the flow at hundreds of scenarios. The usual compromise is one process per corner looping over modes inside it, because the corner selects the expensive data and the mode is only constraints.

Remember.

Walking the scenario list is a nested foreach. Making one failure harmless is the real work.
No catch aborts the loop — 1 of 3 — which is loud, names the cause, and costs a night rather than correctness.
catch without a reset is worse: the failed iteration leaves the previous scenario's state, so the next report is a real number under the wrong name.
A plausibly bad wrong number is never questioned. That is what makes shape B dangerous.
Print what the session actually holds beside every row — the cheapest instrumentation there is.
Reset at the top of the iteration, not after the failure. Each iteration assumes the session is dirty and makes it clean.
continue on a skipped scenario, so it never reaches the reporting code.
Separate SETUP-FAILED from ANALYSIS-FAILED — different causes, different people.
Every scenario produces a row, so the results length still matches the plan.
catch does not isolate constraints, derates, the timing graph, or the database.
Only a fresh process per scenario isolates completely; one process per corner looping over modes is the usual trade, and it is a trade.

Where this fits

Part of the Tcl curriculum.

1. The plan with one typo

2. Shape A: no isolation at all

3. Shape B: catch, and carry on

4. Shape C: reset first, then apply

5. The production loop

6. What catch does not isolate

7. Exercises

Where this fits

6. What `catch` does not isolate