A Solution for Platform VIP
using platform IP, or when an integrated subsystem or system contains
one or more processors, it is important to ascertain the verification
process objective. It is no longer to verify the implementation of
blocks, but rather to verify that data can move through the system
correctly with the expected latency and bandwidth. This requirement is
not met by the UVM for systems that contain processors because there is
no suitable VIP that exists at the block level to support the platform.
is important that additional IP can easily be added to these platforms
and the same demand should be placed on the VIP that goes along with it.
This requirement is not well met by the UVM either since it requires
rewriting virtual sequences. It would be ideal if the same model can be
used as the verification plan and coverage model rather than having to
write additional models for each. The current UVM methodology is
cumbersome on both counts.
A solution exists that matches all VIP
requirements and describes the flow of data through IP blocks based on
possible outcomes. All possible outcomes for a block are described along
with the manner in which that outcome can be created. When multiple
blocks are connected together, more complex flows are created with one
block establishing demands and other blocks providing the necessary data
or conditions. Those blocks in turn establish demands. Thus, a cascade
of demands and ways to meet those demands are created by the VIP for
each IP block.
When a verification target (one of the outcomes)
is specified, a solver finds a possible path through all of the blocks
to achieve that outcome. A generator automatically writes the necessary C
code to run on the embedded processors. The combined VIP is the set of
all possible behaviors and becomes the coverage model as well as the
source of both stimulus and result checking. The selection of outcomes
becomes part of the verification plan. This form of VIP is a scenario
model that can be built incrementally and, as additional scenarios are
incorporated, more extensive tests can be generated, or more ways to
achieve desired outcomes explored.
Figure 4 shows a commercial
example of this approach, the TrekSoC EDA product  from Breker
Verification Systems. TrekSoC reads in a hierarchy of graph-based
scenario models that define all the possible outcomes for the SoC as
well as the ways to achieve these outcomes. It then solves for paths
through the SoC and automatically generated multi-threaded,
self-verifying C test cases to run on multiple embedded processors.
Since some of these test cases will send or receive data on the chip’s
I/O ports, TrekSoC also coordinates the embedded processors with
testbench BFMs, including standard UVCs.
Figure 4: Automatic Generation of Self-Verifying Test Cases
UVM virtual sequences, scenario models are directly reusable at higher
levels of hierarchy. In Figure 4, scenario models for the image
processor, camera and SD card controller blocks are instantiated with no
change in the SoC scenario model, a platform-based verification
solution, with platform VIP as reusable as platform IP.
for a platform is provided via a scenario model, the addition of a new
block creates new ways in which demands can be met or outcomes created.
The integration of this new VIP does not require rewriting or extension
of existing VIPs. The verification plan and coverage model is also
cumulative. Finally, scenario model VIP is implementation independent,
working equally well with a virtual platform or a register transfer
level (RTL) implementation of the IP blocks and SoC.
order to continue increasing the productivity associated with the
design and verification of complex systems, reuse has to be made
scalable and must have a similar impact on both design and verification.
Additional functionality is being instantiated at the system level and
constrained-random generation is failing to provide capabilities
required to verify this functionality.
While platform design IP
has increased the efficiency of the design process, VIP has failed to
deliver similar gains. A new method of describing VIP, scenario models,
is suitable for platform IP. It is reusable and extensible with built in
notions of coverage and verification planning.
Without a migration to scenario models, the SoC development process will become even more constrained by the verification task.
 Universal Verification Methodology (UVM) 1.1 User’s Guide, Accellera, 2011.
“ARM CTO asks: Are we getting value from verification?” by Brian
Bailey, EDN, June 13, 2012.
 Catch-22 by Joseph Heller, Simon & Schuster, 1961.
“Verifying SoCs from the Inside Out” by Thomas L. Anderson, Chip
Design, August 3, 2012.
About the author:
Hamid is co-founder and CEO of Breker Verification Systems. Prior to
starting Breker in 2003, he worked at AMD as department manager of the
System Logic Division. Previously, he served as a member of the
consulting staff at AMD and Cadence Design Systems. Hamid graduated from
Princeton University with Bachelor of Science degrees in Electrical
Engineering and Computer Science and holds an MBA from the McCombs
School of Business at The University of Texas.
If you found this article to be of interest, visit EDA Designline
where you will find the latest and greatest design, technology,
product, and news articles with regard to all aspects of Electronic
Design Automation (EDA).
Also, you can obtain a highlights update delivered directly to your
inbox by signing up for the EDA Designline weekly newsletter – just Click Here
to request this newsletter using the Manage Newsletters tab (if you
aren't already a member you'll be asked to register, but it's free and
painless so don't let that stop you).