Verifying an IP block, a subsystem and a complete system-on-chip is not the same verification task performed on progressively larger RTL. The design hierarchy changes what the verification environment can control, what it can observe, how realistic stimulus should be generated, what a checker can reasonably predict and what evidence is required before sign-off.

The key principle is simple: as verification moves from IP to subsystem to SoC, direct controllability and observability usually decrease while interaction, concurrency, configuration and software involvement increase.

A good verification strategy therefore reuses proven components and evidence where appropriate, but it does not blindly reuse the assumptions made at the lower level. This distinction matters for engineers working with SystemVerilog and UVM because reuse is one of UVM’s central strengths. Accellera describes UVM as a methodology intended to support modular, scalable and reusable verification environments. Reuse, however, does not mean that an IP-level testbench should be copied unchanged into a full-chip environment. [1]

IP vs Subsystem vs SoC Verification at a Glance

These differences are also reflected directly in Alpinum’s practical Design Verification for SV/UVM training, which progresses from stimulus, checking and coverage through IP verification, subsystem integration and CPU-based SoC verification.

Why Verification Strategy Changes With Hierarchy

At IP level, the testbench often owns almost everything around the DUT. It may directly drive every relevant interface, force unusual timing combinations, create error conditions and inspect internal or boundary-level behaviour closely. Running thousands of small constrained-random tests can therefore be practical and productive. Integration changes this situation. At subsystem level, several individually verified components now share interfaces, memory, interrupts, resets or control paths. The important failures are increasingly associated with relationships between components, rather than with isolated transactions.

At SoC level, the problem expands again. Processors, interconnects, memories, accelerators and peripherals interact with firmware and software. A testbench may no longer be the natural owner of all traffic. Some transactions originate because code executing on a CPU configured a device, triggered a DMA engine or responded to an interrupt.

That is why the central verification question changes from:

“Can this block respond correctly?”

to:

“Can the complete system produce the right behaviour when many components act together?”

For a broader explanation of the UVM structure itself, see What Is UVM in Design Verification?. The distinction here is different: the focus is not on what UVM components are, but on how verification intent changes as the hierarchy grows.

IP-Level Verification: Maximise Local Controllability

IP verification normally offers the strongest combination of controllability and observability. Consider a FIFO, DMA controller, protocol bridge or peripheral. The verification environment can often drive transactions directly onto every external interface. Constraints can target empty/full conditions, illegal operations, boundary values, backpressure, reset interaction and other corner cases without first executing a large amount of system activity.

Stimulus at IP level

Effective IP stimulus commonly combines directed tests with constrained-random generation. The important goal is not randomness itself. The objective is to create legal and deliberately stressful combinations of behaviour that expose the IP’s state space efficiently. If an IP supports several independent interfaces, stimulus may also deliberately manipulate timing between them to explore race conditions, arbitration and flow control.

Checking at IP level

Because the IP boundary is well defined, expected behaviour can often be represented by a relatively focused reference model or scoreboard. Assertions can monitor protocol rules and temporal relationships close to their source. The environment may also have enough internal visibility to distinguish an implementation defect from a testbench problem quickly.

Coverage and sign-off

Functional coverage should describe meaningful requirements, operating modes and important crosses. Structural coverage can help reveal RTL that the tests have not exercised. Sign-off is therefore primarily a statement about the IP specification and its defined configurations. This is also where engineers need strong fundamentals before treating UVM as an abstraction layer. Alpinum’s SystemVerilog or UVM First? explains why stimulus, checking, assertions and coverage should be understood before relying heavily on UVM infrastructure.

Subsystem Verification: Interaction Becomes the Target

Subsystem verification is more than “bigger IP verification”. The important new behaviours occur across boundaries. Suppose several individually verified blocks are connected through an interconnect. Each component may satisfy its own specification, but the subsystem can still fail because of:

• Incorrect address decoding
• Incompatible configuration assumptions
• Ordering between transactions
• Reset sequencing
• Interrupt propagation
• Arbitration
• Backpressure
• Error forwarding
• Shared-resource contention

This is the stage at which coordination becomes a major stimulus problem. A subsystem environment may contain several reusable UVM agents, but rather than generating traffic independently, higher-level sequences often need to coordinate them around one system objective. A DMA scenario, for example, might require configuration through one interface, source traffic through another, memory responses from a third and interrupt observation at the end.

Checking must cross the boundaries

An IP-level scoreboard may confirm that one block transformed a transaction correctly. At subsystem level, the more useful question may be whether data injected on one side arrives correctly on another after travelling through several blocks. That requires an end-to-end viewpoint.

Cadence’s current system-verification material illustrates the same general requirement through system-level scoreboarding that checks data integrity across interconnects, memories and protocol boundaries. The engineering principle is vendor-independent: when the feature crosses multiple IPs, the checker must often cross them too.

SoC Verification: From Transactions to System Scenarios

At SoC level, the verification environment faces a different scale of state space. A complete device may combine processors, caches, coherent or non-coherent interconnect, memories, security controls, power management, accelerators and many peripheral subsystems. Exercising these features purely by issuing low-level bus transactions can become both inefficient and unrealistic. Software-driven verification therefore becomes increasingly important.

Instead of directly writing every peripheral register from a testbench, a scenario may execute software on a processor which configures several components and causes the system itself to generate the resulting traffic. This does not make UVM irrelevant. Reusable UVM monitors, protocol checkers, scoreboards, register models and other verification components can remain highly valuable even when they are no longer the primary source of stimulus. A common hierarchical reuse pattern is to retain IP-level observation and checking while moving higher-level control to CPUs, system generators or software.

Where scenario portability is important, the Accellera Portable Test and Stimulus Standard provides a standard representation of test scenarios that can span integration levels and execution platforms including simulation, emulation, FPGA prototyping and post-silicon environments.

The SCCS Hierarchy Review: Four Questions to Ask at Every Level

A useful way to review a verification strategy is to examine four dimensions whenever the design moves up one level of integration.

1. Stimulus: Who now controls the behaviour?

Ask whether the same interface is still externally controllable. An active IP-level agent may become passive when the interface is driven by another integrated block. At SoC level, the processor or firmware may become the natural stimulus source. Do not force IP-level stimulus architecture onto a hierarchy where the system itself should generate the traffic.

2. Checking: Where is the authoritative expected result?

At IP level, the answer may be a local reference model. At subsystem level, expected behaviour may involve routing, ordering or transformations across several components. At SoC level, not every detail should necessarily be duplicated in one enormous reference model. Teams may instead combine protocol checkers, end-to-end scoreboards, assertions, architectural invariants and software-visible checks. The checking strategy should follow the behaviour being verified.

3. Coverage — What new behaviour exists only at this hierarchy?

Simply merging IP functional coverage does not prove that integration has been verified. Subsystem coverage needs to ask whether combinations of components, traffic sources and configurations have interacted. SoC coverage may need to represent system use cases, memory paths, privilege modes, interrupt routes, concurrent initiators, software-controlled configuration and other architectural scenarios.

For a deeper treatment of the relationship between requirements, coverage and completion criteria, see Verification Planning That Actually Works: From Requirements to Coverage Closure.

4. Sign-Off: What evidence can be inherited, and what must be regenerated?

Re-running every IP test unchanged at full-chip level is usually neither necessary nor efficient. Instead, the SoC verification plan should identify what has already been demonstrated at lower levels and what new risk appears because the blocks are integrated. This leads to a more useful hierarchy of evidence:

IP correctness → subsystem interaction → SoC integration and system behaviour.

Each level consumes evidence from the level below while adding evidence that could not exist before integration.

How Coverage Changes From IP to SoC

One of the easiest mistakes is to use the same definition of coverage at every level. At IP level, a coverpoint might record FIFO occupancy, packet type, burst length or protocol response. At subsystem level, coverage should increasingly represent relationships: which initiator reached which destination, which traffic types coincided, which error propagated through which path, or which configuration combination was exercised. At SoC level, the question becomes more architectural. Coverage should help answer whether important system behaviours occurred, not simply whether individual signals toggled.

Code coverage remains useful as diagnostic evidence, but a full-chip percentage needs careful interpretation. RTL may be inactive because of configuration, power mode, redundancy or functionality deliberately proven elsewhere. Conversely, high structural coverage cannot establish that important software-driven or concurrent behaviour has been checked. This is why coverage closure should remain tied to verification intent rather than being reduced to one percentage.

How Sign-Off Changes

IP sign-off can often be closely related to a single specification. Subsystem sign-off must additionally establish that interface assumptions and integration behaviour are correct. SoC sign-off must synthesise evidence across many domains. That evidence can include lower-level verification results, system regressions, assertions, system functional coverage, software-driven scenarios, interface checking, static analysis and other project-specific methods. The central mistake is to assume that successful IP sign-off automatically composes into successful SoC sign-off. It does not. An integrated system can fail even when every individual block behaves correctly in isolation because the failure may lie in connectivity, ordering, configuration, concurrency or system-level assumptions.

The same issue becomes even more visible in multi-die systems; Alpinum’s article on system-level verification in the chiplet era examines how integration creates behaviours that cannot be demonstrated by isolated component closure alone.

A Simple FIFO Example Across Three Levels

Consider the same FIFO as it moves through the verification hierarchy.

At IP level, a testbench can directly push and pop data. It can target empty, full, almost-empty, almost-full, simultaneous read/write, wrap-around and reset behaviour. A local scoreboard can predict every output.

At subsystem level, the FIFO may sit between a producer, consumer and control logic. Verification now needs to establish that backpressure propagates correctly, data remains ordered across connected logic and reset or error behaviour remains coherent across the subsystem.

At SoC level, software may configure the path that eventually feeds the FIFO. The interesting verification scenario is no longer simply “write value X, read value X”. It may be “configure a peripheral, start a transfer, create competing traffic, service an interrupt and confirm that the final software-visible result is correct”.

The FIFO did not become less important.

The verification question surrounding it changed.

That progression closely reflects the hierarchy covered by Alpinum’s curriculum, which uses FIFO IP verification, subsystem verification and CPU-based SoC verification as practical learning contexts.

Common Mistakes When Moving From IP to SoC

Reusing tests instead of verification intent

A sequence written for direct access to an IP may not make sense when that interface is internal to the integrated design. Preserve the purpose of the test before preserving its implementation.

Disabling proven IP environments completely

When an IP becomes integrated, its active driver may no longer be appropriate, but its monitor, assertions, scoreboard or coverage model may still provide valuable observability.

Treating subsystem verification as optional

Jumping directly from IP to SoC can push integration bugs into the least observable and most expensive simulation environment. Subsystem verification exists partly to keep interaction problems manageable.

Merging IP coverage and calling it SoC coverage

A collection of locally closed IPs does not demonstrate that their interactions have been exercised.

Building an enormous full-chip reference model

More hierarchy does not automatically require one monolithic golden model. A layered collection of local checkers, end-to-end scoreboards and architectural checks is often easier to validate and debug.

Defining sign-off after regressions are running

Completion criteria should come from requirements and risk, not from whatever coverage metrics happen to be available late in the project.

What Verification Engineers Should Learn From the Hierarchy

The important skill is not memorising that IP uses one language while SoC uses another. Modern verification is more flexible than that. An engineer should instead learn to recognise how verification intent, controllability, observability and evidence change as the abstraction level changes.

SystemVerilog and UVM remain important because reusable verification components can preserve valuable checking and observation across the hierarchy. At higher integration levels, however, they increasingly coexist with software-driven tests, portable scenario descriptions, emulation and other system-verification techniques. That is the difference between knowing a verification methodology and knowing how to design a verification strategy.

For semiconductor teams that need broader delivery support, Alpinum’s design verification services cover verification planning, testbench architecture, IP integration, coverage and closure across ASIC and SoC programmes.

Conclusion

IP, subsystem and SoC verification should form a connected hierarchy of evidence. At IP level, verification can exploit direct control, fine-grained checking and detailed coverage. At subsystem level, interaction, coordination and end-to-end behaviour become increasingly important. At SoC level, software, concurrency, system configuration and architectural behaviour reshape both stimulus and sign-off. The goal is therefore not to rebuild verification from scratch at every hierarchy level.

It is to reuse proven verification capability while deliberately adding the new evidence required by integration.

Engineers who want practical experience connecting stimulus, checking, assertions, coverage, UVM, debug and IP-to-SoC verification can explore Alpinum’s SV/UVM design-verification course. The course includes practical exercises spanning IP, subsystem and CPU-based SoC verification rather than treating UVM purely as a class-library topic.

references

[1] Accellera Systems Initiative, “Universal Verification Methodology (UVM) Working Group,” Accellera Systems Initiative. [Online]. Available: https://www.accellera.org/activities/working-groups/uvm  Accessed: Aug. 15, 2026. Accellera defines the UVM objective around modular, scalable and reusable verification environments.

[2] IEEE, IEEE Standard for Universal Verification Methodology Language Reference Manual, IEEE Std 1800.2-2020, 2020. Available through Accellera’s IEEE standards programme.

[3] Accellera Systems Initiative, “Portable Test and Stimulus Standard,” PSS 3.0, Aug. 28, 2024. [Online]. Available: https://www.accellera.org/downloads/standards/portable-stimulus  PSS defines test-scenario representation that can be applied across integration levels and execution platforms.

[4] Cadence Design Systems, Inc., “System VIP Technical Brief,” Cadence. [Online]. Available: https://www.cadence.com/en_US/home/resources/technical-briefs/system-vip-tb.html  Accessed: Aug. 15, 2026. The material describes system scoreboarding, subsystem/full-SoC checking and simulation/emulation flows.

[5] Cadence Design Systems, Inc., “Perspec System Verifier,” Cadence. [Online]. Available: https://www.cadence.com/en_US/home/tools/system-design-and-verification/software-driven-verification/perspec-system-verifier.html  Accessed: Aug. 15, 2026. Cadence describes its system methodology in terms of SoC use cases, coverage-guided generation and vertical reuse from UVM-oriented verification.

[6] Alpinum Consulting, “Design Verification for SV/UVM Training,” Alpinum Consulting. [Online]. Available: https://alpinumconsulting.com/services/training/design-verification-for-sv-uvm-training/  Accessed: Aug. 15, 2026. The verified curriculum covers stimulus, checking, coverage, UVM, IP verification, subsystem verification, CPU-based SoC verification and verification planning.

FAQS