{
  "schemaVersion": 1,
  "id": "atlas-lesson-chip-rtl-verification",
  "title": "RTL and functional verification",
  "category": "learning",
  "format": "Atlas lesson",
  "description": "Checks that a cycle-based design obeys its specification before manufacture.",
  "canonicalUrl": "https://semiaifoundry.com/learn/atlas/chip-rtl-verification/",
  "publishedDate": null,
  "revisionDate": "2026-10-07",
  "author": null,
  "topic": "Custom silicon ecosystem",
  "series": null,
  "license": null,
  "rightsUrl": "https://semiaifoundry.com/ai-atlas/licenses.html",
  "version": "1.3.0",
  "status": "Published educational lesson",
  "evidenceScope": "OpenTitan is a methodology example, not an AI accelerator design. Proprietary test coverage and signoff criteria are unknown and are not invented.",
  "contentCoverage": "published-lesson",
  "artifactUrl": "https://semiaifoundry.com/ai-atlas/lesson-data/chip-rtl-verification-a059c32d0e186ea1.json",
  "interactiveUrl": "https://semiaifoundry.com/ai-atlas/#chip-rtl-verification",
  "related": [],
  "supersedes": [],
  "supersededBy": [],
  "contentHash": "9466d12df66133e6e56d1ebc60fd70f745b2d0b22b66bf3add8172243bbf9086",
  "contentLength": 4955,
  "jsonUrl": "https://semiaifoundry.com/agents/publications/atlas-lesson-chip-rtl-verification.json",
  "markdownUrl": "https://semiaifoundry.com/agents/publications/atlas-lesson-chip-rtl-verification.md",
  "sections": [
    {
      "id": "section-1",
      "title": "RTL and functional verification",
      "start": 41,
      "end": 413
    },
    {
      "id": "section-2",
      "title": "The mechanism",
      "start": 413,
      "end": 1683
    },
    {
      "id": "section-3",
      "title": "Science and assumptions",
      "start": 1683,
      "end": 1711
    },
    {
      "id": "section-4",
      "title": "State-space growth",
      "start": 1711,
      "end": 2242
    },
    {
      "id": "section-5",
      "title": "Engineering example",
      "start": 2242,
      "end": 2470
    },
    {
      "id": "section-6",
      "title": "Distinctions and tradeoffs",
      "start": 2470,
      "end": 2943
    },
    {
      "id": "section-7",
      "title": "Specifications and interfaces",
      "start": 2943,
      "end": 3231
    },
    {
      "id": "section-8",
      "title": "Interfaces",
      "start": 3231,
      "end": 3433
    },
    {
      "id": "section-9",
      "title": "Check your understanding",
      "start": 3433,
      "end": 3462
    },
    {
      "id": "section-10",
      "title": "What makes a test useful for a hardware handshake?",
      "start": 3462,
      "end": 3895
    },
    {
      "id": "section-11",
      "title": "Evidence and scope",
      "start": 3895,
      "end": 4237
    },
    {
      "id": "section-12",
      "title": "Sources",
      "start": 4237,
      "end": 4593
    },
    {
      "id": "section-13",
      "title": "Continue exploring",
      "start": 4593,
      "end": 4616
    },
    {
      "id": "section-14",
      "title": "Foundations",
      "start": 4616,
      "end": 4830
    },
    {
      "id": "section-15",
      "title": "Related lessons",
      "start": 4830,
      "end": 4955
    }
  ],
  "citations": [
    {
      "title": "Explore in Atlas",
      "url": "https://semiaifoundry.com/ai-atlas/#chip-rtl-verification"
    },
    {
      "title": "OpenTitan Verification Methodology, Earlgrey 1.0.0",
      "url": "https://opentitan.org/earlgrey_1.0.0/book/doc/contributing/dv/methodology/index.html"
    },
    {
      "title": "Published lesson data",
      "url": "https://semiaifoundry.com/ai-atlas/lesson-data/chip-rtl-verification-a059c32d0e186ea1.json"
    },
    {
      "title": "Atlas releases and licensing",
      "url": "https://semiaifoundry.com/ai-atlas/licenses.html"
    },
    {
      "title": "Edge-triggered D flip-flop",
      "url": "https://semiaifoundry.com/learn/atlas/flipflop/"
    },
    {
      "title": "Workload contract and architecture selection",
      "url": "https://semiaifoundry.com/learn/atlas/chip-workload-contract/"
    },
    {
      "title": "PDKs, synthesis and physical closure",
      "url": "https://semiaifoundry.com/learn/atlas/chip-physical-closure/"
    }
  ],
  "recordHash": "360ee2d68162f6958b9e2b2ecb7665c9f0894c7ce2fc4baeffe4e7f6e375fe62",
  "contentFormat": "text/markdown",
  "content": "Custom silicon ecosystem · Atlas v1.3.0\n\n# RTL and functional verification\n\nChecks that a cycle-based design obeys its specification before manufacture.\n\n[Explore in Atlas](https://semiaifoundry.com/ai-atlas/#chip-rtl-verification)Design abstractions to manufactured package; not one physical scale\n\nLearning objectiveExplain how simulation, assertions, formal checks and coverage contribute different evidence.\n\n## The mechanism\n\nRegister-transfer level code describes how state changes and data moves between registers. Simulation executes that description under selected stimulus; assertions and formal methods test properties under stated assumptions. Coverage asks whether planned situations were exercised, not whether every possible bug has been excluded. An accelerator needs arithmetic checks as well as reset, backpressure, ordering, error and clock-domain behavior. OpenTitan supplies a public example of staged verification planning, reusable test environments and regression evidence. Verification must also cover integrated IP boundaries, because individually correct blocks can disagree about protocols or the meaning of a completed operation.\n\n1.  Write a test plan from externally meaningful requirements, including illegal inputs and recovery behavior.\n2.  Construct reference models for arithmetic and protocol state that can detect implementation disagreement.\n3.  Drive simulation with directed corner cases and constrained randomized sequences.\n4.  Use assertions or formal checks for invariants such as no buffer overwrite before consumption.\n5.  Review failures and coverage gaps, then repeat regressions after integration changes and before stage approval.\n\n## Science and assumptions\n\n### State-space growth\n\n$$\nN_{\\mathrm{states}}=2^b\n$$\n\nThe configuration space of b independent binary state bits contains two to the power b states.\n\nSymbols and units\n\nN\\_states\n\nPossible configurations of b independent state bits\n\nstates\n\nb\n\nIndependent binary state-bit count\n\nbits\n\nb is the number of independent state bits and Nstates is a count. Even modest state creates a large space of possible configurations.\n\nAssumptions A crude upper bound; constraints and abstraction reduce reachable states but must be justified.\n\n## Engineering example\n\nSynthetic FIFO property: after a valid item is accepted, it must emerge once in order unless reset explicitly cancels it. A test that pauses the consumer reveals bugs hidden by continuous ready signals.\n\n## Distinctions and tradeoffs\n\nPassing simulation does not prove all states correct; high coverage does not excuse a missing requirement or an invalid formal assumption.\n\nExhaustive state exploration grows rapidly; engineers combine abstraction, constrained stimulus, formal properties and targeted tests rather than trusting one technique.\n\nA rare deadlock or wrong accumulator rounding can corrupt long training runs even if the common matrix benchmark appears correct.\n\n## Specifications and interfaces\n\nVerification target\n\nSpecification and interface properties\n\nTests require an expected behavior independent of the implementation.\n\nCoverage\n\nEvidence of exercised scenarios\n\nCode or functional coverage is not a mathematical probability of correctness.\n\n### Interfaces\n\nArchitecture specification Input\n\nCycle behavior, numerical rules and protocol contracts\n\nVerification evidence Output\n\nAssertions, regression results, coverage and unresolved failures\n\n## Check your understanding\n\n### What makes a test useful for a hardware handshake?\n\n1.  It checks behavior under backpressure and reset against a protocol rule\n2.  It repeats the RTL calculation verbatim\n3.  It only counts how often valid is high\n\nAnswer and reasoning\n\nIt checks behavior under backpressure and reset against a protocol rule\n\nA handshake’s correctness depends on timing and ownership under difficult conditions, not merely exercising signals.\n\n## Evidence and scope\n\nOpenTitan is a methodology example, not an AI accelerator design. Proprietary test coverage and signoff criteria are unknown and are not invented.\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-   [OpenTitan Verification Methodology, Earlgrey 1.0.0](https://opentitan.org/earlgrey_1.0.0/book/doc/contributing/dv/methodology/index.html)\n\n[Published lesson data](https://semiaifoundry.com/ai-atlas/lesson-data/chip-rtl-verification-a059c32d0e186ea1.json) · [Atlas releases and licensing](https://semiaifoundry.com/ai-atlas/licenses.html)\n\n## Continue exploring\n\n### Foundations\n\n-   [Edge-triggered D flip-flop](https://semiaifoundry.com/learn/atlas/flipflop/)\n-   [Workload contract and architecture selection](https://semiaifoundry.com/learn/atlas/chip-workload-contract/)\n\n### Related lessons\n\n-   [PDKs, synthesis and physical closure](https://semiaifoundry.com/learn/atlas/chip-physical-closure/)"
}