Reporting Paths

Part II · Module 22 · Chapter 22.6 · Reporting Paths

With timing updated, the numbers exist. The path report is how you look at them — and the first thing to be clear about is what question it answers.

1. What it is for

report_timing shows you paths: where they start, where they end, what the delay was made of, and how much slack is left. It is a triage instrument — you use it when you know something is failing and you want to understand why.

It is not a closure test. "Is this design closed" is a different question, and Chapter 22.7 answers it. Using a path report to decide closure is the single most common misreading in timing work, and §3 is about why.

2. How many paths

foreach n {1 3} {
    puts "    worst $n path(s):"
    foreach p [report_timing $n] {
        lassign $p ep slack clk
        puts [format "      %-22s %7s  %s" $ep $slack $clk]
    }
}

=== 22.6 report_timing: how many paths, and what they tell you ===
    worst 1 path(s):
      u_io/u_sync/D           -0.168  io_clk
    worst 3 path(s):
      u_io/u_sync/D           -0.168  io_clk
      u_core/u_pipe_reg/D      0.142  core_clk
      u_mem/u_bank0/D          0.177  core_clk

3. Why it is not a closure test

A path report shows the worst n paths. If n is 1 and there are four hundred violations, you see one of them.

So a clean-looking path report proves nothing about closure:

• It may show a positive worst path for the paths it selected while violations exist elsewhere.
• Narrowing it by clock or endpoint — §4 — narrows what it can find.
• A path report with filters is answering a question about a subset.

Chapter 22.7 exists precisely because "how many violations are there" needs a command that does not take a path count.

4. Controlling what it selects

Real tools give report_timing extensive options, and they are vendor-specific. The categories are consistent, and knowing them tells you what to look for in the reference (Chapter 17.6):

The -from/-to/-through family is the same idea as the exception scoping in Chapter 20.5 §6 — and the objects come from the queries in Module 18, so an empty selection fails the same silent way:

set eps [get_pins -hierarchical u_mem/*/D]
if {[sizeof_collection $eps] == 0} {
    error "no endpoints matched" {} {STA NOENDPOINTS}
}
report_timing -to $eps

A -to that matched nothing produces an empty report, which reads exactly like "no paths here are failing" — Chapter 18.8 in its most expensive location.

5. Capture it as data as well as text

The full path report is for a human: it shows every cell and net, and that is how you find out why a path is slow.

But the summary numbers should also be extractable, because that is how runs get compared — the pattern from Chapter 21.8 §5:

foreach p [report_timing 20] {
    lassign $p endpoint slack clock
    puts $fp [format "%-28s %8s %s" $endpoint $slack $clock]
}

One line per path, machine-readable. Then "which endpoints got worse since last week" is a comparison outside the tool (Chapter 16.3 §5) rather than two people reading two long reports.

6. Reading a path report

What to look at, in order, when triaging one:

1. The endpoint and its clock. Which domain is failing tells you which constraint governs it.
2. The slack. How far off, which decides whether this is a tweak or a redesign.
3. The startpoint. Together with the endpoint this says whether the path crosses hierarchy or domains.
4. Where the delay accumulates — cells or wires. A path dominated by wire delay is a placement problem; one dominated by cell delay is a logic-depth or sizing problem.
5. Whether an exception should apply. Sometimes the honest answer is that this path is a false path nobody declared — and sometimes that is wishful thinking, which Chapter 20.6 §6 warned about.

Point 4 is the one that decides who fixes it, and it is the main reason to look at a detailed path report rather than a slack number.

7. Exercises

Exercise 1. What question does a path report answer?

Exercise 2. The worst path is -0.168 and the next two are positive on another clock. What does that tell you?

Exercise 3. What would the same report mean if the next two were -0.160 and -0.155?

Exercise 4. Why is a clean path report not evidence of closure?

Exercise 5. A -to selection matches nothing. What does the report look like?

Exercise 6. Why capture the paths as one line each as well as the full text?

Exercise 7. Which part of a path report decides whether it is a placement problem or a logic problem?