Tcl · Module 22

Reporting Every Violation

One command answers whether the design is closed. Everything else answers how some particular path behaved — and a zero from a report nobody ran looks exactly like a zero from a design that passes.

Advanced15 min readtcledapart-iistaviolationssignoffclosure

Part II · Module 22 · Chapter 22.7 · Reporting Every Violation

Chapter 22.6 ended on a distinction worth restating: a path report tells you about paths. Whether the design is closed is a different question, and it has its own command.

1. The question it answers

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

set bad [report_all_violators]
if {[llength $bad] == 0} {
    puts "    no violations"
} else {
    puts "    [llength $bad] violation(s):"
    foreach p $bad {
        lassign $p ep slack clk
        puts [format "      %-22s %7s  %s" $ep $slack $clk]
    }
}

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

=== 22.7 report_all_violators: is the design closed? ===
    1 violation(s):
      u_io/u_sync/D           -0.168  io_clk

One violation, out of five paths in the session. Every failing endpoint, not a selection of them — which is the property that makes it a closure test.

Three things that gives you that a path report does not:

A count. The number of failing endpoints, which is the figure people actually quote.
Completeness. Nothing was filtered out, so "zero" means zero.
The distribution of failures, rather than the worst example of one.

2. The count is the number that matters

"Worst negative slack is -0.168" and "there is one violation at -0.168" sound similar and are not.

One violation at −0.168 is a path somebody fixes this afternoon.
Four hundred violations, worst −0.168 is a systemic problem, and the worst number is the least informative thing about it.

The worst number alone cannot distinguish those. The pair — count and worst — is the minimum honest summary of a timing run, and it is what belongs in the quality report from Chapter 21.8 §1.

3. Both checks

Setup and hold are separate checks that fail in opposite directions (Chapter 20.6 §2), and a design can be clean on one and not the other.

An all-violators report must cover both, or it answers half the question. In Chapter 22.8 this becomes sharper still: setup violations cluster at the slow corner and hold violations at the fast one, so a run that checks only setup at only the slow corner can report a closed design that is not.

4. A zero needs proof the report ran

Here is the hazard specific to this command.

"Zero violations" from a report that never ran is indistinguishable from "zero violations" from a design that passes.

The ways to get a spurious zero are all quiet:

The report was not run at all, and the summary defaulted to zero.
Timing was never updated (Chapter 22.5), so there was nothing to violate.
The design is unconstrained (Chapter 22.4 §1) — no requirement, no violation.
The netlist linked to nothing (Chapter 22.2 §1) — no paths at all.

Every one produces a clean report, and a clean report is the one nobody questions.

So a zero has to come with evidence that there was something to count:

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

set paths [sizeof_collection [get_cells -hierarchical *]]
if {$paths == 0} { error "no design to analyse" {} {STA EMPTY} }
if {!$::sta::updated} { error "timing never updated" {} {STA STALE} }

set bad [report_all_violators]
puts "  endpoints analysed : [llength $::sta::paths]"
puts "  violations         : [llength $bad]"

Report the denominator. "0 violations out of 18,422 endpoints" is a result. "0 violations" is a claim.

That is the same move as Chapter 19.5 §6's preview and Chapter 20.8 §3's ok lines: a check that reports what it examined is one you can believe.

5. Make it machine-readable

The all-violators report on a failing design can be enormous. Two outputs rather than one:

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

# for a human
write_report [file join $rundir reports violators.rpt] $full_text

# for comparison
set fp [open [file join $rundir reports violators.txt] w]
foreach p $bad {
    lassign $p ep slack clk
    puts $fp [format "%-28s %8s %s" $ep $slack $clk]
}
close $fp

One endpoint per line makes the questions people actually ask cheap, and all of them happen outside the tool (Chapter 16.3 §6):

Which endpoints are new since last week?
Which got worse?
Are the failures concentrated in one block?

That last one is usually the most useful and is a sort on the hierarchy prefix — Part I list work over a small file.

6. What to do with the result

The count drives the flow's decision, and it should do so mechanically:

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

set violations [llength [report_all_violators]]
set wns        [worst_slack]
puts "  violations $violations, wns $wns"
if {$violations > 0} {
    puts stderr "  design is NOT closed at the $CORNER corner"
    exit 1
}

Two points worth being deliberate about.

The exit status. Chapter 15.4 §6 — a timing run that found violations should tell the surrounding automation, or a flow proceeds to tape-out preparation on a design that is not closed.

A threshold is a policy, not a fact. Some flows accept violations above a small negative number during development. That is legitimate and it must be explicit:

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

set ACCEPTABLE_WNS -0.050     ;# development only; signoff requires 0
if {$wns < $ACCEPTABLE_WNS} { exit 1 }

A threshold written down is a decision. A threshold applied by somebody's judgement each time is how a design drifts.

7. Exercises

Exercise 1. What question does the all-violators report answer that a path report cannot?

Exercise 2. Name the three things it gives you beyond the worst path.

Exercise 3. Why are "worst slack −0.168" and "one violation at −0.168" different statements?

Exercise 4. Name four ways to get a spurious zero.

Exercise 5. What should accompany a reported zero, and why?

Exercise 6. Why write the violators as one line per endpoint as well as the full report?

Exercise 7. Why must an acceptable-slack threshold be written down?

Answers.

1. Whether the design is closed. A path report shows the worst n paths, possibly filtered, so it cannot establish that nothing else is failing.

2. A count of failing endpoints; completeness, so zero means zero; and the distribution of failures rather than one example.

3. Because the first says nothing about how many paths fail. One violation is an afternoon's work; four hundred at the same worst slack is systemic, and the worst number is the least informative thing about it.

4. Any four of: the report was never run; timing was never updated; the design is unconstrained; the netlist linked to nothing.

5. The denominator — how many endpoints were analysed. "0 out of 18,422" is a result; "0" is a claim.

6. So that comparing runs — what is new, what got worse, which block is concentrating failures — happens cheaply outside the tool.

7. Because a threshold applied by judgement each time lets a design drift. Written down, it is a decision that can be reviewed and tightened for signoff.

Where this fits

Part of the Tcl curriculum.