Skip to content
DenseChip
Learn
PracticeCode labInterview

DenseChip

Navigate

Menu

LearnPracticeCode labInterview

Tools

All toolsSV editorCode repoResume
DenseChip

Practice, courses, and chip-design tools in one focused workspace.

LearnPracticeCode labInterviewToolsLearning paths

© 2026 DenseChip

AboutRoadmapCareersInternshipsFAQContactPrivacyTerms
Skip to lesson

Course contents

  • RTL Foundations36
  • Combinational Design25
  • Sequential Design27
  • FSM & Control27
  • Timing & Clocking39
  • Reset & CDC34
  • Memory & Buses57
  • Advanced RTL28
  • Senior & Interview76
    • Low-Power RTL Hub
    • DFT and Scan Hub
    • Physical Awareness Hub
    • Waveform Debug Hub
    • STA and ECO Hub
    • RTL-to-Implementation Closure
      • Ownership and Handoff
      • Reproducible QoR
      • Equivalence-Friendly RTL
      • ECO Regression and Release
      • Proving an ECO: Equivalence and Gate-Level Simulation
    • DFT-Ready RTL
    • Capstone: Resilient Streaming Peripheral
    • Principal Design Review
    • Senior RTL Interview Questions & Model Answers
  • Glossary and Notation
Loading lesson

←RTL-to-Implementation Closure
  1. Topics
  2. RTL Design
  3. Senior & Interview
  4. RTL-to-Implementation Closure
  5. ECO Regression and Release

Part 9 of 9, lesson 25 of 76Part 9 of 9/Senior/Lesson 25 of 76Senior

ECO Regression and Release

Apply the smallest justified change, rerun every affected signoff view, and release with an auditable decision record.

A change that fixes one slow path can create a fast path elsewhere and cause a hold failure. A release needs proof of what moved, not just proof that the original violation is gone.

After this lesson you can: follow the ECO sequence from baseline to release, choose the regression a change needs, and write the release note with a rollback point.

The ECO loop: a change that misses any budget goes back to the change step, not forward to release.
  1. Freeze and reproduce the failing baseline.

  2. Classify root cause: RTL, constraint, library, physical, CDC, or environment.

  3. Choose the smallest change that fixes the cause, not only the symptom.

  4. Run functional, equivalence, lint, CDC/RDC, synthesis, STA, power, DFT, and physical checks affected by the change.

  5. Compare all modes/corners and neighboring paths, not only the original violation.

  6. Record change, evidence, residual risks, waivers, approvals, and rollback point.

The checksum change is released only after latency-aware regression, sequential equivalence, all-corner setup and hold, power, congestion, and downstream interface checks agree. The release note records the old and new pipeline latency and provides a rollback revision.

Illustrative release decision

Disposition

Dossier decision

Keep

Not justified: setup gain alone cannot waive failed hold/power budgets

Revise C1 (selected)

Physical/STA owners investigate new short paths and hold repair; RTL/power owners investigate added clock load; architecture retains the approved extra cycle

Reject / rollback to C0

If repairs cannot meet all budgets across paired seeds and modes, reject C1 and reopen baseline setup closure; C0 itself is not signoff clean

Release status

Blocked in this hypothetical dossier; formal, regression and physical evidence remain unexecuted obligations

Any C2 revision needs a fresh controlled comparison against C0/C1, latency-aware regression, sequential equivalence and all affected signoff views. Attach report revisions, waiver owners/expiry, downstream latency approval and rollback manifest before release; do not turn this illustrative decision into a claimed passing run.

Change

Minimum regression

Combinational RTL

Sim/formal, lint, LEC, synth, all timing views, power

Pipeline stage

Architecture latency, scoreboard, LEC strategy, CDC, STA

Reset/clock

Reset tests, CDC/RDC, STA clocks, DFT, low power

Constraint

Constraint audit, unconstrained paths, all modes/corners

Gate ECO

LEC, STA setup/hold, physical DRC, power and affected tests

For an engineering change order (ECO), explain both schedule pressure and proof radius: what changed, which views can move, what was rerun, and what evidence supports release.

Check yourself Why rerun hold after a setup ECO?

Sizing, buffering, or restructuring that improves a slow path can create a new fast path or alter clock/data balance, causing hold failures.

  • Freeze the baseline, find the cause, make the smallest change, and rerun every check the change can affect.

  • Compare all modes, corners and neighbouring paths, not only the original violation.

  • Record the change, evidence, residual risks, waivers, approvals and rollback point.

How this was checked

The release decision is illustrative and unexecuted. Any revision needs a fresh controlled comparison before release; it is not a claimed passing run.

  • Interview: run a mock interview on this topic

Related topics

  • Incremental and ECO synthesis

  • STA ECO closure

  • Proving an ECO: equivalence and gate-level simulation

Previous

298 / 350

Next: Proving an ECO: Equivalence and Gate-Level Simulation

Up next

Up nextProving an ECO: Equivalence and Gate-Level Simulation

Sign in to save progress

Practice this lessonPrevious lessonReport an error

See also

  • Ownership and Handoff
  • Reproducible QoR