BeginnerQuestion 95 of 95Source: ICC2 User Guide: ECO Implementation

What is the difference between a timing ECO and a functional ECO?

From PDVerse STA Mentor Guide · pdVerse Mentor Guide

By Tabish Iqbal · 9+ Years VLSI Physical Design Experience

Short Answer

A timing ECO only changes non-functional properties of the netlist — cell sizes, buffer insertion, wire routing — to fix a timing or design-rule violation without changing what the chip logically does. A functional ECO changes the logic itself: a gate is added, removed, or rewired to fix a real behavioral bug. The two are handled very differently late in a project, because a functional change can ripple through verification in ways a timing-only change cannot.

A changeset diagram split into two labeled groups: 'timing-only edits' (cell resize, buffer insert) needing only a timing re-run, and 'functional edits' (gate rewire) needing a full regression suite, joined by a shared write_changes handoff. — Technical Reference DiagramWhat is the difference between a timing ECO and a functional ECO?

Technical Explanation

Both are called ECOs, but only one of them risks changing what the design actually computes.

A timing ECO — the kind fix_eco_timing (PT) and fix_eco_drc (PT) perform — resizes cells or inserts buffers, none of which change any logical output for any input pattern.
A functional ECO changes the logic equation itself: adding a missing enable condition, correcting a wrong gate, rewiring a connection to fix a real bug found late.
Because a timing ECO never changes logic, the existing functional verification suite generally still applies without rerunning it end to end.
A functional ECO needs its own targeted verification, since the whole point of the change is that the design's behavior is different afterward.
Close to tapeout or after silicon comes back, teams strongly prefer timing ECOs precisely because they avoid reopening functional verification.
Some flows track both kinds in one changeset anyway, since a single mask-layer respin often has to bundle a timing fix with a small functional fix.

Common Mistake

The Trap: assuming any late-stage netlist edit is automatically "safe" because it is called an ECO.

A functional ECO carries real behavioral risk that a timing ECO does not, even though both use the same write_changes handoff mechanism.
Skipping functional re-verification on a change that actually touched logic — rather than just cell sizes — can let a real bug reach silicon.

Follow-up Question & Model Response

If an ECO both resizes a buffer for hold timing and also rewires one gate to fix a logic bug, does that count as a timing ECO or a functional ECO?

Candidate Model Response: It is treated as a functional ECO, because the presence of any logic-changing edit means the whole changeset needs functional re-verification, not just the timing-only part. Bundling both kinds of change together does not let the timing-safe portion skip scrutiny; the safest practice is to review and verify the changeset at the level of its riskiest edit. Some teams deliberately keep timing ECOs and functional ECOs in separate changesets specifically to avoid this ambiguity, applying and verifying each with a process matched to its actual risk. That separation makes it clear, from the changeset alone, which verification steps still apply.

Practical Example

Two weeks before a respin, a team bundles a 3-cell hold-fixing ECO with a one-gate logic correction for a missed reset condition into a single change list. Because the changeset contains a logic edit, the release process runs the full functional regression suite on it, not just a timing re-verification, even though 90% of the changes were timing-only.

Complete STA Handbook