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 Maps and Address Decode
  1. Topics
  2. SoC Design
  3. Memory Maps and Address Decode
  4. Memory-Map Verification

Part 3 of 14Part 3 of 14/Memory Maps and Address DecodeAll levels

Memory-Map Verification

Sweeps, reset and access-type checks, safe probing, and the regression suite built from the planted bugs.

  • 3topics
  • 3lessons

Everything in this section so far is a claim; this topic is where the claims are tested. Map verification is deliberately unglamorous: sweep every region and every hole, read every register back at reset, exercise every access type, probe the aliases in a controlled test mode, and then freeze the four planted bugs into regression tests so they can never come back. NanoSoC is the ideal size for it, the whole matrix fits in a few dozen directed accesses. The general strategy of what to verify where lives in the verification courses; here the scope is the map, tested the way a chip team actually signs one off. See also Security Verification for the strategy this topic executes.

Lesson

After it you can...

Address and Register Sweeps

Predict every probe answer from the map and check reset values and access types.

Alias, Hole and Connectivity Checks

Prove the alias is the only alias and every select reaches a responder.

Planted Bugs and Regression Hooks

Turn four named bugs into permanent regression tests with sign-off criteria.

Suggested order: top to bottom. Sweeps establish the expected answers, probing hunts for the unexpected ones, and the planted bugs convert surprises into permanent guards.

Check yourself Why verify the map at chip level when every block was already tested alone?

Because the failures live between blocks: a wrong base in the decode, a miswired address bit, a responder nobody instantiated. Block tests cannot see a wiring error by construction; only an addressed access from a master can.

Expect to list the top-level map tests unprompted: sweeps, reset readback, access types, alias and hole probes, connectivity, and the regression set. This topic is that answer with the addresses filled in.

PreviousNext: Address and Register Sweeps

Up next

Up nextAddress and Register Sweeps

Sign in to save progress

Practice this lessonPrevious lessonReport an error

See also

  • Designing the Address Map
  • Implementing Address Decode
  • Decode Errors and Default Slaves