Removing the Processors
test generation is a transaction-oriented verification solution,
similar to driving packets onto the bus that had been driven by a
processor now removed. This solution allows the maximum flexibility in
terms of what can be sent into the rest of the hardware.
problem is that this traffic is not realistic unless scenarios are
created in the verification code to perform functions representative of
the system’s operation. This involves knowing how to set up the
peripherals to perform certain functions and generating the correct
sequence of events on the bus to make data move through the system in a
The UVM breaks down when a processor is added to
the system, as shown in Figure 3. VIPs are not available for processors
and there’s no way to write sequences that mimic the flow of data
through a processor. Thus, with a UVM verification strategy, the usual
option is to remove the processor and drive it with a bus functional
model (BFM) that enables transactions to be driven onto the bus. Again,
this approach may not produce realistic system-level traffic.
Figure 3: UVCs with Processor Added
Running Production Software
designers would object to running production software on the system to
see if it behaves as expected. This is the heart of hardware/software
co-verification and many companies include this step as part of the sign
However, it is unlikely that software will be
available in the right timeframe. Prior to tapeout, a Catch-22 
situation is created. The hardware design is not ready and stable so
that running software may be unreliable, but the software cannot be
debugged and stabilized without executing it on stable hardware –– a
difficult way to perform system-level verification and debug.
addition, relying only on the execution of production software provides
inadequate testing. Production software tends to be well-behaved and
not stress corner cases in the design. Further, if the software were to
change and exercise different flows through the hardware, bugs lurking
in the design could restrict the versions of software that could be run.
Finally, production software usually runs slowly in simulation. Booting
a real-time operating system (RTOS) on an embedded processor is
feasible on a hardware accelerator, but this option is not available to
all SoC verification teams.
Writing Custom Software
course, it is possible to handwrite custom software to run on the
processors and could be at two different levels. First, directed tests
could be written that move data through the system in a specific manner.
This may use some of the production software, such as drivers, to
create a hardware abstraction layer so that the test developer does not
need to know details, including peripheral configuration. Directed tests
suffer from many of the same problems as running production software,
in addition to the time it takes to write the tests.
software could be written that is more specific for verification,
analogous to the process of writing code for built-in self-test (BIST).
While multiple tests could be written, this tends to be customized code
that may not be useable when the platform is modified or extended. It
gets successively more difficult as additional processors are added into
the system, especially if they are heterogeneous in nature. Moreover,
humans have trouble visualizing parallel activity within the SoC, making
it difficult to handwrite multi-threaded tests for multiple embedded