Signoff vs Implementation Views: Theory Deep Dive

Foundational theory

Signoff vs Implementation Views is central to MMMC Signoff. Implementation and signoff use different parasitic corners and analysis views; comparing them without mapping causes false panic or false confidence. Senior STA engineers always tie slack movement to corner, mode, constraint set, and parasitic view — not just a single report line.

Core concepts explained

• Implementation and signoff use different parasitic corners and analysis views; comparing them without mapping causes false panic or false confidence.

• Primary metric: view delta WNS, parasitic corner mismatch, SPEF vs signoff RC gap

• Primary artifact: view comparison report, SPEF tag manifest, delta slack log

• Owners: STA lead, PD owner, extraction owner

• Setup: max delay path; Hold: min delay path

• WNS/TNS summarize tail risk across endpoints

Why this matters at signoff

At signoff, Signoff vs Implementation Views failures block tapeout or force risky ECO. Signoff is a matrix problem: corners × modes × views × libs. Wrong analysis setup wastes weeks of PD effort.

Mental model

SAME NETLIST — TWO VIEWS

impl_view SPEF (typical)     WNS = +50ps
signoff_view SPEF (cworst)   WNS = -30ps

Delta is expected; panic only if delta exceeds historical bound.

Worked intuition

1. Name corner, mode, and view for the failing run.

2. Open view delta WNS, parasitic corner mismatch, SPEF vs signoff RC gap and identify worst path group.

3. Read critical path: cell vs net, launch/capture clocks.

4. Check constraints on that path (exceptions, generated clocks).

5. Collect view comparison report, SPEF tag manifest, delta slack log and tag database versions.

6. Classify: constraint bug, view mismatch, or real path.

7. Propose minimal ECO and list MMMC+SI regression.

Common misconceptions

• One typical corner is enough for signoff.

• False paths can be applied broadly to green-wash violations.

• Implementation WNS equals signoff WNS without view mapping.

• Setup fix automatically preserves hold.

Visual reinforcement

View comparison

SAME NETLIST — TWO VIEWS

impl_view SPEF (typical)     WNS = +50ps
signoff_view SPEF (cworst)   WNS = -30ps

Delta is expected; panic only if delta exceeds historical bound.

Layer responsibilities

STA OWNERSHIP LAYERS — Signoff vs Implementation Views

layer              owns                         failure mode
----------------   --------------------------   ---------------------
constraints        clocks, IO, exceptions       false violations
implementation     cells, nets, placement       real path delay
extraction         SPEF/RC corners              view mismatch
signoff policy     derate, MMMC matrix          margin disputes
closure           ECO order, regression        fix breaks other corner

STA deep dive

Signoff WNS is the minimum across the full scenario matrix.

Concept diagram

MMMC

corners (ss/tt/ff) x modes (func/test) x views (signoff RC)
= scenario set -> min(WNS) is signoff

Metric graph

WNS HEATMAP BY CORNER

        ss    tt    ff
setup  -80   +10   +5
hold   -15   -2    -8

Reports and artifacts

• per-corner WNS

• mode summary

• lib map audit

• view delta

Mini case study

Passed TT typical but failed SS hold — signoff matrix was incomplete; added low-voltage mode.

Debug branches

• Isolate failing scenario first

• Never compare unlike SPEF tags

Senior review question

Ask: what corner/mode/view proves this topic is closed or failing?

Key takeaways

• State corner, mode, view, and database tag with every slack claim.

• Run setup and hold plus MMMC regression after every ECO.

Common pitfalls

• Comparing STA runs with different SPEF or SDC tags.

• Broad false_path to green-wash violations.

• Setup-only ECO without hold check.

Theory reinforcement

Signoff is a matrix problem: corners × modes × views × libs.