MST MPW HANDBOOK · 27 SEPTEMBER 2026

A reviewable MPW handoff, from layout identity to first-silicon preparation

This handbook is for a first-time project coordinator or engineer preparing an MPW review. It explains what to collect, which inconsistencies to investigate and who needs to confirm the result. It does not supply a foundry PDK or signoff flow. The downloadable geometric examples are MST-created teaching material without transistors or an electrical netlist.

Download the complete exercise · Save this handbook. Use Print to save a PDF.

1. “Which GDS did we actually check?”

A filename is a label, not proof of file identity. Keep a frozen release candidate with a recorded SHA-256, top cell, units, expected bounding box and revision. The same filename may be overwritten; two differently named files may contain identical bytes. Record both the human label and the checksum.

1. Unzip the teaching pack. Run python3 verify.py inside it. This uses only Python’s standard library and checks the packaged file hashes plus the two report-binding exercises.
2. Open Local GDSII Inspector and select layout-a.gds. Expect one top cell MST_DEMO_TOP, two cells in total, DBU 0.001 micrometers (1 nm), layers 1/0, 2/0 and 99/0, and a 100 by 60 micrometer bounding box.
3. Select layout-b.gds. Its bounding box changes to 120 by 60 micrometers. Its SHA-256 also changes. The top-cell name, cell count and layer pairs remain the same.
4. For an independent local check, create a Python virtual environment, install pip install -r requirements.txt, then run python inspect.py. The pinned KLayout API reads both files and compares the extracted values with expected-layouts.json.

The bounding rectangle here is a teaching outline on layer 99/0. A real file’s overall geometry bounding box is not automatically its approved die or scribe-line boundary. Interpret the foundry’s layer map and boundary definition. The inspector does not provide foundry DRC/LVS or validate layer meaning.

More than one top cell

A library can legitimately contain several unreferenced cells. Inspect the hierarchy and identify the intended submission top cell with the designer. Do not select a random cell to silence an error or assume the largest one is the approved design. A selected top cell must agree across the layout export, verification run and handoff note. The KLayout discussion illustrates why an explicit checking target matters; its scripting answer applies to that documented workflow, not every foundry flow.

2. “DRC passed yesterday, but the layout changed today”

Open Report Revision Check. Select layout-b.gds and the file reports-stale.json. Keep top cell MST_DEMO_TOP, revision B and PDK label TEACHING-NO-PDK-v1. Run the check. Expect two findings on the DRC record: its hash and revision refer to A. The LVS metadata refers to B.

Now open reports-consistent.json. The result is metadata consistent, because both fictional summaries refer to B. These files do not represent executed DRC/LVS. Change the top-cell field to OTHER to create two further mismatches. Restore the value, export the findings, and compare with the exercise’s expected-results.md.

1. Freeze the intended candidate and confirm the required PDK and deck revisions with the provider.
2. Run the approved checks in the authorized engineering environment.
3. Review error counts, check coverage, exclusions, waivers and engineer acceptance in the original reports.
4. Record the exact layout checksum, tool build, deck revision, top cell and run context beside the evidence.
5. After a layout change, ask the responsible engineer which checks must be repeated. Do not recycle yesterday’s report merely because the filename is unchanged.

DRC concerns the implemented geometric rules; LVS compares the extracted implementation with its reference schematic/netlist. Neither result alone proves functional correctness, startup behavior, reliability, packaging suitability or test readiness. The accepted flow and required signoff evidence are provider-specific.

3. “The package is missing a file, but nobody owns the list”

Use Handoff Manifest to inventory a non-confidential practice package. Enter a role and checksum for each required file. In a real controlled release, identify the layout, layer map, source netlist as required, original reports, approved waiver record, design README, package/bond documentation and test deliverables. The provider’s checklist determines the actual required items; this list is a starting point.

A useful inventory records filename, role, revision, SHA-256, source owner, reviewer and current disposition. “Pending” needs an owner and a date. A checksum does not authenticate its author, and a complete list does not imply the provider has accepted the package. Use the authorized transfer channel and obtain a receipt tied to the same revision.

The pack includes handoff-checklist.csv and report-metadata-template.json. Fill the original run facts into the template; never invent a pass status. The browser tools retain files in memory and send no layout content to MST. Confidential designs still belong in your organization’s approved environment and transfer process.

4. “Everyone has the PDK, but not the same environment”

Before layout or signoff review, agree on process option, PDK release, metal stack, required libraries, IP compatibility, extraction setup, rule-deck versions and supported tool releases. A matching marketing node name is insufficient. Record versions and the source of each authorization in an environment manifest.

1. Start from the provider-approved checklist and NDA/access terms.
2. Ask each contributor to report exact release identifiers, rather than “latest”.
3. Resolve differences with the project owner before merging layout or verification outputs.
4. Keep the final run environment associated with the frozen candidate. Re-check compatibility before upgrading tools or decks mid-project.

Use the PDK preparation tutorial. TEACHING-NO-PDK-v1 in this pack is an intentionally fictional label; no foundry technology or license is supplied.

5. “The shuttle date moved; which deadline does it affect?”

Separate reservation, NDA/PDK access, design review, dry-run GDS, final data freeze, signed order, wafer shipment and packaged-parts delivery. A public calendar is a planning reference. Confirm the run identifier, applicable process option, timezone, required documents and current acceptance cutoff with the coordinator.

Maintain an internal target before the external cutoff, with named owners for unresolved DRC/LVS work, packaging data, commercial paperwork and transfer confirmation. If a date moves, update dependent tasks and ask what remains binding. Avoid presenting a posted shuttle date as a reserved slot. See how to choose and confirm an MPW run.

6. “The chip is coming back; where is the test plan?”

Decide whether the expected return is a wafer, bare die or packaged samples. Confirm die quantity, thinning/dicing, package type, pad and pin definitions, bond diagram, assembly constraints, wafer-probe responsibilities and final-test scope. Distinguish planned deliverables from purchased and accepted services.

1. Make a pin and pad table with signal role, direction, supply domain and relevant electrical limits derived from the approved design.
2. Prepare a bring-up sequence: inspection, current-limited supply setup, reset/clock checks and the first observable test. A qualified engineer must determine safe limits for the actual device.
3. Define the board, connectors, instruments, firmware and known-good references needed to execute each test.
4. For each requirement, name the test stimulus, measurable expected result, tolerance source, owner and evidence file.
5. Review the bond/package/board correspondence before committing the board or packaging order. Track open decisions early enough to change them.

The pack’s first-silicon-test-plan.csv is a blank planning template. It supplies no electrical limits, production-test program or promised yield. Continue with the packaging and test tutorial.

7. Where MST can help

MST’s public tools help inspect basic file information and organize review materials. MPW coordination starts with a non-confidential application, process requirements, project stage, estimated die/sample needs and package/test expectations. Partners must confirm process fit, PDK access, schedule, pricing, verification requirements and acceptance. Use the MPW service entry when those responsibilities need to be coordinated; these educational results are not foundry signoff.

Sources and reproducibility

Geometry scripts were executed using KLayout 0.30.12. The official Python API guide and cell hierarchy reference document the inspection primitives. Review the SKY130 verification documentation for one process-specific example; its rules must not be substituted for another process. MST code and synthetic examples are MIT licensed; KLayout is a separately installed dependency with its own license.