The ecosystem¶
The IHP Open ADK is one repository in a set that together forms an open flow for 2.5D heterogeneous integration. This page names each repository, says what it owns, and shows how they fit together. The rule of thumb is that each repository owns exactly one contract, and nothing owns two.
The repositories¶
Repository |
License |
Owns |
|---|---|---|
Apache-2.0 |
The assembly rules, the adapter contract, the DRU generator, the 3Dblox exporter and the manifest-level checks. This site’s primary subject. |
|
Apache-2.0 |
The |
|
Apache-2.0 |
The IntM4TM2 interposer technology: layers, KLayout technology, its own fabrication DRC, and the Cu-pillar structures. |
|
Apache-2.0 |
The attachment method registry: Cu pillars, solder bumps, microbumps, with their parameters and 3D bodies. |
|
GPL-3.0-or-later |
The KiCad fork hardened for nanometre-scale layout and carrying the semiconductor exports. |
|
GPL-3.0-or-later |
The pcbnew export plugin, the flow orchestrator, and the HyperLynx to GDS converter. |
|
GPL-3.0-or-later |
Conversion of die GDS into KiCad footprints, symbols and pin lists. |
|
GPL-3.0-or-later |
The 3D assembly viewer and |
|
GPL-3.0-or-later |
The container that pins and builds the seven tools above, plus the
reference design. The |
The base process PDK, IHP-GmbH/IHP-Open-PDK, sits underneath all of this and is documented separately at https://ihp-open-pdk-docs.readthedocs.io.
Note
The pinned revision of each repository, as documented by this site, is in the version matrix on The ADK-Tools image. That table is generated from the submodules this documentation is built against, so it always describes the code these pages actually describe.
How they connect¶
The tools of the ecosystem. Each addresses one step that had no open answer.¶
The same set in data-flow terms, following the files rather than the tools:
The ecosystem in data-flow terms. Each repository owns one contract and hands one artefact to the next.¶
Two artefacts hold this together.
The .chiplet file is the pivot format. It records where every component
sits in one shared frame, how each die is mounted in z, its orientation, and
which artwork it refers to. Every tool downstream of layout reads it, and it
remains the authoritative placement source even when a derived view, such as a
3Dblox assembly, is exported from it.
The .lyp layer property files are the shared layer source of truth. The
interposer PDK owns them, and the converter, the layout tool and the viewer all
read the same files rather than each carrying its own layer table.
Who owns which rules¶
Rule kind |
Owner |
|---|---|
Can this metal shape be fabricated on this process |
The relevant PDK. The ADK never touches these. |
Can these vias and pads be built on the interposer |
The interposer PDK. |
Is this bump pitch achievable by this attachment method |
The interconnect PDK provides the numbers, the ADK’s IXN axis applies them to the assembly. |
May this die sit here, at this spacing |
The ADK’s ASM axis. |
Do the pads of this die land on the pillars actually drawn |
The ADK’s manifest-level check. |
Finding your dependencies¶
Every tool locates the others through one shared discovery chain rather than fixed relative paths. They all use the same discovery chain rather than fixed relative paths, and the container sets the roots for you. Environment and path discovery has the full table.
Licensing in practice¶
The ADK, the format specification and both PDKs are Apache-2.0, so a rule deck, an adapter or a reader can be reused with minimal obligation. The tools built on KiCad and KLayout are GPL, as their upstreams require.
The container image is a mere aggregation of independently licensed components.
Each keeps its own license, and NOTICE.md in the ADK-Tools repository
carries the per-component breakdown together with the corresponding-source
obligation that applies if you redistribute the image.