An SoC-level verification strategy is the plan for showing that the integrated chip works, not just each of its blocks. Each IP block may be thoroughly verified on its own, yet the chip can still fail: a wire connected to the wrong port, an address map that overlaps, an interrupt routed nowhere, two blocks that each follow the protocol but disagree about the order of a reset. These bugs only appear when the blocks run together, and they are expensive, since a chip that doesn't boot can't even be debugged. This article explains what SoC-level verification must find, the layers of a strategy, how tests that run software on the processor work, and how the team decides it has done enough.
11 min read | Intermediate
What You'll Learn
- Identify the kinds of bugs that only appear at SoC level
- Describe the layers of SoC verification and what each catches
- Explain how software-driven tests and connectivity checks work
- Plan regressions, coverage and sign-off criteria for an SoC
What SoC-Level Verification Must Find
Block verification answers "does this block meet its spec". SoC-level verification answers different questions:
- Is everything connected correctly: every port, clock, reset and interrupt line?
- Does the address map match the spec, with every register reachable from every manager that should reach it, and unreachable from those that shouldn't?
- Do blocks work together: a DMA transfer from a peripheral to memory, an interrupt waking a sleeping core?
- Does the chip boot, through every boot mode?
- Do the system-wide features work: power domains, clock changes, resets, security rules?
- Does the chip meet its performance targets under realistic traffic?
It does not repeat block verification. Running a block's full set of tests again at SoC level would be far slower and would find little, since the block was already checked. The strategy relies on the blocks being verified, and tests the joins between them.
Layers of Verification
Bugs are caught most cheaply where they are made, so verification is organized in layers, each slower and more expensive per bug than the one before.
Block-level verification tests each IP on its own, with full control of its inputs. Subsystem verification puts a few blocks together, such as a processor cluster with its caches and a small interconnect, and tests their interaction. Full-chip simulation runs the whole RTL, often with programs running on the real processor model. Connectivity and register checks confirm the wiring and the address map systematically. Emulation and FPGA prototypes run the design fast enough to boot an operating system, covered in FPGA Prototyping and Emulation. Finally, silicon validation tests the real chip.
The aim at each layer is to catch everything that layer can catch, so that the slower layers find only what genuinely needs them. A bug in a FIFO's full flag should never first appear when the operating system fails to boot in emulation, where finding it takes days.
Software-Driven Tests
At full-chip level, the most natural stimulus is software. Tests are written as small C programs, compiled for the chip's processor and loaded into its memory in simulation. The processor runs them exactly as it would on silicon: it programs a peripheral's registers, starts a transfer, waits for the interrupt, and checks the result. These tests exercise the real paths from the processor through the interconnect to each block, which is exactly what SoC verification needs.
Loading the program through the boot flow would take far too long in simulation, so the test environment usually writes the program directly into the memory model before the simulation starts, called backdoor loading. Boot ROM and the Boot Flow explains why separate tests then check the real boot path. A test reports pass or fail by writing to a special address that the test environment watches, since a simulated chip has no screen.
Software tests are combined with verification components outside the chip that drive and check its interfaces: a model of the external memory, a component that sends UART characters or network packets in and checks what comes out. The SoC Verification tutorial covers how such environments are built.
Quick Check
Q: Why are full-chip tests usually written as programs running on the processor, rather than by driving the bus directly from the test environment?
Show Answer
The processor's own accesses go through the real paths: its bus interface, the interconnect, the address decoders and the firewalls. Driving the bus directly would skip those paths, which are exactly what SoC-level tests must check. The same programs also become early versions of drivers and bring-up tests.
Connectivity and Register Checks
Many SoC bugs are wiring mistakes, and they are best found systematically rather than by hoping a test touches them. Top-Level Integration and Connectivity Checks showed how the top level is often generated from a description of the blocks and their connections. Connectivity checks compare the netlist against that description: every interrupt line reaches the right input of the interrupt controller, every clock and reset reaches the right block. Formal tools are well suited to this, because they prove each connection for all cases instead of simulating a few.
Register checks read and write every register in the address map from the processor, and check their reset values and access types. They are generated from the same register description that produces the documentation and the driver headers, as the software view of the chip requires, so a register that is missing or at the wrong address is found at once. They also check that protected registers can't be reached from managers that shouldn't reach them.
Scenario and System Tests
Beyond connectivity, tests exercise realistic scenarios: several blocks working at once, such as a camera writing frames through DMA while the processor reads them and the display scans out. These find bugs in arbitration, buffering and shared resources, and they check performance as well as function. Tests also cover system features, each with its own risks: entering and leaving every power state, changing the clock frequency during traffic, resetting one domain while others run, and the security rules, including the accesses that must be refused.
Randomization helps here: running the same scenario with random sizes, delays and orders finds corner cases that no one thought to write. Since a C program runs slowly in simulation, scenario tests are usually short, and the long, realistic workloads move to emulation.
Where Is This Used?
A large SoC project runs thousands of full-chip tests every night, on large compute farms, and tracks the pass rate daily. Teams keep a set of quick "smoke" tests that every change must pass before it is checked in, so that one engineer's mistake doesn't break everyone's work. Before tapeout, the operating system and real drivers are booted in emulation, and the same C tests are reused on the first silicon to bring it up.
The Verification Plan
All of this is written down in a verification plan: a list of every feature to verify, the method for each (simulation test, formal check, emulation, review), and how its completion is measured. The plan is built from the architecture spec, so that every requirement has a check. SoC Verification Planning in the SoC Verification tutorial covers how it is written.
Completion is measured with coverage. Code coverage shows which lines and branches of the RTL were exercised; at SoC level it mainly finds connections and modes that no test reached. Functional coverage records whether the scenarios in the plan actually happened: each power transition, each interrupt source, each boot mode. A test that passes without exercising its scenario, because a setting was wrong, shows up as a gap.
Quick Check
Q: Code coverage of the interrupt controller is 100 percent at SoC level. Why might functional coverage still show gaps?
Show Answer
Code coverage only says that every line ran. It doesn't say that every interrupt source was raised from its real device, at every priority, or while the core was asleep. Those scenarios are what functional coverage records.
Regressions and Sign-Off
Tests are run together as regressions, repeatedly, as the design changes. A failing test is debugged, the bug is fixed in the design or the test, and the regression runs again. The team tracks how many bugs are found each week. Early in the project, the rate is high; as the design matures, it falls. A falling rate is one of the signs that the design is ready, but not the only one, since it also falls when the team stops looking. So the team also checks that new kinds of tests are still being added, and that each recent bug was found by a test that targeted its area.
Sign-off criteria are agreed in advance: all planned features verified, coverage goals met with every gap explained, all regressions passing, no open serious bugs, and a review of what was waived and why. Tapeout Readiness and SoC Sign-Off puts these into the wider list of what must be true before a chip is manufactured.
Reusing Tests Across Layers
Writing tests is a large share of the effort, so good strategies write them once and run them in several places. A C test written for full-chip simulation can run unchanged in emulation, on an FPGA prototype, and on the first silicon, provided it reports its result in a way each platform can read and avoids depending on simulation-only shortcuts. Teams build a small library for this: functions to print a message, report pass or fail, and wait for a time, each implemented once per platform. When silicon arrives, a large set of tests is ready on the first day, and a failure on silicon can be rerun in simulation, where every signal is visible.
Debugging at SoC Level
A failing full-chip test is harder to debug than a failing block test. The symptom, such as a test that never finishes, may appear millions of cycles after the cause, in a different block. Good environments help by logging every transaction on the main interconnects, tracing the instructions the processor runs, and checking protocols with assertions at every interface, so that a bad transaction is flagged where it happens rather than when its effect is noticed. A failure is first reproduced with the same seed and settings, then narrowed to the first point where the behaviour differs from what was expected.
Common Mistakes
Mistake #1: Repeating block tests at SoC level
Block-level tests run slowly at full-chip level and find little. Focus SoC tests on connections, interactions and system features.
Mistake #2: Testing only the allowed accesses
Security and protection rules need tests that try forbidden accesses and check that they are refused.
Mistake #3: Relying on emulation to find simple bugs
A bug that a simulation test could find takes far longer to debug in emulation. Catch everything possible at the earlier, faster-to-debug layers.
Practice Exercise
Challenge: Plan the Tests for a New Peripheral
A new SPI controller is added to an SoC. It has registers, an interrupt, two DMA request lines and its own clock. The block itself has been verified. List the SoC-level checks you would add, and say for each one which layer of verification it belongs to.
Hint
Think about connections, the address map, interactions with other blocks, and system features such as clocks and power.
Solution
Connectivity (formal or generated check): interrupt to the right controller input, DMA requests to the right channels, clock and reset to the right sources. Register check (full-chip simulation): every register at its address with the right reset value and access type. Software test (full-chip simulation): program a transfer, receive the interrupt, check data through an external SPI model. Scenario test: a DMA-driven transfer while other traffic runs. System features: clock gating or a power state while idle, and wake-up afterwards. Emulation: the real driver running under the operating system.
Summary
- SoC verification checks connections, the address map, interactions between blocks and system-wide features, not each block again.
- Layers from block to silicon each catch what they can, so slower layers find only what needs them.
- Software tests run C programs on the real processor model, loaded by backdoor, with components checking the interfaces.
- Connectivity and register checks are generated from the same descriptions as the design, and formal tools prove the wiring.
- A verification plan, coverage, regressions and agreed sign-off criteria decide when the job is done.
