Product Updates

MPW Readiness Report Example: What MST Checks Before Partner Review

An MPW readiness report helps a team understand what is complete, what is missing and what should not be uploaded before the NDA and partner-review path is clear.

MPW readiness report review with wafer and checklist dashboard
Key Takeaways
  • Answer-first summary
  • Report sections
  • Example scoring model
  • Example output
  • How this becomes a commercial product

Answer-first summary

An MPW readiness report tells a customer whether an early mature-node prototype request is ready for partner review. It does not replace partner review and does not confirm price, schedule, PDK access or capacity. Its job is to show what is complete, what is missing, what should not be uploaded yet and what the next safe action should be.

MST uses this report format to move vague MPW interest toward a structured, non-confidential RFQ brief. The report can be used before NDA because it relies on high-level planning information rather than design IP.

Report sections

1. Intake completeness

The report checks whether the customer provided the minimum non-confidential fields: application, node range, process family, rough die area, sample target, package/test assumptions, timeline, country and end-use context. Missing fields are listed as follow-up questions.

2. Process-fit hypothesis

The report classifies the request into a tentative process family such as analog, mixed-signal, RF, high-voltage, BCD, sensor-oriented, eNVM-related or plain CMOS. This is a hypothesis for review, not a final route decision.

3. NDA and PDK path status

The report states whether the inquiry is still public-intake only, whether NDA is required next, whether PDK access is a future question and whether any customer design information should remain withheld until the controlled path is clear.

4. Package and test readiness

Many MPW requests mention only wafer access. The report scores whether the customer has stated package preference, pad-count estimate, wafer-probe need, final-test need, characterization goal, sample handling and logistics assumptions.

5. Compliance and disclosure flags

The report records country, end-use and customer-type context at a high level. It also flags whether any requested disclosure, file sharing or route naming should wait for written approval and partner confirmation.

6. Schedule realism

The report separates the customer’s desired date from what can actually be confirmed. Early schedule discussion can identify urgency, but shuttle windows, queue position, packaging lead time and test scope require partner confirmation.

Example scoring model

A practical readiness score can use five bands:

  • 0-20: Idea only. Application is visible, but node, process family, die estimate, samples and package/test assumptions are missing.
  • 21-40: Early brief. Basic application and node range exist, but package/test scope, design maturity or end-use context is incomplete.
  • 41-60: Reviewable with gaps. The brief can be discussed, but partner review needs follow-up questions before any route can be evaluated.
  • 61-80: Partner-review candidate. The request is structured enough to prepare a foundry-review packet, subject to compliance and NDA path.
  • 81-100: Controlled technical review candidate. The project has a clear brief and known gaps, but design files still wait for the correct NDA/PDK path.

These bands are internal readiness labels, not acceptance decisions. Partner review remains the gate for process availability, commercial terms and technical next steps.

Example output

Customer brief

The customer is evaluating a mature-node mixed-signal prototype for an industrial sensor application. Target node range is approximate. Process family may require analog or mixed-signal options. The customer wants a small sample quantity for first-silicon learning and has not finalized package or wafer-probe scope.

Readiness result

The request is reviewable with gaps. MST should ask for die-area estimate, package preference, wafer-probe expectation, characterization goal, country/end-use context and design maturity before preparing a partner-review packet.

Do not upload yet

Do not upload GDS, OASIS, RTL, netlists, schematics, source code, PDK files, masks or proprietary IP at this stage. These materials require the correct NDA, PDK and partner-confirmed review path.

Suggested next step

Prepare a non-confidential RFQ brief and route it for MST screening. If the brief remains plausible after screening, prepare a partner-review packet. If process or package/test scope is too unclear, return a focused follow-up questionnaire first.

How this becomes a commercial product

The readiness report can be a low-friction entry product for teams that are not yet tapeout-ready. It gives them a useful output even when they are too early for partner review. It also protects MST and qualified partners from spending review time on incomplete or unsafe inquiries.

← Back to News

Start with a high-level brief

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.