MPW Tapeout Tutorial: Prepare GDSII, DRC and LVS Handoff

Short answer: an MPW handoff needs the final layout plus evidence identifying what it contains and which checks were run. Prepare the top-cell name, process and option, units, layer-map reference, final netlist, applicable DRC/LVS results, approved exceptions and file checksums. The selected provider determines the complete acceptance package.

This tutorial turns “the GDS is ready” into a package another engineer can inspect. File names below are invented examples, not a downloadable foundry submission.

Jump to: DRC versus LVS, the handoff manifest, or spot the stale report.

What is the difference between DRC and LVS?

• GDSII or OASIS: layout data in a format accepted by the route. Opening it successfully does not prove signoff.
• DRC: checks encoded geometric/process rules using a particular deck and configuration. A clean result is meaningful only within that check’s coverage.
• LVS: compares the extracted layout circuit with the intended reference netlist under the configured comparison rules.
• Other required checks: may include electrical, antenna, density, timing or reliability-related checks according to the design and program. DRC/LVS do not replace circuit validation.

The SKY130 verification documentation distinguishes physical verification tasks. As a concrete program example, IHP’s open-silicon development checklist identifies release artifacts, consistent top-cell identity and DRC/LVS acceptance requirements. Apply your own program’s checklist; do not copy IHP-specific rules into an unrelated process.

Step 1: freeze the exact release

Choose a release identifier and identify the final layout and reference netlist. Record the process option, PDK, layer map, top cell and units. Stop using ambiguous names such as “final-new-fixed.gds” without a revision record. If the layout changes after verification, determine which checks must run again; a report for yesterday’s file is not proof for today’s file.

Step 2: retain the reports and their execution context

For every required check, preserve the input file identity, tool version, rule-deck version, relevant options, execution time, outcome and unresolved findings. Distinguish “not run,” “failed,” “passed under the stated setup,” and “accepted with an explicitly approved exception.” A missing result is not a pass.

Check that the report refers to the intended top cell and final netlist. A clean result obtained by excluding the wrong block or skipping a stage can be misleading. The PDK’s published limitations are part of interpreting what its tools have actually checked.

Step 3: make a file-level tapeout manifest

A teaching example might contain:

• release.gds — final layout; top cell DEMO_TOP.
• release.cdl — the agreed reference netlist format.
• drc-summary.txt and lvs-summary.txt — outcomes with links to retained detailed reports.
• handoff-notes.txt — revisions, owners, approved exceptions and receiver instructions.

Generate a SHA-256 value from each actual file. On macOS, a local command for one file is:

shasum -a 256 release.gds

On a Linux environment with GNU coreutils, use sha256sum release.gds. Copy the resulting digest exactly into the manifest. A checksum identifies file bytes; it does not certify the design or encrypt the file.

Use this compact record for each deliverable:

Step 4: inspect and rehearse the handoff

Use the Local GDSII Inspector for the file properties it supports, and the GDS/OASIS Handoff Manifest Generator to organize filenames, roles and checksums. Neither tool runs foundry signoff.

For a non-confidential practice exercise, enter a synthetic project label, top-cell note and placeholder filenames. A missing digest should remain visibly missing until it is calculated from the real file. Never present a made-up 64-character value as verification.

Have the receiver check the manifest, recompute file hashes after transfer, identify the top cell and confirm that the reports correspond to the same release. Use the authorized exchange path for real layouts, netlists and PDK material.

Try it: spot the stale verification report

In this invented handoff, layout R2 and netlist R2 are in the delivery folder. The DRC report identifies layout R2. The passing LVS report identifies layout R1 and netlist R1. The receiver recomputes the delivered-file hashes and they match the sender’s manifest. Is the R2 handoff verified?

A useful completion test: give a colleague only the manifest and the authorized evidence locations. They should be able to identify the release, reproduce the file-identity check and locate the report for each required result without guessing which “final” folder you meant.

A final three-question review

1. Can another engineer identify every delivered file and its intended role?
2. Can each required result be traced to these exact inputs and the accepted tool/deck setup?
3. Are open exceptions and the person authorized to accept them explicit?

If any answer is no, record the gap before requesting final acceptance. An early commercial review can proceed with non-confidential readiness information, but that is separate from releasing design data for fabrication.

Continue the MPW tutorial

Review the PDK worksheet, then plan packaging and test. The first-silicon checklist connects these tasks to fabrication and sample delivery.

Technical review: 17 September 2026. This is a release-preparation tutorial; only the authorized program can accept a particular tapeout package.