Module 7: Timing Closure & Static Timing Analysis · 7.4 Fixing Timing Violations

The ECO Concept: Surgical Fixes, Not Full Reruns

The previous article ended with a confirmed violation: the parity path is 2.00 ns short at the slow corner. If we were still in Module 2, the natural reaction would be to change the RTL and run everything again: synthesis, floorplan, placement, CTS, routing, extraction and STA. At this stage of the flow that reaction is usually wrong, and in this article I want to explain why, and what we do instead.

Why rerunning everything is the wrong reflex

By now the UART has been through synthesis, floorplanning, placement, clock tree synthesis and routing, each stage building on decisions the previous one committed to. A full rerun does not just fix the parity path. It produces a new placement, a new clock tree and new routes for the whole design, all because of a change meant for one path. Every path that was passing comfortably is back in play. The tools are under no obligation to find the same solution twice, and a slightly different placement can fix your one violation while creating a new one somewhere you were not looking.

An engineering change order (ECO) is the alternative. It is a small, targeted change made directly to the finished design database: insert one buffer, resize one gate, occasionally reroute one net. It fixes a specific, identified problem and leaves everything else exactly as it was, including every path that was already passing.

Blast radius

The idea that makes ECOs work is blast radius: how much of the design a change could possibly affect. A full rerun has the largest blast radius there is, the whole chip. A well-aimed ECO touches a handful of nets and cells around the violation, and ideally none of the paths that were already fine. Figure 1 shows the difference.

Blast radius of a full rerun compared with an ECO
Figure 1: A full rerun can change every cell, route and clock branch, while an ECO changes a few cells on one net

The later you are in the flow, the more a large blast radius costs. A change found right after synthesis is cheap to absorb in a full rerun because almost nothing downstream has been committed. A change found after routing and extraction, where we are now, is expensive, because placement, CTS and routing are verified work that a rerun would throw away and redo, with no guarantee of getting the good parts back.

ECOs are not a workaround for a flow that should have got it right first time. Even with excellent commercial tools, some paths only show a problem once real parasitics and every signoff corner are checked. That is exactly what happened to the parity path. The ECO is the normal, accepted response to that, not a sign that something upstream was broken.

What OpenROAD gives you

In this course the ECO tool is OpenROAD’s resizer. It works directly on the placed and routed database and can make the local changes an ECO needs: insert a buffer on a particular net, or swap a particular gate for a stronger or weaker version of the same function, without touching anything else. The next article covers those two techniques in detail.

One mistake worth avoiding is treating every violation as a candidate for an ECO. A single path missing by a bounded amount in an otherwise clean design is the textbook case. Dozens of paths failing across the whole design usually means something more basic is wrong, such as a clock constraint the design cannot meet or a floorplan problem, and no amount of local buffering fixes that without ending up redoing most of the design anyway. Recognising which situation you are in comes before choosing either tool.

Practice Exercise

The multi-corner run in the previous article found one failing path, at one corner, missing by 2.00 ns. Another run on the same design finds 340 failing paths spread across all three corners, with a worst slack of only −0.30 ns but a total negative slack of tens of nanoseconds. For each case, is an ECO the right tool?

Solution

The first case, our actual situation, is a good ECO candidate: one identified path, a bounded violation, and everything else confirmed clean. Buffering or resizing on that one path has a small, well-understood blast radius.

The second case is not, even though each violation is smaller than ours. Hundreds of failing paths across the design and a large total negative slack are the signature of a systemic problem, most likely a clock target the design’s logic depth and size cannot meet, or a pattern repeated all over the design rather than one bottleneck. Patching 340 paths one at a time is no longer surgical. The combined blast radius approaches that of a rerun, without the benefit of a fresh, globally optimised placement and route. The honest fix is to revisit whether the constraint was realistic, and then rerun with a relaxed clock or an architectural change, not several hundred small patches.

In the next article we look at the two techniques an ECO uses for a violation like ours, buffer insertion and gate sizing, and what each one costs.

← Running Multi-Corner Analysis on the UART Buffer Insertion and Gate Sizing as ECO Techniques →