Skip to content
IHP - Leibniz Institute for High Performance Microelectronics Leibniz Institute
for High Performance Microelectronics
 
Contributing
Type to start searching
    IHP-GmbH/IHP-Open-ADK
    • IHP Open ADK 0.2.0 documentation
    • business IHP Microelectronics
    • precision_manufacturing Shuttle Program
    • menu_book Open PDK Docs
    • chat_bubble Chat
    • bug_report Issues
    IHP-GmbH/IHP-Open-ADK
      • 1. Build the image
      • 2. Check the image
      • 3. Look at the assembly
      • 4. Start your own design
      • Where to go next
        • The role model
        • The abstraction boundary
          • The geometric axis: assembly DRC
          • The connectivity axis: assembly LVS
        • What the ADK is not
        • Where the boundary comes from
        • A note on maturity
        • Why heterogeneous integration
        • What was missing
        • How the ADK closes it
        • The approach
        • Positioning
        • The repositories
        • How they connect
        • Who owns which rules
        • Finding your dependencies
        • Licensing in practice
        • Assembly concepts
        • Kits and rules
        • Geometry and attachment
        • Formats and frames
        • Tools
        • Prerequisites
        • Clone with submodules
        • Build the image
        • Run the image
        • Graphics
        • The shared folder
        • Scaffold a project
        • List the tools
        • Run the self test
        • Where to go next
        • The reference platform
        • System packages
        • The worker virtual environment
        • KLayout
        • The KiCad fork
        • The chiplet export plugin
        • gds2kicad
        • The ADK
        • Chiplet Studio
        • The PDKs
        • The base SG13G2 PDK slice
        • OpenROAD
        • Wiring it together
        • The discovery chain
        • The variables
        • Marker subpaths and accepted directory names
        • Where the walk starts
          • The worker interpreter
          • The ADK runner, seen from the plugin
        • Fail loud, do not degrade
        • ${VAR} references in path inputs
        • Setting the environment
        • See also
        • What goes in and what comes out
        • The flow at a glance
        • The stages
        • The pivot artefact: .chiplet
        • The shared layer source of truth: .lyp
        • What the assembly checks actually check
        • Project layout
        • Where to go next
        • What you are producing
        • Step 1: look at the GDS before converting it
        • Step 2: say where the pads are
        • Step 3: curate the pads
          • Pad numbers are pad names
        • Step 5: generate the symbol
        • A die with no GDS
        • Interposer I/O pads
        • Traceability properties
        • Checking the result
        • Next
        • Before you start
        • Start from the template board
        • Draw the outline
        • Project text variables
        • Register the project libraries
        • Draw the schematic
        • Place the dies
        • Place the I/O pads
        • Route
        • Check while you design
        • What is not checked here
        • Next
        • Running the export
        • What happens when you press Run
        • Headless
        • The output tree
          • <board>.chiplet
          • MANIFEST.md
          • <board>.hyp
          • layout/<board>_interposer.gds
          • layout/<board>_complete.gds
          • layout/<stem>.boundaries.json
          • layout/<stem>.pillars.json
          • layout/<stem>.ixn_methods.json
          • reports/<board>_assembly_drc.lyrdb
          • reports/<board>_cupillar_drc.json
        • Deliverables and intermediates
        • Checking the export
        • Common failures
        • Next
        • What the converter consumes
        • What it produces
        • Running it
          • Copper layers must be named after the process metals
          • Traces, arcs and the outline
          • Vias come from the base PDK’s own PCells
          • Why a missing interposer PDK is fatal here
        • Flip-chip placement
          • Boundary manifest
          • Pillar manifest
          • Optional boundary annotation
        • After the conversion
        • Stage 1: KiCad design-time rules
        • Stage 2: the 3Dblox export and check_3dblox
        • Stage 3: the KLayout assembly DRC
        • Stage 4: the pad-to-pillar alignment check
        • Producer-side checks
        • Where each stage sits in the flow
        • What none of these stages cover
          • How the file resolves its layouts
          • What the panels give you
          • Drilling down into a component’s layout
          • Other panels
        • Opening the GDS in KLayout with named layers
        • Walking DRC violations in the Marker Browser
        • Viewing chiplet boundaries
        • Related pages
        • What the demo assembles
        • Directory tree
          • chiplets/
          • kicad/
          • outputs/
          • Step 0: open what is already there
          • Step 1: the gds2kicad prior steps
          • Step 2: author the board
          • Step 3: export and generate the GDS
          • Step 4: the assembly DRC on its own
          • Step 5: checks the demo does not run for you
          • Step 6: the one-command self test
        • What the committed reports say
        • Reproducibility
        • What the demo demonstrates
        • What it does not demonstrate
        • Starting your own design
        • The role model
        • The abstraction boundary
        • Why there is no chiplet adapter
        • Adding an interposer
        • The interconnect axis
        • The eval chain
        • Cross-tool consistency
        • Known limitations
          • Location and selection
          • Shipped interposer adapters
          • Required abstract inputs
          • Optional rule-parameter overrides
          • What interposer adapters must NOT do
          • Selecting an interconnect adapter
          • Shipped interconnect adapters
          • The parameter pack
          • Optional region narrowing
          • What interconnect adapters must NOT do
          • Per-method refinement
        • Evolving the contract
        • Writing an adapter for a new interposer
        • The rule set
        • What the rules see
          • ASM.a: chiplet boundaries must not overlap
          • ASM.b: minimum chiplet-to-chiplet spacing
          • ASM.e: minimum chiplet area
          • ASM.f: attachment geometry must not straddle a chiplet edge
        • There is no ASM.c and no ASM.d
        • Single-tier limitation
        • Where the numbers come from
        • Running these rules
        • The axis is optional and additive
        • The rule set
        • The checked region
          • Assembly-global mode
          • Per-method mode
        • Why pitch is checked as a spacing
        • The 10 nm circle tolerance
        • Fail-loud validation
        • Where the numbers come from
        • Shipped interconnect adapters
        • Prerequisites
        • The minimal invocation
        • Adding the interconnect axis
        • Command-line reference
        • Flags in detail
        • Manifest discovery and validation
        • The legacy exchange0 path
        • Run modes
        • What lands in the run directory
        • Reading the report in KLayout
        • Exit codes
        • Troubleshooting
        • What the generator produces
        • Coverage matrix
        • Running the generator
        • How adapter overrides are merged
        • Importing the renderer
        • Files
        • What it consumes and what it emits
        • Running the exporter
        • What the output looks like
          • z consistency, exactly
          • Mounting on attachment_surface_z
          • Rotation restricted to quarter turns
          • Orientation, and why face_down is rejected
          • The anchor requirement
          • Other preconditions
        • Bump-aware export
        • Loading the result in OpenROAD
        • Importable entry points
          • Extracting pads from a GDS
        • The transform
          • Findings
          • Auto-resolve demotion
          • Tolerance
          • The JSON report
          • --strict
          • Exit codes
        • Importable entry points
        • Version discipline
        • config/rule_params.json
        • config/interconnect.json
        • config/layers.json
        • config/chiplet_pads.json
          • Rule parameter registry
          • Interconnect registry
          • Layer registry
        • Sidecar schemas
        • Changing a registry
          • Relationship to CDXML, JEP30 and 3Dblox
        • File structure
        • The assembly block
        • The technologies block
        • The connection_stacks block
        • Paths and the ${VAR} convention
        • Validation rules
          • Implementer rights
        • Where to go next
          • Geometry: position, dimensions and anchor
          • orientation
          • connection and per-die z-mounting
          • The interposer attachment_surface_z
          • io_pads
          • die_array
          • interconnect
          • interfaces
          • netlist
          • flow
          • _metadata and intermediate files
          • Proposed extensions: cdxml_ref and 3dblox_ref
        • A complete example
        • Where to go next
        • The rules in brief
          • Why the GDS bbox corner
          • Interposer dimensions against interposer position
        • The anchor convention
        • Orientation and flip-chip mirroring
          • Worked case
          • The 3D world frame
          • How the mounting surface resolves
          • Worked case, two dies and two methods
          • Edge cases
        • io_pads
        • The leak guard
          • Why KiCad needs a finalizer
        • The reader contract
        • Verification fixtures
        • Appendix: glossary of coordinate frames
        • Where to go next
        • File location and auto-discovery
        • Producers and consumers
          • Top level
          • Boundary entries
          • Which fields are authoritative
          • Vestigial fields
          • The schema file
        • Version policy
          • The legacy path
        • Example
        • File location
        • Producers and consumers
          • Top level
          • Pillar entries
          • The schema file
          • As drawn, not as requested
          • The canonical frame
          • Auto-resolve bookkeeping
        • Version policy
        • Example
        • Using it
        • File location
          • Top level
          • Method entries
          • The schema file
        • Example
        • How the exporter derives the file
        • One interconnect PDK, many methods
        • What the deck does with it
        • Version policy
          • Metadata
          • Pin entries
          • Coordinate frame
          • From a die GDS
          • From a KiCad footprint
          • The dbu_um caveat
          • Consumer 1: bump maps for the 3Dblox export
          • Consumer 2: pad positions for the alignment check
        • What 3Dblox is
        • The shared core
        • Forward mapping, .chiplet to 3Dblox
          • Dropped by declaration
          • Not expressible in .chiplet v1.0
          • External inputs an export needs
          • Connection thickness is the stack height, exactly
          • The attachment surface is not the maximum z
          • Flip is a mounting intent, not a shared mirror convention
          • Physical thickness has one source
        • The reverse direction
        • The 3dblox_ref proposed extension
        • One assembly, one authoritative placement source
        • The exporter in the ADK
        • Why a fork
          • Geometry limits
          • Units and grids
          • Rendering at extreme zoom
          • Integer arithmetic
          • Zone filling
          • Export precision, HyperLynx
          • Export precision, chiplet
          • Python surface
          • Stability
        • Where the exports live in the UI
        • How it is built and pinned
        • What this page does not assert
        • What one run produces
        • Reaching it
          • Output directory
          • Outputs
          • PDK roots
          • Pipeline options
          • Per-die settings
          • Assembly DRC
          • The sequence
          • Turning a design into runner flags
          • The two adapter axes
        • Boundaries: manifest, not layer
        • Headless use
        • Writer parity
        • Troubleshooting
        • The problem it solves
        • Installing
          • The role of the .lyp
          • Pad extraction
          • Traceability properties
        • Die to symbol
        • The pin list
        • Curating pads by hand
        • Database units
        • Black-box chiplets
        • Interposer I/O pads
        • Board back to chiplet netlist
        • The GUIs
        • Where files are written
        • Troubleshooting
        • What it is for
          • Importing a bare GDS
          • Render modes
          • Black-box chiplets
          • Attachment bodies
        • The 2D drill-down
        • The net graph
        • The flow pipeline
        • Python scripting
        • Running the application
        • Resolving PDK roots
        • Known limits
          • The metal stack
          • How many layers
          • The decks
          • Rule values
          • Testing
        • LVS
        • The PCell library
        • Cu-pillar generation
          • The board template
          • Device footprints and symbols
        • What INTERPOSER_PDK_ROOT provides
        • Simulation and extraction support
        • Why this is a separate PDK
        • The method registry
          • Parameters per method
          • Fabrication anchors
        • The 3D auxiliary layers
          • Bump bodies
          • Bump macros for OpenROAD
        • 3D stackup fragments
        • The standalone DRC deck
        • Relationship to the ADK
        • What INTERCONNECT_PDK_ROOT provides
        • The submodules are the lockfile
        • Build stages
        • The verify stage is the release gate
        • Pinned components
        • The version story
        • Updating a clone
        • Testing one tool at a different revision
        • Mounting a development checkout
        • Releases
        • Licensing
        • Thermal
        • Power delivery
        • Timing
        • What would have to change first
        • 2.5D place and route
        • Extraction and signal integrity
        • Multiphysics analysis
      • The connectivity axis of assembly verification
        • Where a change belongs
        • Adding an adapter
        • Rules and their two consumers
        • Tests
        • The container as the integration gate
        • Commit conventions
        • Getting a local build
        • What is generated
        • Updating to newer sources
        • Writing conventions
        • Editorial rules
      • Project resources
      • Bibliography
    • Show Source

    Contributing¶

    Contributing

    • Contributing to the ADK
      • Where a change belongs
      • Adding an adapter
      • Rules and their two consumers
      • Tests
      • The container as the integration gate
      • Commit conventions
    • Contributing to this documentation
      • Getting a local build
      • What is generated
      • Updating to newer sources
      • Writing conventions
      • Editorial rules
    Previous Analysis and automation
    Next Contributing to the ADK
    GitHub
    License
    © Copyright 2026, IHP Open ADK Authors.
    Created using Sphinx 7.4.7. and Material for Sphinx