PDK and Foundry Requirement Checklist Before MPW Review
A PDK and foundry requirement checklist keeps MPW conversations grounded in the right models, decks, documents, export context and handoff gates.
- →Answer-first summary
- →Why PDK questions need structure
- →Checklist areas before MPW review
- →Sample output from the checklist
- →Public-intake boundary
Answer-first summary
A PDK and foundry requirement checklist helps MPW teams separate public planning questions from NDA-gated technical access. Before partner review, a team should clarify process family, device options, model needs, DRC/LVS expectations, package/test assumptions, customer context and route restrictions. Detailed PDK files and foundry documents belong behind the correct NDA and access path.
MST’s PDK / Foundry Requirement Checklist is a planning tool for this stage. It helps a team identify what must be asked before a mature-node MPW request can move from general interest to a reviewable case.
Why PDK questions need structure
PDK access is not just a download link. A mature-node MPW project may need models, DRC/LVS decks, layer maps, reliability rules, device documents, IO libraries, SRAM or NVM options, special device permissions and package-related constraints. Some topics can be discussed publicly at category level; others require route-specific approval.
A checklist prevents teams from asking for the wrong thing too early. It also helps MST prepare a clean partner question set without exposing customer design files.
Checklist areas before MPW review
1. Process and option assumptions
- Target node range and acceptable alternatives
- Plain CMOS, analog/mixed-signal, BCD, high voltage, RF, eNVM or sensor process family
- Voltage domains and special device assumptions
- Memory, RF, high-voltage or thick-metal needs at category level
2. NDA and PDK path
- Who needs to sign NDA: customer, design house, MST, partner or multiple parties
- Whether customer legal review is required before PDK discussion
- Whether the route permits academic, startup, design-service or commercial access
- Whether the intended country, end use and customer type require manual review
3. Verification and handoff expectations
- DRC, LVS, ERC, antenna, density and reliability deck expectations
- Required signoff summaries before GDS/OASIS handoff
- Top-cell, pad-ring, seal-ring and scribe-lane assumptions
- Whether layout source, foundry decks or third-party IP files are excluded from public exchange
4. Package, probe and test
- Package family, pin count, die attach and wire-bond assumptions
- Wafer-probe requirement or wafer-only expectation
- Final-test and characterization scope
- Sample logistics and first-silicon bring-up support
Sample output from the checklist
| Question | Reason | Owner |
|---|---|---|
| Does the project require BCD or only mixed-signal CMOS? | Process-family choice changes route and review questions. | Customer engineering |
| Which entities need NDA before PDK discussion? | PDK and foundry documents require controlled access. | MST and customer legal |
| Is wafer probe expected before packaging? | Probe strategy affects cost, schedule and test planning. | Customer and package/test partner |
| Which end-use context must be disclosed at screening level? | Some cases require manual route and compliance review. | Customer commercial owner |
Public-intake boundary
The checklist can mention PDK needs, but it should not include PDK files, foundry manuals, device models, private libraries, proprietary decks, layout data or confidential customer IP. The goal is to identify the correct gate, not to move controlled files through the wrong channel.
How MST uses the checklist
MST uses checklist output to prepare a partner-review question set and to decide whether the case is ready for an RFQ packet. Teams can start with the PDK / Foundry Requirement Checklist, then attach the non-confidential summary to an MPW RFQ intake.
Related Articles
Ready to scope your run?
Send node, process family, die area, volume and timeline - no design IP. We screen it, route to a qualified partner, and return an indicative quote.