How MST Prepares a Foundry-Review Packet for Mature-Node MPW
A foundry-review packet turns an early MPW request into a structured, non-confidential brief that a qualified partner can review without public-intake design IP.
- →Answer-first summary
- →Why the packet matters
- →Core sections of a review packet
- →What MST can return to the customer
- →What the packet is not
Answer-first summary
A foundry-review packet is the structured brief that sits between a customer’s early MPW request and a qualified partner review. It should make the project understandable without asking the customer to upload GDS, RTL, netlists, schematics, PDK files, mask data or proprietary design IP at public intake.
MST prepares this packet by normalizing the customer’s requirement, screening process-fit questions, separating public planning items from NDA-gated technical exchange, defining package and test assumptions, and asking for a partner-confirmed next step. It is not a capacity promise, price list, shuttle reservation or public disclosure of a named foundry route.
Why the packet matters
Many early MPW inquiries arrive as a short email: a desired node, an application idea, a target sample count and a hoped-for date. That is not enough for a serious review, but it is also too early to ask for the most sensitive design files. The review packet gives both sides a safer middle ground.
For the customer, it clarifies what is missing before more technical data moves. For the partner, it removes vague intake noise and turns the request into a consistent review object. For MST, it creates a repeatable qualification layer instead of forwarding unstructured messages.
Core sections of a review packet
1. Customer and project context
The packet records the customer organization type, country, application area, intended end use and contact channel. This is not a substitute for legal screening, but it keeps geography, customer type and end-use context visible from the beginning.
2. Non-confidential technical brief
The technical brief should include target node or node range, process family, rough die-area estimate, expected sample count, intended package direction, wafer probe or final-test assumptions, schedule pressure and current design maturity.
At this stage, the brief should avoid circuit implementation detail. It should not include GDS, OASIS, RTL, netlists, schematics, PDK files, source code, masks or proprietary IP.
3. Process-fit questions
A mature-node inquiry is rarely just a node name. Analog, mixed-signal, RF, high-voltage, BCD, eNVM, sensor and power-related requests may require different process options. MST turns the customer’s request into questions a qualified partner can answer: possible process family, unavailable assumptions, device-option uncertainty and whether the request should move toward MPW, engineering run, full-mask review or design-support discussion.
4. NDA and PDK path
The packet separates what can be discussed publicly from what belongs behind NDA and PDK access. Public planning can cover node range, process family and high-level intent. PDK files, detailed design data, design-rule detail and partner-specific technical rules require the correct controlled path.
5. Package, probe and test scope
A wafer-only conversation often fails later when package and test assumptions appear. The packet should record package preference, pad-count estimate if available, wafer-probe needs, final-test expectations, characterization goals, sample logistics and any special handling assumptions.
6. Readiness gaps and requested response
The packet ends with open gaps, risk flags and a concrete requested partner response. Examples include: confirm whether the process family is plausible, identify the NDA/PDK gate, request package/test clarification, reject an unsuitable route or ask for missing non-confidential information before review continues.
What MST can return to the customer
After reviewing the intake, MST can return a structured readiness note: what is complete, what is missing, which assumptions are risky, what should not be uploaded yet and what the next qualified review step should be. This may become a partner-review packet, a request for more non-confidential details, a recommendation to prepare package/test scope, or a recommendation to seek design/layout support before MPW routing.
What the packet is not
The packet is not a public quote, a slot reservation, a PDK access confirmation, a schedule promise, a yield estimate, or a named-route announcement. Availability, pricing, PDK access, schedule, packaging, wafer probe and final test remain case-by-case and partner-confirmed.
Practical checklist
- Application and end-use context are stated at a non-confidential level.
- Node range and process family are described as assumptions, not final claims.
- Die area, sample count and timeline are approximate but visible.
- Package, wafer probe and final test are included in the scope.
- NDA and PDK questions are separated from public intake questions.
- No GDS, RTL, netlist, schematic, source code, PDK file, mask data or proprietary IP is attached.
- The requested partner response is clear and bounded.
Where AI helps
AI can help convert an unstructured email or form response into a clean first brief, flag missing fields, classify NDA-gated items, draft package/test questions and highlight inconsistent assumptions. AI should not confirm process availability, price, PDK access, shuttle windows or capacity. Those remain human and partner-confirmed decisions.
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.