Skip to content
DenseChip
Learn
PracticeCode labInterview

DenseChip

Navigate

Menu

LearnPracticeCode labInterview

Tools

All toolsSV editorCode repoResume
DenseChip

Practice, courses, and chip-design tools in one focused workspace.

LearnPracticeCode labInterviewToolsLearning paths

© 2026 DenseChip

AboutRoadmapCareersInternshipsFAQContactPrivacyTerms
Skip to lesson

Course contents

  • How to Use This Course
  • The NanoSoC Tour
  • Reading Path
  • SoC Glossary10
  • SoC Metrics Reference
  • SoC Cheatsheet
  • What SoC Integration Is12
  • Architecture and Budgets21
  • Memory Maps and Address Decode26
  • Interconnect and Bus Fabrics26
  • Clock and Reset Architecture24
  • Power Architecture21
  • Interrupts, DMA and Peripherals15
  • Memories, Boot and Security21
  • IP Integration and Handoff21
  • Top-Level Verification and Bring-up21
  • Package, Pads and I/O18
  • Chip Signoff and Tapeout18
    • The Signoff Manifest
    • Waiver Governance
    • Closure Dashboards
    • Tapeout Readiness Review
    • ECO and Respin Risk
    • Errata and Post-Silicon
      • From Bug to Erratum
      • Workarounds That Hold
      • The Loop to the Next Chip
  • SoC Interview Prep16
  • Capstone: Integrate NanoSoC14
Loading lesson

←Errata and Post-Silicon
  1. Topics
  2. SoC Design
  3. Chip Signoff and Tapeout
  4. Errata and Post-Silicon
  5. The Loop to the Next Chip
On this page

    Part 12 of 14, lesson 18 of 18Part 12 of 14/Chip Signoff and Tapeout/Lesson 18 of 18All levels

    The Loop to the Next Chip

    Turning errata into prevention: design rules, checklist rows and verification tests the next chip inherits.

    Why it matters

    An erratum that changes nothing is tuition unpaid: the next chip repeats the bug, pays the workaround cost again, and adds its own entries beside it. The loop closes only when each erratum becomes a rule the next chip cannot forget: a design requirement, a checklist row, or a verification test that fails if the bug returns. This lesson runs the loop for the NanoSoC errata and states what the next chip inherits. Its one job is the feedback; it closes the section and the course's signoff story.

    The core idea

    Each erratum maps to one of three inheritances. Design rules change the RTL contract: every new status register uses set-wins write-1-to-clear, every control write preserves unrelated enables, every job-start clears all terminal flags. Checklist rows change the integration review: the driver-rule audit joins the evidence matrix, the spare-select tie-off audit joins the ECO review, the errata sheet ships with the headers. Verification tests change the regression: the error-then-success sequence, the clear-against-event race, and the start-while-busy case become permanent top-level tests that fail if the behaviour returns. The script below counts the NanoSoC loop: four sources (ERR-001, ERR-004, the clear-versus-set race and the gated-clock hang) converted into seven inherited items, three rules, two tests and two checklist rows, none left as prose advice.

    example.py
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    # The feedback loop: every erratum becomes a rule, a test or a
    # checklist row, each with an owner. Items are illustrative.
    errata = ["ERR-001", "ERR-004"]
    loop = [  # source, kind, what the next chip inherits, owner
        ("ERR-001", "checklist", "driver-rule audit in evidence matrix", "integrator"),
        ("ERR-004", "rule", "job-start clears all terminal flags", "rtl owner"),
        ("ERR-004", "test", "error-then-success sequence permanent", "verification owner"),
        ("ERR-004", "rule", "control writes preserve enables", "rtl owner"),
        ("W1C-race", "rule", "set-wins W1C on all new status bits", "rtl owner"),
        ("W1C-race", "test", "clear-against-event race test", "verification owner"),
        ("gated-clock", "checklist", "bridge-watchdog and busy-guard proof with every gating change", "integrator"),
    ]
    
    def audit(loop, errata):
        bad = []
        for src, kind, text, owner in loop:
            if kind not in ("rule", "test", "checklist"):
                bad.append((src, "kind"))
            if not owner:
                bad.append((src, "no owner"))
        sources = {item[0] for item in loop}
        for e in errata:
            if e not in sources:
                bad.append((e, "never inherited"))
        return bad
    
    assert audit(loop, errata) == []
    count = {k: sum(1 for item in loop if item[1] == k)
             for k in ("rule", "test", "checklist")}
    assert count == {"rule": 3, "test": 2, "checklist": 2}, count
    assert len(loop) == 7
    # the audit must be able to fail: an unowned item and an unlooped erratum
    assert audit(loop + [("ERR-004", "rule", "x", "")], errata) == [("ERR-004", "no owner")]
    assert audit(loop, errata + ["ERR-007"]) == [("ERR-007", "never inherited")]
    print("PASS: 7 inherited items, 3 rules, 2 tests, 2 checklist rows, every erratum covered")

    What the review looks for

    • The next chip's plan quotes the inherited items by identifier: which rules, which tests, which rows.

    • No erratum closes with prose advice alone: advice without an owner and a test is a wish.

    • The escape-rate table improves because the granting bar references these rules, not because the count was reset.

    Verify and debug

    At the next chip's first integration review, run the inherited tests against the new RTL before anything else: they are the cheapest failures the project will ever find. Any inherited test that cannot run on the new design is itself an erratum in the loop, and gets a rule that tests stay portable. The memory-map contract lessons carry the same message for headers and decode.

    Diagram
    # not-run: the loop card pinned to the next kickoff wall
    every erratum -> one rule, one test, or one checklist row, with an owner
    ERR-004 -> start clears all flags; error-then-success test permanent
    W1C-race    -> set-wins W1C everywhere; clear-against-event test permanent
    gated-clock -> bridge-watchdog and busy-guard proof with every clock-gating change

    Silently ignored writes and sticky error state are the repeated offenders: exactly the class that returns when the loop is prose. The rule that control writes preserve enables and the permanent error-then-success test are what stop the next DMA from relearning it.

    If asked what the next chip learns from this one, answer with the counts: seven items, three rules, two tests, two checklist rows, each with an owner. Then offer one example end to end: the sticky flag to the set-wins rule to the race test.

    Check yourself An erratum's fix is planned as an ECO on this chip. Does it still enter the loop?

    Yes: the ECO fixes this chip, while the rule, test or row stops the next one. The silicon plan and the loop entry are different fields, and both must be filled.

    Related topics

    • Workarounds That Hold

    • Verification: Observability in Silicon

    • Hardware Debug: Escape Analysis

    Previous

    249 / 289

    Next: The Whiteboard Framework

    Up next

    Up nextThe Whiteboard Framework

    Sign in to save progress

    Practice this lessonPrevious lessonReport an error

    See also

    • From Bug to Erratum