Key Areas to consider during SOC Verification

Design size keeps doubling roughly every two years, in line with Moore’s observation about transistor counts. Chip makers pack more functions and features into each SoC to win market share, and every new feature adds verification effort. The costliest event for a chip company is a respin caused by a functional bug. That pressure means teams must verify complex designs in less time, which calls for a clear plan of what to check and an efficient method. This post covers the key areas to consider during SoC verification and how to work through them.

A simple way to picture it

Think of building a house from rooms that were each inspected at the factory. The plumber already tested the bathroom pod, the electrician tested the wiring loom, and so on. When the rooms arrive on site, you do not re-test each tap. Instead you check the connections: does water reach every room, do the light switches control the right lights, does the front door key work, and does everything still run when you flip the main breaker off and on. SoC verification is that connection check for a chip. The blocks are trusted; the joins between them are where you look hardest.

SoC verification versus IP verification: what to check at chip level

The first thing to settle is the difference between SoC and IP verification. When you design an SoC, each IP block is either bought from a third party or built in-house, and you can assume it already passed its own IP-level test suite. The SoC team integrates those blocks to match the chip specification. So the SoC verification team checks chip-level behaviour, which is mostly about integration. Each IP supports many features, so the skill is picking which features actually need checking at the SoC level. For example, an IP might have many interrupt outputs, but the SoC team only needs to verify the interrupts that are actually wired at the chip level. For the bigger picture of how blocks come together, see our SoC verification flow guide.

Key areas to consider during SoC verification

You could always throw more engineers at a complex chip, but that raises cost and hurts margins, so the real question is “what to verify at SoC level?” Here are the important areas, each with a short reason why it matters.

Area	What to check	Why it matters
Pin muxing	The muxing logic that shares a limited number of chip pins across many internal IP signals.	Pin count drives chip cost, so pins are limited. If the mux selects the wrong function, the chip talks to the outside world incorrectly.
Protocol checks	Protocol checkers placed at module boundaries.	Most integration bugs show up where two blocks talk. Checkers at the boundary catch illegal handshakes early.
SoC bring-up sequences	Reset sequences and boot-up, including boot from internal or external memory.	A chip that will not reset or boot cleanly is dead on arrival, so every boot source must be checked.
Memory and register access	That the design can configure registers and memory to enable various SoC scenarios.	Almost every feature is turned on through a register or memory setting, so access must be reliable.
Control and data paths	External interface protocols (LIN, CAN, UART), parallel masters (processor, DMA), and interrupt paths.	These are the paths that carry real traffic; contention and priority bugs hide here.
Analog modules	Analog block integration, ideally with behavioural models written in Verilog-AMS (VAMS).	Digital-only simulation cannot model analog behaviour well, so a VAMS model keeps it close to silicon.
Low power	Low-power entry and exit, verified with UPF or CPF intent and structures like isolation cells and level shifters at RTL.	Battery devices depend on it; missing isolation or a bad wake sequence can hang or corrupt the chip.
Polarity check	That an output port of one module connects with the correct polarity to the input port of another.	A single inverted connection can break a whole datapath in a way that is easy to miss.
Gate-level simulation	Timing issues, constraint or glitch problems, and combinational logic on the reset path.	RTL hides real timing. GLS catches problems that only appear in the gate-level netlist.
SPICE simulation	Analog functionality, with a few analog blocks in SPICE and the rest of the system in digital.	Behavioural models have limits, so mixed SPICE-digital runs confirm true analog integration.
System-level use cases	Application scenarios with multiple applications running in parallel that exercise real control and data paths.	These are what the customer will actually run, and they expose bottlenecks in latency and priority.

A closer look at a few high-value areas

• Pin muxing: a typical chip has far fewer pins than the sum of all IP signals, so one physical pin is shared by several functions through a mux. Verify that every function reaches its intended pin in every mux mode, and that changing modes does not glitch a live signal.
• Bring-up: beyond the reset check, walk through each boot source (internal ROM, external flash, and so on) and confirm the chip lands in the correct state. A wrong boot vector is a classic silicon bug.
• Control and data paths: set up transactions to the outside world through the interface protocols, run masters like the processor and DMA in parallel, and fire interrupts along their functional paths so priority and arbitration are exercised.
• Analog integration: because ordinary digital simulation cannot model analog behaviour accurately, write behavioural models in Verilog-AMS so the analog block behaves close to silicon during full-chip runs.
• Low power: tests should drive both entry into and exit from each low-power mode. Modern flows describe intent in UPF or CPF and insert isolation cells and level shifters at the RTL stage so the intent is verified early.

An efficient SoC verification strategy

Even with a clear list of what to verify, complexity can still outrun the schedule, so teams plan for automation to cover the whole design while keeping quality and hitting the deadline. These steps make the process more efficient:

• Effective test suite: build the verification plan from the chip specification so every feature maps to at least one test pattern. Review each pattern against the feature it covers and add clear comments about its intent.
• Automatic test-pattern generation: basic checks like memory and register access can be generated automatically rather than hand-written.
• Self-checking patterns: every test should decide pass or fail on its own, for example by comparing the interrupt count seen against expected, or a status register value at the end of a transaction. Built-in checks save large amounts of debug time.
• Automated testbench checks: enable monitors and assertions for key functions. Clock monitors and low-power entry-sequence checks are good examples.
• Reusable test suite: write the suite so a new SoC is mostly plug and play with minor tweaks. Code test cases in a high-level language so they do not depend on one processor. Reuse can be horizontal (SoC to SoC) or vertical (IP to SoC); both improve efficiency.
• Use the pre-silicon platform: very long patterns take a long time in simulation, so identify the key long-running scenarios and move them to an emulator or FPGA prototype.

Where randomization helps at SoC level

Use random stimulus in the testbench to reach corner cases that directed tests miss. Good candidates to randomize include:

• Values written in register read and write patterns.
• The number of resets applied during a pattern.
• Which pin is used to wake the chip from low-power mode.
• The latency of the wake-up from low-power mode.
• The width of the wake-up pulse.

For the difference between hand-written and random stimulus, see our directed vs constrained-random guide, and for building the coverage model see functional coverage.

More techniques that hit hard-to-reach corners

• Intelligent pattern selection for gate-level sims: GLS is very slow, so do not run every RTL pattern at gate level. Pick the ones that exercise IO paths, digital-analog interaction, clock gating, and clock-switching muxes for glitch detection.
• SoC-level regressions early: enable them at an early stage so you can track progress against overall test completion.
• IP-level regressions: run an IP regression suite on each IP release delivered to the SoC team, so the SoC team can focus on true SoC-level defects rather than IP bugs.
• Formal checks for IO muxing: with more logic muxed onto each limited pin, directed patterns cannot cover every path. Formal verification checks the IO muxing quickly and thoroughly.
• Coverage: enable design coverage (toggle, code, FSM) in every regression to find and close holes, and add cover points and covergroups so you can confirm assertions and monitors are exercised.
• Low-power at RTL and gate level: verify low power in both to confirm the low-power cells were inserted correctly in the netlist.

A worked example: a self-checking register access test

Here is a small, LRM-correct SystemVerilog style example of a self-checking register test of the kind you would write for the “memory and register access” area. It writes a value, reads it back through a simple bus model, and flags any mismatch on its own.

// Self-checking register write/read-back check (illustrative)
task automatic check_reg(input logic [31:0] addr,
                         input logic [31:0] wdata);
  logic [31:0] rdata;
  bus.write(addr, wdata);   // drive a write on the bus model
  bus.read (addr, rdata);   // read the same address back
  if (rdata !== wdata) begin
    $error("REG MISMATCH @ 0x%08h: wrote 0x%08h, read 0x%08h",
           addr, wdata, rdata);
  end else begin
    $display("REG OK @ 0x%08h = 0x%08h", addr, wdata);
  end
endtask

// Randomized driver over a small register map
initial begin
  logic [31:0] a, d;
  repeat (20) begin
    a = {24'h0, $urandom_range(0, 8)} << 2; // word-aligned addr 0..8
    d = $urandom();
    check_reg(a, d);
  end
  $finish;
end

The same pattern extends to interrupts: count how many interrupts the design raised and compare against the expected number, rather than eyeballing a waveform.

When do you stop SoC verification?

This is the question every engineer faces at sign-off. Even if gate count grows in a straight line, the number of possible states can grow exponentially, so you cannot verify every state. A clear set of coverage goals keeps the effort focused on converging with quality in limited time.

• At module or IP level: collect full code coverage (line, expression, block, FSM, toggle) plus functional and assertion coverage.
• For SoC integration: toggle coverage is a key metric. Review and analyse code coverage for logic the SoC team wrote, such as clocking and glue logic, and add tests to fill gaps.
• For analog blocks: define functional coverage and assertions on the behavioural models to confirm the normal operating modes are exercised.
• For low-power modes: use the power-format files to collect a functional-coverage database of the low-power states.
• Closure: when there are no holes left against the specification, you have evidence that nothing in the intended functionality was missed.

Source: the area list and strategy follow the EDN article “How to verify SoCs”.

Expected result, in plain words

This is guidance and a checklist, not one simulation run, and the code above describes intended behaviour from a SystemVerilog read rather than a captured run. In practice, working through these areas with self-checking tests should give you a regression that passes consistently and a coverage report with no unexplained holes. Random values depend on your seed, and timing and glitch results depend on your netlist and tool, so confirm everything on your own simulator, emulator, and coverage tool.

Frequently asked questions

Share this post: on Twitter on Facebook