OCP’s Material Design Kit tackles an unglamorous but consequential problem: getting trustworthy material data into the tools used to design and analyze chiplet systems.
People often talk about chiplets as though the hard part is getting two dies to communicate. That is certainly one hard part, but it is not the end of the problem.
Once several dies are placed in the same package, the package itself becomes part of the system. Heat crosses die attach layers, underfill, interposers, substrates, lids, and thermal interface materials. Signals travel through conductors and dielectrics whose behavior changes with frequency and temperature. Every power cycle causes materials with different expansion rates to pull against one another.
At that point, material data is design data.
The trouble is that this data rarely arrives in a form that can move cleanly through a design flow. It may be scattered across supplier data sheets, spreadsheets, test reports, email threads, and private tool libraries. One team records thermal conductivity at room temperature. Another needs a temperature-dependent curve. A dielectric constant is copied into a model without the frequency at which it was measured. Months later, two simulations disagree and nobody can tell whether the cause is physics, geometry, or simply a different material entry.
The Open Compute Project’s Material Design Kit, or MDK, is an attempt to make that situation less normal.
One number is not a material model
Published as Version 1.0 in January 2025, the OCP Material Design Kit defines a common way to describe the materials used in dies, packages, substrates, interposers, redistribution layers, and 3D assemblies.
Its scope is deliberately broad. The document covers electrical properties such as dielectric constant, loss, conductivity, and resistivity; thermal and thermo-mechanical behavior; structural and failure properties; and even optical and surface characteristics. Values can be recorded with their units and the conditions under which they apply.
That last part matters more than it may appear. A thermal conductivity value without a temperature can be misleading. A dielectric constant without a frequency is incomplete. Coefficient of thermal expansion is often treated as a single convenient number even when the material changes behavior over the operating range. The MDK gives these dependencies somewhere to live.
It also includes an XML schema. In practical terms, that means material information can be structured for software rather than written only for a person reading a PDF. A tool can check that expected fields are present, distinguish one property family from another, and carry the same definition into more than one analysis flow.
The MDK is not the first attempt to organize material information, and it will not make every existing library obsolete. Its value is that it gives companies a neutral exchange point. A supplier, an OSAT, an EDA vendor, and a system company no longer have to invent the basic shape of the handoff each time they work together.
The less visible side of chiplet interoperability
Interoperability discussions naturally gravitate toward die-to-die interfaces. Protocols, PHYs, bump pitch, bandwidth, and latency are easy to connect to product performance. Material information is less visible, but a compatible interface does not tell an engineer whether the proposed assembly will warp, overheat, or survive repeated thermal cycling.
This is why the MDK belongs to a larger family of design kits being developed through OCP’s Chiplet Design Exchange workstream. The Chiplet Design Kit describes the die. The Assembly Design Kit captures placement and assembly rules. The Test Design Kit describes how the parts can be accessed and tested. Signal- and power-integrity kits support electrical analysis. The MDK supplies the physical properties needed to understand what the chosen materials will do.
Alongside these kits, CDXML provides a machine-readable description of a chiplet. The aim is not to create one enormous file that answers every question. It is to replace a collection of disconnected handoffs with a set of descriptions that can travel together.
That becomes important early in a program, not just during signoff. Consider a package architect deciding whether two high-power dies should be moved closer together. The shorter connection may help electrical performance, but it may also increase thermal coupling. Changing the substrate or heat spreader may improve one path while introducing a mechanical mismatch somewhere else. These are coupled decisions, and they are often made while the design is still fluid.
If electrical, thermal, and mechanical teams begin with different material assumptions, a co-optimization exercise is compromised before the first solver runs.
What a schema cannot fix
There is a risk in talking about standardization as if the publication of a schema settles the engineering problem. It does not.
An XML file can be perfectly valid and physically wrong. The MDK cannot determine whether a supplier used the right test method, whether a bulk measurement still applies at package scale, or whether an interface has been modeled faithfully. It cannot create missing temperature-dependent data or decide how much uncertainty should be assigned to an estimated value.
Nor will every useful property become public. Materials and processes are competitive technology, and some data will continue to be shared only under commercial agreements.
The MDK is also not a solver. It does not choose boundary conditions, build geometry, create a power map, select mesh resolution, or validate a model against measurements. Those remain engineering tasks.
What it can do is make assumptions easier to see. It can reduce retyping, unit mistakes, and accidental differences between tools. It can give reviewers a clearer path from a simulation result back to the material values that shaped it. None of this is glamorous. All of it saves time when a design is moving quickly.
From specification to engineering practice
The MDK was written by contributors from simulation, EDA, semiconductor, packaging, standards, and academic organizations. That mix is a fair reflection of the problem. No single participant in the supply chain owns all the information needed to describe a heterogeneous package.
That work sits close to Anemoi Software’s day-to-day focus. The company develops thermal modeling tools and workflows for chiplets, advanced packages, boards, and other compute-dense electronics. Its DankaThermal platform is built around comparing designs while packaging, materials, power maps, and cooling choices can still be changed. In that setting, material information is not background documentation. It is where the model begins.
This is also where the MDK’s usefulness will be tested. Standards become real when tools can read them, engineers can inspect them, and a design team can make a decision without first spending days reconstructing the inputs.
Success will look ordinary
The MDK is not finished in the sense that material characterization is ever finished. More properties, better measurements, tool support, and hard-won conventions will be needed as the industry uses it. Version 1.0 is a foundation.
If the work succeeds, the result may eventually feel unremarkable. A material definition will arrive with the part or package data. The receiving tool will understand it. An engineer will be able to see where a value came from and under what conditions it applies. Thermal, mechanical, and electrical teams will spend less time reconciling libraries and more time discussing the design.
That sort of routine exchange is exactly what a chiplet ecosystem needs. Silicon can only be modular if the information required to use it becomes modular too.
References
1. Open Compute Project, Material Design Kit (MDK), Version 1.0 (https://www.opencompute.org/documents/material-design-kits-mdk-2-pdf), January 2025.
2. Open Compute Project, Chiplet Data Exchange in XML Format (CDXML) (https://www.opencompute.org/chiplets/31/chiplet-data-exchange-in-xml-format-cdxml).
3. Open Compute Project, OCP and JEDEC announce a collaboration on chiplet standards (https://www.opencompute.org/blog/open-compute-project-foundation-and-jedec-announce-a-new-collaboration), January 2023.
4. Lawrence Berkeley National Laboratory, LBNL/OCP Open Chiplet Economy Experience Center demonstrations (https://chiplets.lbl.gov/past-events/open-chiplet-economy-experience-center/demos).
5. Semiconductor Engineering, 3DKs: Making Headway on Chiplet Standards (https://semiengineering.com/3dks-making-headway-on-chiplet-standards/).