MCMM Signoff Strategy

On-call / interview prompt

You own MCMM Signoff Strategy on a block nearing implementation freeze — what do you verify first?

CLOSURE CHAIN

1. METRIC     — name the failing report line (WNS, DRV, DRC count, IR %)
2. HYPOTHESIS — 2–3 likely causes ordered by probability
3. EXPERIMENT — one cheap check (corner, clock, report, map)
4. FIX        — minimal physical or constraint change
5. REGRESSION — what you re-run and what must not regress

Topic overview

Design and operate a corner/mode matrix that reflects silicon risk, not just tool runtime convenience.

Mechanism to narrate

• Section: Timing Closure

• Primary artifact: MCMM summary matrix (setup, hold, DRC timing checks)

• Downstream dependency: next PD stage

Staff/principal ownership model

Own MCMM Signoff Strategy as a release decision, not a page of notes. A senior PD engineer names the metric, the physical mechanism, the cross-team dependency, and the smallest evidence-producing experiment.

STAFF REVIEW MEMO — Timing Closure / MCMM Signoff Strategy

1. Current state
   - Failing / watched metric: MCMM summary matrix (setup, hold, DRC timing checks)
   - Database tag, corner/mode, tool version: <fill before review>
   - Physical scope: block, hierarchy, macro region, clock domain, or net class

2. Root-cause hypothesis
   - Most likely mechanism: <name physical or constraint mechanism>
   - Competing hypothesis: <name the second plausible cause>
   - Evidence still missing: <report/map/schematic/check>

3. Proposed action
   - Minimal reversible fix: <physical, constraint, ECO, or methodology change>
   - Expected improvement: <metric delta>
   - Regression risk: late-stage schedule slip, silicon risk, or cross-stage regression

4. Regression and signoff
   - Re-run: MCMM summary matrix (setup, hold, DRC timing checks)
   - Must not regress: timing, routing, power, PV, DFT, package, or tapeout signoff
   - Decision owner: PD owner

Sub-lessons in this topic

1. mechanism — Mechanism

2. inputs-outputs — Inputs & Outputs

3. reports — Reports & Metrics

4. debug-playbook — Debug Playbook

5. worked-example — Worked Example

6. pitfalls — Pitfalls & Red Flags

7. interview — Interview Drills

8. checklist — Review Checklist

Related topics

• Mode/reset behavior assumptions

• Multi-clock CTS interaction

Key takeaways

• Master MCMM Signoff Strategy through reports, not GUI habit.

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

Lesson 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

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

"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.