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

AboutContactPrivacyTerms
Skip to lesson

Course contents

  • How to Use This Course
  • PD Flow Overview — RTL to GDSII
  • Data & Libraries — What PD Receives
  • Data and Libraries49
  • Floorplanning Expanded65
  • Power Planning57
  • Placement65
  • Clock Tree Synthesis57
  • Routing65
  • Timing Closure81
    • SDC for Implementation
    • Setup/Hold Closure Playbook
    • MCMM Signoff Strategy
    • ECO Timing Fixes
      • ECO Timing Fixes — Mechanism
      • ECO Timing Fixes — Inputs & Outputs
      • ECO Timing Fixes — Reports & Metrics
      • ECO Timing Fixes — Debug Playbook
      • ECO Timing Fixes — Worked Example
      • ECO Timing Fixes — Pitfalls & Red Flags
      • ECO Timing Fixes — Interview Drills
      • ECO Timing Fixes — Review Checklist
    • Path Group Prioritization
    • Generated Clocks and Clock Groups
    • IO Timing and Block Boundaries
    • Useful Skew in Timing Closure
    • Post-Route Extraction and SPEF
    • Timing Signoff Dashboard
    • Timing Closure Tricky Q&A
  • Signal Integrity and Variation41
  • Power Signoff57
  • Physical Verification65
  • Physical Design Integration49
  • Signoff and Tapeout49
  • PD Interview Prep5
  • PD Closure Cheat Sheet
Loading lesson

‹ECO Timing Fixes
  1. Topics
  2. Physical Design
  3. Timing Closure
  4. ECO Timing Fixes
  5. ECO Timing Fixes — Pitfalls & Red Flags

Physical Design · All levels

ECO Timing Fixes — Pitfalls & Red Flags

Pitfalls & Red Flags for ECO Timing Fixes (Timing Closure).

On this page

    Common mistakes

    • Optimizing without naming corner/mode/stage

    • Local fix that regresses neighboring metrics

    • Skipping documented checklist before signoff

    Red flags in reviews

    • Cannot explain worst report line

    • No regression list after proposed fix

    • Waiver requested without cluster analysis

    Failure modes seen in real tapeouts

    • A fix is accepted because the local metric improved, while the release tag silently changes.

    • A waiver is treated as permission to ignore root cause instead of a tracked risk with owner and expiry.

    • A tool knob hides the symptom but creates a non-repeatable methodology dependency.

    • A local improvement in ECO Timing Fixes regresses timing, routing, power, PV, DFT, package, or tapeout signoff.

    How a senior engineer recovers

    1. Freeze the evidence: tag, report, layout snapshot, and command-line switches.

    2. Name the real owner and approval path.

    3. Convert the lesson into a checklist item, regression, or methodology guardrail.

    Deep dive: how this shows up in real closure

    Timing closure is a signoff matrix problem, not a single worst-path problem.

    Reports and artifacts to inspect

    • report_timing -max and -min with corner, mode, SI, and OCV enabled

    • path group WNS/TNS: which clock domain is actually blocking signoff

    • net delay percentage vs cell delay percentage

    • exception audit: false paths, multicycle paths, generated clocks

    Mini case study

    A -90 ps setup path has 75% net delay and crosses a macro channel. Sizing the launch flop is weak. The stronger response is to layer-promote or shorten the route, then re-run hold at the fast corner.

    Debug branches

    • If net delay dominates, look for physical fixes before cell sizing.

    • If cell delay dominates, consider VT swap, sizing, or RTL micro-architecture.

    • If only one mode fails, inspect mode-specific SDC overlays and case analysis.

    Senior review question

    Ask yourself: what single report line would prove this page's concept is either passing or failing?

    What changes at 10+ years

    • You are expected to predict what your fix can break before running it.

    • You should recognize when the issue is methodology, not one block's implementation.

    • You should communicate risk in tapeout language: owner, evidence, impact, mitigation, and decision date.

    Principal-level review bar

    Deep subpage pages in this course should be read like real closure review material. For a 10+ year PD engineer, the bar is not remembering terminology; it is making a release-quality decision under ambiguity.

    What excellent looks like

    • Names the failing metric, corner/mode, database tag, and analysis switches before proposing a fix.

    • Separates data, constraint, physical, tool, and methodology root causes instead of treating all failures as optimization problems.

    • Chooses experiments by information gain and reversibility, not by habit.

    • States regression blast radius across timing, route, power, PV, DFT, package, and tapeout manifest.

    • Turns recurring failures into methodology guardrails, dashboards, or checklist items.

    Closure note template

    Diagram
    STAFF / PRINCIPAL CLOSURE NOTE
    
    Context:
      stage: <pre-CTS | post-CTS | post-route | post-fill | signoff>
      tag: <database / netlist / SDC / library stack>
      failing metric: <exact report line>
      affected scope: <block / hierarchy / path group / power domain / region>
    
    Hypotheses:
      H1: <most likely physical or constraint mechanism>
      H2: <competing explanation>
      H3: <methodology or input-data issue>
    
    Decision:
      next experiment: <cheap check that can falsify H1>
      fix candidate: <minimal reversible change>
      rollback trigger: <metric that says the fix is wrong>
      regression set: <timing / route / power / PV / DFT / package>
      escalation owner: <team or reviewer>

    Tradeoffs a senior engineer must discuss

    Technical tradeoff

    Timing closure is a signoff matrix problem, not a single worst-path problem. Explain not only the preferred fix, but what margin or schedule you are spending to get it.

    Cross-team tradeoff

    • What must RTL, synthesis, CAD, STA, DFT, package, IP, or foundry agree to before this decision is final?

    • Which artifact becomes the source of truth after the decision: report, waiver, manifest, ECO script, or methodology deck?

    • What is the cost of being wrong: one rerun, ECO churn, mask risk, performance loss, or silicon escape?

    Leadership communication

    Diagram
    "The current blocker is <metric> in <corner/mode/stage>. The leading cause is <mechanism>. I recommend <fix> because it is bounded and reversible. The regression surface is <domains>. If it fails, we escalate to <owner> with <evidence>."

    Key takeaways

    • Always connect the concept back to a measurable signoff artifact.

    • A fix is not complete until you can name the regression checks.

    Common pitfalls

    • Optimizing by habit instead of reading the current report.

    • Forgetting that a local fix can regress timing, routing, power, or PV elsewhere.

    Previous

    380 / 709

    Next: Electromigration Analysis — Pitfalls & Red Flags

    Up next

    Up nextElectromigration Analysis — Pitfalls & Red Flags

    Sign in to save progress

    Practice this lessonReport an error

    See also

    • ECO Timing Fixes — Mechanism
    • ECO Timing Fixes — Inputs & Outputs
    • ECO Timing Fixes — Reports & Metrics