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
    • Designing the Address Map
    • Implementing Address Decode
    • Decode Errors and Default Slaves
    • Register Maps and Banks
    • Security and Privilege Regions
    • The Software View and the Hardware-Software Contract
    • IP-XACT and Automated Assembly
    • Memory-Map Verification
      • Address and Register Sweeps
      • Alias, Hole and Connectivity Checks
      • Planted Bugs and Regression Hooks
  • 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
  • SoC Interview Prep16
  • Capstone: Integrate NanoSoC14
Loading lesson

←Memory-Map Verification
  1. Topics
  2. SoC Design
  3. Memory Maps and Address Decode
  4. Memory-Map Verification
  5. Planted Bugs and Regression Hooks
On this page

    Part 3 of 14, lesson 26 of 26Part 3 of 14/Memory Maps and Address Decode/Lesson 26 of 26All levels

    Planted Bugs and Regression Hooks

    Four named NanoSoC bugs, the test that catches each, and the hooks that keep them caught forever.

    Why it matters

    A bug found once and fixed is a cost; the same bug found twice is a process failure. Regression hooks are how a map team converts the first kind into immunity: every decoded failure becomes a named, permanent test that runs on every change to the map, the decode or the wiring. This lesson takes four of the planted bugs, states the catching test for each, and closes the section with the sign-off criteria for the map as a whole.

    The four bugs and their catches

    Bug 1, the 8 KB decode window, let a write to SBR CTRL also write DMA KEY because the DMA slot select covered two slots. Its catch is a cross-talk test: write a known pattern to every register of each APB slot that has no side effect, then read back every register of every other slot and assert nothing moved. Writes with side effects are excluded by a list marked in the register table: the reset controller's SWRST (it resets the chip) and PWR_CTRL (it requests power-down), CLK_EN (clearing a bit gates a block and the next access to it hangs), DMA CTRL GO and SBR CTRL START (they start jobs). Bug 4, the byte-versus-word wiring, connected the DMA's paddr to apb_paddr bits 9 down to 2, so only offset zero survived and a COUNT read returned STATUS with no error. Its catches are the offset walk, one front-door access per implemented offset, and the bit-level connectivity rule that paddr bit i is driven by apb_paddr bit i. Bug 7, the bridge resetting as non-secure, made copies out of SRAM1 fail on the first beat while CPU reads passed; its catch is one transfer per master per region class in the access-control matrix, with the bridge present in both of its states.

    Bug

    Symptom signature

    Catching test

    Hook

    1: 8 KB window

    SBR writes corrupt DMA KEY (offset 0x0C collision)

    Cross-talk: write slot N, read back all other slots

    Runs on every decoder change

    4: paddr from [9:2]

    Only DMA CTRL answers; the rest PSLVERR

    Offset walk plus bit-i-from-bit-i connectivity

    Runs on every wiring change

    7: SBR NS reset

    SRAM1 copies ERR at beat one; CPU reads fine

    Master-by-region matrix, bridge in both states

    Runs on every map change

    9: contract traps

    Stale KEY, stuck interrupt, disarmed IRQ_EN

    The three driver-rule tests of the errata list

    Runs on every driver release

    Bug 9 is the odd one out and deliberately so: the hardware behaves as specified, and the regression lives in the driver rules. Its three tests are the errata entries written as code: reprogram without polling BUSY and observe the stale configuration, finish a failed then a good job and observe the stuck interrupt until STATUS is written with 0x6, and start with CTRL written as 0x1 and observe the missing completion interrupt until the rule of writing 0x3 is applied. Each test fails without its rule and passes with it, which is what keeps a workaround honest across releases. Together the four hooks cover the four layers of the section: decode, wiring, security and contract, one named test per layer per bug.

    Regression hooks and sign-off

    A hook is a test plus a trigger: the condition under which it must run. The triggers above are the discipline, because a test that runs only when somebody remembers protects nothing. The map sign-off then reduces to a checklist the review can actually audit: the map checker clean on the current table, the register-specification checker clean, sweeps and reset readback passing in simulation, alias count exact with connectivity clean, the access-control matrix complete and passing, and the four regression hooks green on the final generated artifacts, all quoted against one map version. Anything failing is either fixed or becomes an erratum with a workaround, which is the errata lesson's process doing its job.

    What the review looks for

    • Each planted bug has a named regression test and a stated trigger; the test fails when the bug is reintroduced, which is itself tested by mutation.

    • Sign-off quotes one map version across all artifacts, with checker and sweep outputs archived, not summarised.

    • New bugs found after sign-off enter the same pipeline: erratum first, regression test second, fix third.

    Verify and debug

    Mutation-check the hooks once: reintroduce each bug in a scratch build (widen the select, rewire paddr, set the bridge state, break a driver rule) and confirm exactly its test fails while the others pass. A hook that fails for every mutation is too coarse to localise; a hook that fails for none is decoration. Keep the mutation results with the sign-off pack, so the reviewer inherits evidence rather than assurances.

    A regression suite that only runs at milestones, so a decode change lands, three weeks of work build on it, and the hook fails when nobody remembers the context. Hooks run on the change that can break them: decoder, wiring, map table or driver, respectively.

    If asked how you stop a fixed bug returning, answer with hooks and triggers: named test, named change class, mutation-checked once. Then recite the four NanoSoC examples, one per layer, as proof the method is concrete rather than process talk.

    Check yourself A fifth bug is found after sign-off: a second alias inside the UART slot. What happens process-wise before the fix ships?

    It becomes an erratum entry with symptom, cause, revisions and a driver-facing rule if one exists; a new alias-count or cross-talk regression hook is added with the wiring-change trigger; only then does the fix land, verified by the new hook failing on the old artifacts and passing on the new.

    Related topics

    • Alias, Hole and Connectivity Checks

    • Errata and Software Workarounds

    • Sizes, Alignment and Power-of-Two Windows

    Previous

    71 / 289

    Next: Ordering and Deadlock at the Top

    Up next

    Up nextOrdering and Deadlock at the Top

    Sign in to save progress

    Practice this lessonPrevious lessonReport an error

    See also

    • Address and Register Sweeps