SoC Verification VS Traditional (UVM) verification

“But why can’t I just use our UVM testbench to verify SoC behavior?”

I often hear junior engineers or those who have not worked on SoC verification before, asking some variant of this question.

In this article, I attempt to very simplyexplain what exactly SoC verification is, how it differs from “standard” verification, and why using standard stimuli to do it would be suboptimal.

Let’s dive right in!

 

System-on-chip (SoC) verification is more than verifying a single IP block (like a standalone UART or PCIe controller). It focuses on the entire chip-level integration. This often requires a mix of hardware-oriented techniques (like traditional RTL testbenches in SystemVerilog) and firmware/software tests (often in C/C++).

IP vs SoC

Let’s look at the high-level difference between IP level and SoC level verification:

• IP Verification: You verify an individual component (e.g., a DMA controller) against its specification, typically using a testbench (e.g., UVM) with constrained random scenarios, checkers, scoreboards, etc.
• SoC Verification: You integrate multiple IP blocks (CPU cores, memories, accelerators, peripherals, interconnect, etc.) onto a single chip. You must ensure all these components work together correctly: system-level power management, security, bus protocols, interrupts, clock gating, multi-core concurrency, etc.

Because an SoC usually includes at least one CPU core (sometimes multiple), a large part of SoC verification involves running C testson the embedded CPU(s).

Instead of purely driving signals from a SystemVerilog testbench, you usually do the following:

1. Boot the SoC: Possibly load a bootloader or minimal OS image.
2. Run C test applications: These tests exercise the SoC’s functional features (e.g., configure DMA, trigger interrupts, test cache coherency).
3. Check Results: By reading internal registers or memory regions, comparing to expected outcomes, or printing logs to a UART console.

Why C Tests?

• At SoC level, many features only make sense once the CPU configures and uses the IP blocks.
• It mirrors real-world usage, where firmware or OS code drives hardware resources.

 

 

Below are some key points to illustrate why SoC-level testing differs from typical UVM block-level verification.

1) The CPU Itself Is Driving Most Transactions

At the Block/IP level:

In UVM, you have drivers (in SystemVerilog) that stimulate inputs and monitors that check outputs. You can do constrained-random tests or directed tests, and it’s straightforward because the IP under test doesn’t depend on a CPU’s register programming or firmware initialization.

At the SoC level:

The embedded CPU (or multiple CPUs) configures and drives the IP. For example, to start a DMA transfer, you typically:

• Boot the CPU.
• CPU configures the DMA engine by writing to control registers.
• CPU triggers a transfer.
• CPU might wait for an interrupt or poll a status register.

This flow is naturally expressed in C coderunning on the SoC’s CPU, rather than a UVM driver toggling signals.

2) Realistic Power and Reset Sequences

• SoC designs often have multiple voltage domains, power gating, clock gating, complex reset strategies, etc. The CPU or firmware might handle these transitions (e.g., instruct part of the SoC to go into low-power mode).
• A typical UVM testbench is not built to replicate such advanced power-state management. The methodology mostly focuses on transaction-level stimulus, scoreboards, and monitors around a powered, always-on IP block.
• In an SoC environment, you want to see if the firmware can properly enter/exit low-power states, re-initialize hardware, handle clock gating, etc.

3) Firmware / OS Integration

• Testing at the SoC levelis about “Does the system work when the real software is loaded?” not just “Can the IP respond to transactions?”
• If you rely solely on a UVM environment, you would have to replicate the entire OS/firmware initialization sequences in SystemVerilog drivers, which is complex and not very representative of real usage.

4) External vs. Internal Interfaces

• You might still use UVM to verify external interfaces at the SoC boundary (e.g., PCIe, USB, Ethernet). A UVM agent can generate high-level protocol traffic on the chip’s pins. Meanwhile, inside the SoC, the CPU runs firmware that configures the IP for each test mode.
• For example, you could have a UVM scoreboard that checks external traffic correctness, but the overall “test scenario” is triggered by embedded software. This is a hybrid approach—you don’t lose UVM entirely, but you rely on CPU-driven scenarios for configuration.

5) How They Complement Each Other

• Block-Level: UVM is perfect for verifying each IP or subsystem thoroughly before integration. You get constrained random coverage, corner-case exploration, checkers, etc.
• SoC-Level: Integrate IP blocks together. Use real (or near-real) firmware to configure them. Possibly combine UVM transactors for external I/O (Ethernet, PCIe, etc.).Focus on system-level behaviors (power states, security, concurrency, interrupts, OS boot, etc.).

SoC verification uses more software-centric testing, but that doesn’t mean you can’t use UVM. You just rarely build a top-level UVM environment to replicate the CPU’s role. Instead, you let an actual CPU model + C code handle that. UVM may remain in the picture to handle external interfaces, check coverage, or coordinate with the embedded software in a co-simulation environment.

 

Key Differences from “Typical” RTL Verification

• CPU-Driven Testing: Instead of a UVM driver sending stimuli to a bus, the on-chip CPU sets up and triggers the IP, like it would in real usage.
• Bigger Focus on System Use-Cases: E.g., “Stream data from Ethernet to memory via DMA while CPU toggles power states.”
• Complexity of Integration: Many corner cases come from how IPs interact.
• Performance & Power often matter, not just functional correctness.
• Firmware skill sets: SoC verification engineers often write or modify C code, handle cross-compilation, and debug code running on the SoC.

Final words

You could build a purely UVM test that tries to mimic or replicate SoC CPU behavior by writing drivers that do register writes, sequences that handle interrupts, etc. But that’s very tedious, less realistic, and doesn’t represent the real firmware flow. Most SoC verification teams go for:

1. Firmware-based testing for the CPU and internal subsystem interactions.
2. UVM-based testbench (or partial UVM methods) for external interfaces or for specialized debugging/monitoring.

Hence, SoC verification relies heavily on embedded C tests to cover real usage scenarios, whereas block/IP-level verification is typically pure UVM for deep protocol-level coverage.