HHGrace MPW PDK, NDA & Overseas Onboarding

Short answer: An overseas team should not treat HHGrace (Hua Hong / 华虹) PDK access as a download request. Prepare the contracting entity, country/region, application and end use, intended node/process family, named users, EDA environment, IP/library needs, schedule owner and secure exchange path. MST Singapore can screen that non-confidential onboarding brief and coordinate the next review as a non-exclusive agent for overseas projects. The fab decides NDA terms, customer eligibility, PDK access, permitted users, technology scope and project acceptance case by case.

NDA signature and PDK access are related but different gates. An NDA creates a legal framework for defined confidential exchanges. It does not automatically grant a design kit, every process option, unrestricted redistribution or permission for contractors in other entities. A practical onboarding plan therefore maps the legal entity, people, technology and tooling before the design schedule depends on access.

Start with the legal and project identity

HHGrace’s public customer-inquiry form requests contact and company information plus application market, end product, chip type and platform. That is a useful indication of the initial identity and project context needed for review. An overseas team should also identify which entity will contract, which country or region it operates from, who owns the product, whether third-party design houses are involved and which end-use or compliance questions need an owner.

Keep the first brief non-confidential. A company profile, product category and high-level process requirement are normally enough to determine what legal and technical questions come next. Proprietary schematics, netlists, layout, rule decks and PDK files belong only in an approved controlled exchange.

Separate NDA, customer setup and PDK gates

Map every PDK user and tool dependency

List the engineers who need access, their employers, work locations and roles. Include external design houses, IP vendors and contractors rather than assuming the main customer’s NDA covers them. State the EDA vendors and versions used for schematic capture, simulation, layout, extraction and physical verification. Record operating-system or licence-server constraints that could make an otherwise available kit unusable.

Also list the controlled deliverables the project expects: device models, design rules, verification decks, technology files, standard cells, memories, IO, analog/RF models and documentation. Do not assume each item is bundled with a process name. Some items may have separate licences, qualification states or approval paths.

A non-confidential overseas onboarding checklist

1. Company: contracting entity, website, address, size/context and responsible commercial contact.
2. Project: application market, end product, chip type, node/process hypothesis and target schedule.
3. People: internal users, design partners, contractors, locations and responsible programme owner.
4. Tools: EDA vendors/versions, operating environment, IP/library needs and CAD support owner.
5. Control: secure account, approved storage, least-privilege access, revocation and audit responsibility.
6. Open questions: NDA parties, eligible technology, required agreements, compliance conditions and expected review sequence.

Plan onboarding as a project workstream. Legal review, customer setup, account provisioning, tool installation and technical familiarization all take time. A schedule that starts physical design on the assumed PDK-receipt date is fragile; it needs owners, dependencies and contingency.

What MST can coordinate

MST can identify missing fields, help separate public intake from controlled exchange and coordinate the question set with the HHGrace route. It can also keep the project’s open issues and owners visible. MST does not decide the NDA, issue PDK credentials, broaden licence rights or approve a customer. Those decisions remain with the responsible fab and contracting parties.

Security and governance red flags

• A shared generic account is proposed for engineers across multiple entities.
• The design house is expected to receive files even though it is not named in the legal/access scope.
• The team cannot identify which PDK version, tool version or library release the schedule assumes.
• Controlled files are planned for consumer cloud storage, public repositories or email forwarding.
• The project has no access-revocation owner when staff or suppliers change.
• NDA completion is treated as proof of capacity, process fit or order acceptance.

Use the right supporting resources

Use the HHGrace MPW agent entry for the route-specific enquiry. Use the PDK Checklist to structure legal, user, tooling and controlled-exchange readiness before depending on a PDK date.

Frequently asked questions

Does signing an NDA guarantee HHGrace PDK access?

No. The fab still reviews customer eligibility, technology scope, named users, agreements and the project context. NDA and PDK authorization are separate gates.

Can an overseas design house use the customer’s PDK?

Only if the applicable agreements and fab approval cover that entity, its named users and permitted use. Do not assume a customer NDA automatically includes contractors or affiliates.

What can I provide before the NDA?

Provide company identity, application, end product, high-level chip/process requirements, user/tooling context and schedule assumptions. Keep proprietary design data and controlled technology files out of public intake.

Why should EDA versions be part of onboarding?

A PDK may rely on specific tool releases, verification engines or operating environments. Discovering a mismatch after access can delay implementation and support.

Who issues the PDK and approves access?

The responsible fab controls the kit, licence scope and authorization. MST prepares and coordinates the enquiry; it does not issue PDK files or credentials.

Primary sources and review boundary

• HHGrace Customer Inquiry — official public company, contact, application, product, chip-type and platform intake fields.
• HHGrace Online — official controlled customer-access surface.
• HHGrace Online FAQ — official support context.
• GlobalFoundries Process Design Kits — official generic evidence that PDKs contain controlled design enablement and platform-specific resources; it does not describe HHGrace entitlement.
• Hua Hong Semiconductor 2025 Annual Report — public company/platform context, not a PDK authorization source.

Last technically reviewed: August 9, 2026. Public intake and login pages do not establish entitlement. NDA terms, customer eligibility, PDK scope, named-user access, technical fit, capacity, schedule and project acceptance remain fab-confirmed case by case.