What's the difference between a timing ECO and a functional ECO?
From PDVerse PnR Interview Handbook · pdVerse Mentor Guide
Short Answer
A timing ECO changes how fast the logic is without changing what it computes: sizing, Vt swaps, buffers and hold delay cells. A functional ECO changes what the logic computes, usually to match a corrected RTL. That difference decides where the change comes from, what equivalence is checked against and how much risk the change carries.
Technical Explanation
- Timing ECOs usually come from
fix_eco_timing(PT) andfix_eco_drc(PT), or from manual what-if edits withsize_cell(PT) andinsert_buffer(PT). The logic stays the same, so equivalence against the pre-ECO netlist must still pass. - Functional ECOs come from an RTL change. A new gate-level netlist or a small patch is produced, and in ICC2
eco_netlist -by_verilog_file(ICC2) compares it with the working design and writes the edits as a change script. - By default
eco_netlist(ICC2) ignores timing ECO differences such as resized cells and added or removed repeaters, so a functional ECO does not undo the timing work already in the layout.-extract_timing_eco_changesincludes them when you want them. - Equivalence works differently. For a timing ECO the reference is the netlist before the ECO, and any failing compare point is a bug in the ECO. For a functional ECO the reference is the new RTL; the old netlist is expected to fail against it, and passing against the new RTL is the proof.
- Physical impact differs as well. Timing ECOs mostly swap cells in place or add a few buffers near existing logic. Functional ECOs add or rewire gates, sometimes in several places, and after tapeout they must map onto spare cells in the freeze silicon flow.
- Both end in the same loop of placement, routing, extraction, PrimeTime re-timing and equivalence. A functional ECO often needs a timing ECO afterwards, because the new logic lengthens a path.
- Risk and review differ. A timing ECO can usually be generated, checked and implemented by the physical design engineer alone. A functional ECO needs the RTL owner to confirm the intended change, and often verification sign-off on the new behaviour, before the layout team touches it.
- Same-name trap:
size_cell(PT) andsize_cell(ICC2) both exist. In freeze-silicon mode the ICC2 command also checks for a matching spare cell nearby, within five times the unit site height. A logic-only PT sizing does not look at spare cells; PT only does that in its physically aware freeze_silicon mode, which needs a PrimeTime-ADV license.
Common Mistake
The Trap: Using the pre-ECO netlist as the Formality reference for a functional ECO, because that is what the last timing ECO used. Every changed cone fails, the engineer reads the failures as expected and waives them, and a missing inverter in the patch is never caught until silicon. The right reference would have shown the failing cone at once and pointed straight at the inverter. Choosing the reference is the first decision of every equivalence run, and it follows directly from the ECO type.
Follow-up Question & Model Response
"Can one change list contain both kinds of change?"
Candidate Model Response: It can, and late in a project it often does: a small logic fix plus the sizing that makes it meet timing. I would still keep them apart in review, because they need different equivalence references. A clean order is to implement the functional patch first and verify it against the new RTL, then run the timing ECO on top and verify it against the post-functional netlist. Mixing them in one step makes a failing compare point hard to assign to either change.
Practical Example
Tapeout Scenario: Two changes arrive in the same week (illustrative). The timing ECO from PrimeTime resizes 18 cells and adds 26 hold buffers, and Formality against the pre-ECO netlist reports every compare point equivalent. The functional ECO fixes an enable condition in the RTL: synthesis of the changed module gives 7 new gates, eco_netlist -by_verilog_file (ICC2) writes a script that adds those 7 cells and rewires 11 nets, and Formality against the new RTL passes. Re-timing then shows the new enable path at −14 ps, so a small timing ECO of 2 resized cells follows and is verified against the post-functional netlist. Keeping the three steps separate meant each Formality run had one clear reference and a failure would have pointed at one change.
PnR Flow Mentor Guide
Master the Physical Design Implementation Flow
Read the complete 8-chapter PnR Flow Mentor Guide free on the web — library setup through placement, clock tree synthesis, routing, chip finishing, hierarchical implementation, and ECO, all the way to stream-out.
Continue practising