Path-Based vs. Graph-Based Timing Analysis
In the previous article we looked at how the timing estimate improved from stage to stage. In this article we look at the analysis itself. Every timing report in this course so far has been produced in one particular mode, graph-based analysis (GBA), and it has not mattered until now. GBA is the default for a good reason: it is fast enough to run on a full chip in minutes and it does not miss real violations. Its weakness is that it can report some paths as worse than they really are, and at signoff that pessimism starts to cost you.
How graph-based analysis gets its speed
An STA engine like OpenSTA does not walk every startpoint-to-endpoint path one by one. For any real design the number of distinct paths through the fan-out and fan-in of the netlist is astronomically large. Instead it builds a timing graph. Every pin is a node, every cell arc and every net is an edge with a delay, and the engine propagates forward from the clock edges, computing at each node the worst arrival time and the worst transition time (slew) coming in from any of its fan-in edges.
Once a node has its worst arrival and worst slew, GBA carries only those forward. It does not remember which upstream path produced them. That is where the speed comes from: the work grows with the number of edges in the graph, not with the number of paths through it.
It is also where the pessimism comes from. The worst arrival at a node and the worst slew at the same node may come from different incoming paths. The delay of the next cell depends on its input slew, so GBA times the downstream cells as if the latest signal also had the slowest edge, even though no single transition in the real circuit has both. Figure 1 shows a small case.
Where path-based analysis earns its keep
Path-based analysis (PBA) takes one named path and re-times it using only what that path actually sees: its own slews at every stage, its own loads, its own arrival times. In Figure 1, PBA would time u6 with path P’s own sharp 0.08 ns slew instead of the 0.35 ns slew borrowed from path Q, and the delay through u6 and everything after it comes out smaller. It is much slower per path, far too slow to run on every path in a chip, but it is exact for the path it is run on.
The usual signoff approach uses both in sequence. Run GBA over the whole design, which is cheap and never optimistic. Then re-run PBA on just the handful of paths GBA reports as worst. If PBA confirms the violation, it is real. If PBA shows a smaller violation or none, the difference was GBA pessimism. On a well-optimised design this recovered margin can be a large share of the apparent violations, which is why engineers under schedule pressure lean on PBA for the paths they have deliberately chosen to re-check. They do not use it as a blanket replacement for GBA.
In OpenLane the STA step reports graph-based numbers. Full path-based recalculation is mainly a feature of the commercial signoff timers. That is fine for this course: the UART is small, and its margins are decided by the corners in Section 7.3 far more than by GBA pessimism.
Pessimism is not the same as a false path
One mistake I see often is assuming that any GBA violation that “looks pessimistic” will go away under PBA. PBA removes the pessimism of merged slews and arrivals. It does not know anything about the design’s function. Consider a mux whose select line is a configuration bit that is set at power-up and never changes. One of its inputs comes from a long path that is only ever selected in a mode you never use. GBA will time that path, and so will PBA, because the path exists structurally in the netlist. Neither engine knows the select line never switches.
For that you have to tell the tool, with a constraint such as set_case_analysis on the select line or set_false_path on the path. And even then you should run PBA or read the path carefully before deciding a violation is not real. Some GBA “pessimism” turns out to be a genuine violation once it is checked, and assuming otherwise is how real timing failures slip through signoff.
Practice Exercise
A design has a scan mux on every flop’s D input, selecting between functional data and a scan-shift input. In normal operation scan-enable is tied low and never switches. GBA reports a violation on a path that only exists when scan-enable is high, the scan-shift path. Should this block functional-mode signoff, and what is the right way to handle it instead of running PBA and hoping it clears?
Solution
It should not block functional-mode signoff, but PBA is not the fix. PBA re-times a path more exactly, but it has no more idea than GBA that scan-enable cannot be asserted in normal operation. Both engines analyse the scan path because it is structurally present in the timing graph.
The right handling is a mode-aware constraint. For functional-mode signoff, apply set_case_analysis 0 to scan-enable, which removes the scan-shift path from that analysis altogether. The scan-shift path still has to be checked, but in a separate test mode with its own constraints (usually a slower scan clock). That is the multi-mode setup Section 7.3 describes.
That completes the background for this module. In the next article we start the hands-on part and look at what RC extraction actually produces when it walks a routed design.