1
Abstract
This paper provides some guidelines on how to
approach System On a Chip (SOC) verification, and how to
create effective SOC testbenches. It surveys the challenges
in SOC verification and some of the traditional verification
techniques, and then focuses on showing preferred practical
approaches to the problem.
1. Introduction
This paper starts by giving an introduction to SOC
verification and its hardships. We look at typical SOC
designs and the traditional verification techniques applied
to them, commenting on their benefits and inherent
limitations. As part of that, we mention the components of
an SOC and some effect they have on the design of the
testbench.
The rest of this paper focuses on showing practical and
novel approaches to the verification of SOC designs.
Experience shows that many SOC bugs result from
incomplete integration of IP cores and complex scenarios
and corner cases between the software and hardware
components of the system. Techniques for dealing with both
of these are discussed.
All material presented is based on the combined
experience of many verification experts in many application
domains. The technology mentioned is mature and
available, and all that remains to be done is to develop
“verification environments as they should be”.
This paper discusses simulation-based verification, or in
other words, verification done by running well-targeted
simulations in self checking verification environments. This
paper does not discuss any formal techniques, which are
considered complementary.
It is our belief that creating good and capable verification
environments involves some degree of programming.
People write testbenches using a large variety of languages
and tools: Verilog/VHDL, C/C++/PERL, and some
verification languages and tools customized for verification.
2. Why are SOC Designs Special
Let us open by defining what an SOC is and is not. A
System On a Chip (SOC) is an implementation technology,
not a market segment or application domain. SOCs may
have many shapes and many different variants, but a typical
SOC may contain the following components: a processor or
processor sub-system, a processor bus, a peripheral bus, a
bridge between the two buses, and many peripheral devices
such as data transformation engines, data ports (e.g.,
UARTs, MACs) and controllers (e.g., DMA).
In many ways, the verification of an SOC is similar to the
verification of any ASIC: you need to stimulate it, check
that it adheres to the specification and exercise it through a
wide set of scenarios. However, SOC verification is special
and it presents some special challenges:
Integration
: The primary focus in SOC verification is on
checking the integration between the various components.
The underlying assumption is that each component was
already checked by itself. This special focus implies a need
for special techniques.
Complexity
: The combined complexity of the multiple
sub-systems can be huge, and there are many seemingly
independent activities that need to be closely correlated. As
a result, we need a way to define complicated test scenarios
as well as measure how well we exercise such scenarios and
corner cases. [1]
Reuse of IP blocks
: The reuse of many hardware IP
blocks in a mix-and-match style suggests reuse of the
verification components as well. Many companies treat
their verification IP as a valuable asset (sometimes valued
even more than the hardware IP). Typically, there are
independent groups working on the subsystems, thus both
the challenges and the possible benefits of creating reusable
verification components are magnified. [4]
HW / SW co verification
: The software or firmware
running on the processor can be verified only in relation to
the hardware. But even more than that, we should consider
the software and hardware together as the full Device Under
Test (DUT), and check for scenarios that involve the
combined state of both hardware and software. Thus we
need a way to capture hardware and software dependencies
in the tests we write and in the coverage measurements we
collect.
Practical Approaches to SOC Verification
Guy Mosensoson
Verisity Design, Inc.