{
  "schemaVersion": 1,
  "id": "atlas-lesson-die-link-compatibility",
  "title": "Die-to-die links and UCIe compatibility",
  "category": "learning",
  "format": "Atlas lesson",
  "description": "Defines what adjacent chiplets must agree on to exchange useful data.",
  "canonicalUrl": "https://semiaifoundry.com/learn/atlas/die-link-compatibility/",
  "publishedDate": null,
  "revisionDate": "2026-10-07",
  "author": null,
  "topic": "Chip-to-hall integration",
  "series": null,
  "license": null,
  "rightsUrl": "https://semiaifoundry.com/ai-atlas/licenses.html",
  "version": "1.3.0",
  "status": "Published educational lesson",
  "evidenceScope": "The example does not claim a UCIe configuration. Public initialization guidance supplies the mechanism; vendor interoperability test results remain configuration-specific.",
  "contentCoverage": "published-lesson",
  "artifactUrl": "https://semiaifoundry.com/ai-atlas/lesson-data/die-link-compatibility-e2fb037f49d24af9.json",
  "interactiveUrl": "https://semiaifoundry.com/ai-atlas/#die-link-compatibility",
  "related": [],
  "supersedes": [],
  "supersededBy": [],
  "contentHash": "4f8b46b904477dc2002505873ade061817bc1cf1aa205b54fd1d936f654cda79",
  "contentLength": 4650,
  "jsonUrl": "https://semiaifoundry.com/agents/publications/atlas-lesson-die-link-compatibility.json",
  "markdownUrl": "https://semiaifoundry.com/agents/publications/atlas-lesson-die-link-compatibility.md",
  "sections": [
    {
      "id": "section-1",
      "title": "Die-to-die links and UCIe compatibility",
      "start": 41,
      "end": 402
    },
    {
      "id": "section-2",
      "title": "The mechanism",
      "start": 402,
      "end": 1500
    },
    {
      "id": "section-3",
      "title": "Science and assumptions",
      "start": 1500,
      "end": 1528
    },
    {
      "id": "section-4",
      "title": "Usable link rate",
      "start": 1528,
      "end": 2198
    },
    {
      "id": "section-5",
      "title": "Engineering example",
      "start": 2198,
      "end": 2393
    },
    {
      "id": "section-6",
      "title": "Distinctions and tradeoffs",
      "start": 2393,
      "end": 2820
    },
    {
      "id": "section-7",
      "title": "Specifications and interfaces",
      "start": 2820,
      "end": 3066
    },
    {
      "id": "section-8",
      "title": "Interfaces",
      "start": 3066,
      "end": 3229
    },
    {
      "id": "section-9",
      "title": "Check your understanding",
      "start": 3229,
      "end": 3258
    },
    {
      "id": "section-10",
      "title": "What must match beyond a connector or standard name?",
      "start": 3258,
      "end": 3602
    },
    {
      "id": "section-11",
      "title": "Evidence and scope",
      "start": 3602,
      "end": 3969
    },
    {
      "id": "section-12",
      "title": "Sources",
      "start": 3969,
      "end": 4301
    },
    {
      "id": "section-13",
      "title": "Continue exploring",
      "start": 4301,
      "end": 4324
    },
    {
      "id": "section-14",
      "title": "Foundations",
      "start": 4324,
      "end": 4518
    },
    {
      "id": "section-15",
      "title": "Related lessons",
      "start": 4518,
      "end": 4650
    }
  ],
  "citations": [
    {
      "title": "Explore in Atlas",
      "url": "https://semiaifoundry.com/ai-atlas/#die-link-compatibility"
    },
    {
      "title": "Introduction to UCIe webinar: Q&A recap",
      "url": "https://www.uciexpress.org/post/introduction-to-ucie-webinar-q-a-recap"
    },
    {
      "title": "Published lesson data",
      "url": "https://semiaifoundry.com/ai-atlas/lesson-data/die-link-compatibility-e2fb037f49d24af9.json"
    },
    {
      "title": "Atlas releases and licensing",
      "url": "https://semiaifoundry.com/ai-atlas/licenses.html"
    },
    {
      "title": "Interposer and redistribution layers",
      "url": "https://semiaifoundry.com/learn/atlas/interposer/"
    },
    {
      "title": "Package substrate",
      "url": "https://semiaifoundry.com/learn/atlas/package-substrate/"
    },
    {
      "title": "Signal integrity, timing and the eye diagram",
      "url": "https://semiaifoundry.com/learn/atlas/interface-signal-eye/"
    }
  ],
  "recordHash": "6a4be79447e005e2405057e3533f33f0916295df6600e2c763dd876166fd44bf",
  "contentFormat": "text/markdown",
  "content": "Chip-to-hall integration · Atlas v1.3.0\n\n# Die-to-die links and UCIe compatibility\n\nDefines what adjacent chiplets must agree on to exchange useful data.\n\n[Explore in Atlas](https://semiaifoundry.com/ai-atlas/#die-link-compatibility)Micrometers of package wiring to board-scale links; schematic\n\nLearning objectiveSeparate die-link standardization from implementation compatibility and qualification.\n\n## The mechanism\n\nA package link connects separately manufactured logic regions through short wires and interfaces. A common standard can define electrical behavior, link training and supported protocols, but compatibility still depends on the selected package class, widths, rates and implementation options. UCIe’s public explanation describes negotiation of operating parameters during initialization. The physical link must also fit the package routing and power budget. A label saying UCIe therefore identifies a framework for interoperability rather than proving that any two purchased chiplets can be assembled together without additional design and qualification work.\n\n1.  Choose compatible package and electrical options before committing bump locations.\n2.  Match protocol support and the meaning of data, control and error responses.\n3.  Train the link and negotiate the supported operating parameters.\n4.  Verify routing losses, timing and supply noise over intended conditions.\n5.  Qualify the integrated package rather than inferring compatibility from individual component labels.\n\n## Science and assumptions\n\n### Usable link rate\n\n$$\nB_{\\mathrm{useful}}=\\frac{N_{\\mathrm{lane}}r\\eta}{8}\n$$\n\nUsable directional link rate is lane count times effective per-lane bit rate times payload efficiency divided by eight.\n\nSymbols and units\n\nB\\_useful\n\nUsable link payload rate in the stated direction\n\nbytes/s\n\nN\\_lane\n\nActive lane count\n\nlanes\n\nr\n\nEffective bit rate per lane\n\nbits/(s·lane)\n\nη\n\nFraction carrying the selected payload\n\nfraction\n\n8\n\nBits per byte\n\nbits/byte\n\nNlane is lane count, r effective bits/s per lane and η payload efficiency; Buseful is bytes/s in the stated direction.\n\nAssumptions No lane double-counting; bidirectional aggregate rates require a separate label.\n\n## Engineering example\n\nSynthetic interface: 16 lanes at 8 Gbit/s with 80% payload efficiency yield 12.8 GB/s one way. Summing the reverse direction would describe a different aggregate metric.\n\n## Distinctions and tradeoffs\n\nA shared interface name is necessary evidence of a common framework, not sufficient proof of a qualified product combination.\n\nStandardized interfaces improve reuse but reserve area, power and routing that a highly specialized link may optimize differently.\n\nChiplet-based accelerators depend on reliable data exchange before their separate arithmetic and memory resources form a useful device.\n\n## Specifications and interfaces\n\nCompatibility levels\n\nPhysical, link and protocol\n\nAgreement is required at every implemented layer.\n\nBandwidth density\n\nBytes/s per edge length\n\nSpecify the direction and usable interface edge in a comparison.\n\n### Interfaces\n\nChiplet transmitter Input\n\nEncoded data and link-control information\n\nChiplet receiver Output\n\nValidated data delivered to the supported protocol\n\n## Check your understanding\n\n### What must match beyond a connector or standard name?\n\n1.  Physical options and supported protocol behavior\n2.  Only the marketing color\n3.  Only the total transistor count\n\nAnswer and reasoning\n\nPhysical options and supported protocol behavior\n\nElectrical and logical compatibility must coexist with package routing and operating margins.\n\n## Evidence and scope\n\nThe example does not claim a UCIe configuration. Public initialization guidance supplies the mechanism; vendor interoperability test results remain configuration-specific.\n\nUse the manufacturing investigation to trace compatible inputs, assembly and operating constraints; no current standalone calculator models this lesson’s full mechanism.\n\n## Sources\n\n-   [Introduction to UCIe webinar: Q&A recap](https://www.uciexpress.org/post/introduction-to-ucie-webinar-q-a-recap)\n\n[Published lesson data](https://semiaifoundry.com/ai-atlas/lesson-data/die-link-compatibility-e2fb037f49d24af9.json) · [Atlas releases and licensing](https://semiaifoundry.com/ai-atlas/licenses.html)\n\n## Continue exploring\n\n### Foundations\n\n-   [Interposer and redistribution layers](https://semiaifoundry.com/learn/atlas/interposer/)\n-   [Package substrate](https://semiaifoundry.com/learn/atlas/package-substrate/)\n\n### Related lessons\n\n-   [Signal integrity, timing and the eye diagram](https://semiaifoundry.com/learn/atlas/interface-signal-eye/)"
}