ASIC Signoff Checklist and Handoff

Signoff Is an Evidence-Based Release Decision

ASIC signoff is not a single tool run or a final green dashboard. It is a controlled release decision supported by evidence from several verification domains. The design team must show that the released implementation, constraints, libraries, parasitics, rule decks, and operating assumptions belong together. A checklist provides the structure for that proof.

The most useful checklist separates three ideas: the check that must run, the acceptance criterion for that check, and the artifact proving the result. For example, a timing task is incomplete if it merely says that static timing analysis ran. It should identify the analysis scope, required scenarios, report location, unresolved exceptions, and reviewer. This distinction prevents activity from being mistaken for completion.

Signoff also requires an explicit baseline. Record the design revision, netlist identity, physical database identity, constraint version, library set, extraction corner set, and verification deck versions. Without that baseline, reports can be individually valid but collectively describe different designs. Release confidence comes from coherent evidence, not from the volume of generated logs.

Freeze Inputs and Prove Configuration Consistency

Begin the final signoff cycle by freezing or tightly controlling authoritative inputs. Late changes to clocks, generated-clock definitions, operating modes, power intent, macro abstracts, or library files can invalidate dependent results. A freeze does not prohibit change; it requires each accepted change to trigger documented impact analysis and the necessary reruns.

Create a manifest that names every critical input and includes a digest where practical. The manifest should cover the implementation database, gate-level netlist, timing constraints, parasitic data, timing and power libraries, technology files, physical verification decks, antenna rules, and any approved supplemental rules. Keep paths understandable, but do not rely on paths alone because mutable files can retain the same name.

Consistency checks should verify that extracted parasitics correspond to the released layout and that timing uses the intended parasitic and library corners. Confirm that hierarchical blocks and top-level views use compatible interfaces. Check that black boxes, abstract views, and excluded regions are intentional. Any mismatch should block release until corrected or explicitly dispositioned, because a result based on stale configuration is not reliable evidence.

Close Timing Across Required Scenarios

Timing signoff should cover the project-defined set of modes and process, voltage, temperature, and extraction conditions. Evaluate setup and hold behavior, clock relationships, uncertainty, propagated clocks, input and output assumptions, and path exceptions. The checklist should state which scenarios are required rather than letting each engineer infer scope from a convenient default run.

Review constraint quality before interpreting slack. Unconstrained endpoints, missing clocks, unintended ideal networks, disabled arcs, and broad false-path or multicycle exceptions can hide real paths. Exceptions need a technical reason and traceability to the relevant interface or architecture intent. Reports should make scenario coverage and constraint diagnostics visible alongside violation summaries.

Timing closure is more than confirming that a headline worst slack is acceptable. Inspect path groups, clock-domain crossings covered by timing constraints, recovery and removal where applicable, minimum pulse width checks, and transition or capacitance limits required by the methodology. Ensure that ECO changes are present in both logical and physical release views. For deeper context on report review, see Cadence Tempus Timing Signoff.

Complete Physical and Electrical Verification

Physical verification establishes that the released geometry obeys manufacturing rules and corresponds to the intended connectivity. The checklist normally includes design-rule checking and layout-versus-schematic comparison, plus project-required antenna, density, manufacturability, and connectivity checks. Use the qualified rule deck and document all run options, exclusions, and waivers.

A clean summary is insufficient when the run contains filtered, waived, or unclassified results. Preserve detailed databases and reports so reviewers can trace each disposition. LVS review should account for expected device transformations, parameter tolerances, supply naming, and intentional hierarchy handling. Unexpected shorts, opens, devices, or property mismatches must not disappear behind summary filtering.

Electrical reliability checks add concerns that geometric and connectivity checks alone do not resolve. Depending on the design methodology, these may include current-density, voltage-aware spacing, latch-up-related rules, or checks for vulnerable interfaces. The exact required set comes from project and foundry policy. Related workflows are discussed in PVS Physical Verification and Calibre PERC Reliability Guide.

Validate Parasitics, Power, and Integrity Assumptions

Parasitic extraction links the physical implementation to timing, noise, power, and reliability analysis. Confirm that extraction used the released layout, intended technology setup, hierarchy policy, and required corner definitions. Review extraction warnings, missing cells, coupling treatment, and net coverage. A technically successful run can still be unsuitable for signoff if it silently substituted views or omitted geometry.

Power integrity review should use a coherent activity model and power-delivery representation. Document whether activity comes from simulation, propagation, or bounded assumptions, and identify domains or modes that require separate treatment. Examine static and dynamic voltage-drop results according to the project methodology, together with current-density or electromigration checks where required. Unknown or unavailable coverage must remain explicit rather than being reported as zero.

Cross-domain consistency matters here. Timing libraries, extracted interconnect, voltage assumptions, and power analysis conditions should describe compatible scenarios. If voltage-drop-aware timing or another coupled analysis is required, record its inputs and conclusions separately. The extraction stage and common review points are described further in Synopsys StarRC Extraction.

Treat Waivers as Controlled Engineering Records

A waiver is a risk decision, not a convenient way to make a report green. Every waiver should identify the exact violation or bounded class of violations, affected design scope, rationale, supporting evidence, owner, reviewer, and approval state. It should also record the design and rule context so that it cannot be silently reused after the underlying conditions change.

Avoid broad text filters that suppress future violations resembling an old one. Prefer stable identifiers, geometry or hierarchy scope, and explicit matching criteria. Revalidate waivers after design changes, deck updates, or methodology changes. A previously acceptable exception may no longer describe the same topology or risk.

The final review should distinguish accepted waivers from open issues. Open issues need an owner, severity, planned disposition, and release decision. If a required check is unavailable or its result cannot be tied to the release baseline, fail closed. Recording uncertainty honestly is safer than converting missing evidence into an implied pass.

Assemble a Reproducible Final Handoff

The handoff package should let another qualified engineer identify what was released and understand why it was accepted. Include the final logical and physical deliverables required by the recipient, the configuration manifest, critical reports, waiver records, known limitations, approvals, and checksums. Add a concise index explaining the package structure and naming conventions.

Before transfer, run mechanical checks on the package itself. Verify that required files exist, archives can be opened, checksums match, and no temporary credentials or unrelated data are present. Confirm that report references resolve to included artifacts and that generated deliverables carry the intended top-cell, units, layer mapping, and hierarchy. Protect the release location from accidental modification.

Conclude with a signoff review that records participants, scope, evidence, exceptions, and the release decision. Assign ownership for any post-release questions without creating an informal second version of the design. If a correction becomes necessary, issue a new baseline and repeat the affected checks. A disciplined handoff preserves traceability from design intent through verification evidence to the exact released artifact.