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
    • SoC Verification Strategy
      • Levels and What Only the Chip Can Show
      • The NanoSoC Top-Level Test List
      • Reuse, Regression and Signoff Evidence
    • Integration and Connectivity Tests
    • Firmware Co-Simulation
    • Performance Verification
    • Gate-Level and Power-Aware Simulation
    • Emulation and FPGA Prototyping
    • Bring-Up Readiness
  • Package, Pads and I/O18
  • Chip Signoff and Tapeout18
  • SoC Interview Prep16
  • Capstone: Integrate NanoSoC14
Loading lesson

←SoC Verification Strategy
  1. Topics
  2. SoC Design
  3. Top-Level Verification and Bring-up
  4. SoC Verification Strategy
  5. The NanoSoC Top-Level Test List
On this page

    Part 10 of 14, lesson 2 of 21Part 10 of 14/Top-Level Verification and Bring-up/Lesson 2 of 21All levels

    The NanoSoC Top-Level Test List

    The concrete chip-level tests for NanoSoC, grouped by risk, each mapped to the planted bug it would catch.

    Why it matters

    Strategy without a list is a wish. The integrator's test list is short enough to memorise and complete enough that every planted bug trips at least one entry. Its one job is that list: ten groups, each with a stated target and a named bug it catches, ordered so the cheapest tests run first and the expensive ones earn their keep.

    The core idea

    The list runs in risk order, cheapest first. Connectivity proves the wires: one forced toggle per interrupt into the RAW register, one read per reset value, one write per clock enable. The memory-map sweep proves the decoders: one access per region, one per hole with the expected DECERR or SLVERR, one alias pair proving the DMA repeats sixteen times. Register sweeps prove reset values and access types against the register tables, including the DMA traps: LEN and KEY silently ignored while BUSY, ERR sticky across GO, CTRL bit 1 rewriting IRQ_EN on every write. Boot to banner proves the ROM flow end to end, with a bench monitor timestamping each stage (the ROM itself prints only the banner). Interrupt end to end proves each source raises irq_cpu and the handler clears it, with the DMA job as the flagship. The DMA stream proves a 64-word job in 72 system clocks with the checksum compared. Power-state walk proves SLEEP entry and wake with retention. Reset-order proves the staged release and the software-reset scope. Security proves secure-only regions reject non-secure access, and that non-secure software cannot make the SBR issue secure accesses. The second check fails on NanoSoC v1: the SBR slot is non-secure and its NS bit is writable, so the partition is not closed until the bit is made secure-writable. Performance proves the bandwidth and latency table, which has its own topic.

    Group

    Target

    Planted bug it catches

    Connectivity

    Each interrupt to its RAW bit, clocks to toggles

    Bug 3 (wrong input); bug 5 (unsynchronised crossing) is caught by the structural CDC check, not by simulation

    Map sweep

    Regions answer, holes error, alias repeats

    Bug 1 (overlap), alias A1 misuse

    Register sweep

    Reset values, W1C, BUSY rules

    Bug 4 (byte offsets), bug 9 (sticky ERR, CTRL trap)

    Boot to banner and jump

    Reset vector to the jump at 12.581 ms

    Bug 2 (reset order)

    Interrupt end to end

    Source to handler to clear

    Bug 3, and a source pulse shorter than 83.3 ns that the controller can miss

    DMA stream

    64 words, DONE, checksum, 750 ns

    Bug 7 (NS default), bug 8 (LEN mismatch)

    Power walk

    SLEEP, isolation, wake, retention, CLK_EN gating

    Bug 6 (missing isolation), bug 10 (clock gated during an access)

    Reset order

    Staged release, SW scope

    Bug 2, and a software reset that touches the wrong nets

    Security

    Secure-only rejects non-secure; NS bit not writable by non-secure code

    Bug 7, and the known SBR weakness (below)

    Performance

    Budgets in the bandwidth and latency table

    The same-bank trap (361.4 to 180.7 MB/s each)

    Diagram
    # not-run: ordering arithmetic, NanoSoC teaching values
    # Cheapest-first order keeps debug cheap: connectivity and map sweeps run in
    # milliseconds of simulated time and catch wiring bugs before the 12.581 ms
    # boot test ever runs. A wiring bug found by boot costs the whole boot per
    # iteration; found by sweep it costs one register access (a CPU read of a DMA or SBR register takes 125 ns; a clk_per register such as INTC RAW takes 281.25 ns).

    What the review looks for

    • Every planted bug names at least one group above; every group names at least one bug or budget it guards.

    • The boot test asserts the 12.581 ms total and the 86.9 percent SPI share, so a slowdown points at its stage.

    • Security tests touch both directions: secure may enter SRAM1 and RSTPWR, non-secure must be refused with an error response (SLVERR for SRAM1). One test is expected to fail until the SBR weakness is fixed, and it stays in the list as a named open item.

    Verify and debug

    Run the list top to bottom on every integration change: stop at the first red group, because a connectivity failure explains most boot failures and a map failure explains most driver failures. Keep each group independent so a power-walk failure never blocks the register sweep; independence is what makes the list bisectable. For the method behind software-driven chip tests see the co-verification lesson linked below.

    CPU released with the fabric (planted bug 2): the boot test hangs at PC = 0x0000_0000 with ARVALID high and no RVALID, and the first instinct is to debug the ROM image. Stop-at-first-red points elsewhere: the reset-order group fails first, and its assertion that rst_cpu_n never rises before rst_sys_n names the cause in one run. The fix is the 8 clk_sys plus 2 clk_cpu gap after rst_sys_n.

    If asked to plan top-level verification on a whiteboard, write these ten groups, map two bugs to each from memory, and state the stop-at-first-red rule. That is the whole answer.

    Check yourself Which groups catch the most planted bugs, and why do they run first?

    Connectivity, map and register sweeps: bugs 1, 3, 4 and 9 are wiring, decode or register-contract facts, and each costs a handful of register accesses (125 ns for a DMA or SBR register, 281.25 ns for a clk_per register) instead of a full 12.581 ms boot.

    Related topics

    • Levels and What Only the Chip Can Show

    • Next: Reuse, Regression and Signoff Evidence

    • Chip Signoff: Tapeout Readiness Review

    • Verification First Principles: Hardware-Software Co-Verification

    Previous

    191 / 289

    Next: Reuse, Regression and Signoff Evidence

    Up next

    Up nextReuse, Regression and Signoff Evidence

    Sign in to save progress

    Practice this lessonPrevious lessonReport an error