oFunctional ECO: An Engineering Change Order implemented to fix a logical bug in the design’s functionality or to add/modify a feature. The change originates from an RTL modification.
- RTL code is modified to fix the bug or add the feature.
- The changed RTL is synthesized (often just the affected module).
- Synopsys Formality ECO, Cadence Conformal ECO compares the original synthesized netlist (the one in PnR) with the newly synthesized netlist from the changed RTL.
- The ECO tool identifies the logical differences and generates a set of gate-level changes (ECO patch – add/delete/modify gates and connections) needed to transform the PnR netlist to match the new functionality. This patch is often a sequence of tool commands (add_cell, remove_cell, connect_net, disconnect_net, etc.).
Implementation in PnR: The ECO patch (script) is applied to the PnR database, followed by incremental placement (legalization) and routing of the modified logic.
Verification: LEC is run between the patched PnR netlist and the new golden synthesized netlist. Full regression testing (simulation) is also usually required.
Timing ECO: An ECO implemented to fix timing violations (setup, hold, DRVs) in a design that is already functionally correct (i.e., LVS and LEC clean against the intended functionality).
- STA (e.g., PrimeTime) is run on the post-route design, identifying timing violations. And generates ECO suggestions/scripts (e.g., size_cell, insert_buffer, swap_vt_cell).
- Alternatively, engineers manually analyze failing paths and devise fixes.
- Implementation in PnR: Similar to functional ECOs, the timing ECO script is applied to the PnR database, followed by incremental placement and routing.
- Verification: STA is re-run to confirm the timing violation is fixed and no new violations are introduced. LEC might be run if there’s a concern that the timing fix inadvertently changed logic
Functional ECO: https://www.synopsys.com/glossary/what-is-functional-eco.html