Platform
Verification
Table of Contents
Executive Summary
Platform verification is a new methodology for verifying system-on-a-chip
(SoC) and system-level designs. Analogous to platform design, platform
verification is an integrated functional verification system supporting
all levels of abstraction concurrently throughout the entire design
flow. By integrating the complete verification suite into a single,
unified environment, designers can better meet the challenges of
larger designs, shorter time windows and shrinking resources.
The ideal architecture for this methodology
is a single, unified hardware platform that features simultaneous
verification (simulation, acceleration and emulation), scalable
capacity, verification consistency, advanced debugging and co-verification
(concurrent hardware and software verification). Abstraction binding,
that is, supporting all levels of abstraction concurrently through
the entire design flow, enables designers to reuse many of their
models during verification.
Further gains in productivity can be realized
through domain-specific solutions for markets such as embedded processors,
graphics, multimedia, networking, communications, wireless and PDAs.
These prepackaged solutions include qualified and tested IP modules
and an integrated platform verification suite.
The Increasing Challenge
of Verifying Complex Designs
Design teams who are developing SoCs are coming under increased
time pressures. Product life cycles are shorter, so the market window
of opportunity is smaller than ever before. This fact pushes design
teams to finish their designs faster and with a higher degree of
confidence that the fabricated chip will be right the first time.
Also, highly price-competitive markets force product developers
to continually look for ways to increase the level of integration
and hold down development costs.
However, other factors are working against
this goal of faster and cleaner designs. Take the constant shrinking
of the chip geometries. As the geometries get smaller, functions
can be integrated into the SoC that used to require additional chips;
in a sense, the functions become "free" on the manufacturing side.
But incorporating more functions takes more design time and requires
more internal interconnects, which greatly increases the complexity
of the verification task. The trend toward using IP blocks, often
from multiple vendors, further adds to the complexity of verification
due to both the increased functionality and the diverse tool sets
used by IP vendors to verify their IP.
The Expanding Verification Project
The increase in complexity adds up to longer
verification times. Recent studies have shown that the verification
portion of SoC development has grown significantly, reaching as
much as 70% (see Figure 1).
Figure 1. Verification
in the Total Design Effort
The increase in the verification portion can
potentially lengthen the design process and add costs, thus working
against the OEM's requirements for time to market and budget control.
Therefore, a desirable goal for verification systems of the future
is to reduce the time and resources spent on verification without
adversely impacting the accuracy of the result.
The Verification Gap
In most of today's design efforts, the verification
system consists of two disjoint environments: simulation/acceleration
and emulation. In effect, the design team must maintain create,
operate and maintain two distinct verification environments. Within
each environment, there are often microenvironments, for example,
the use of IP blocks from multiple vendors may require several different
simulation tools. Creating, operating and maintaining a number of
different verification environments has a number of disadvantages:
- Time intensive: Each environment requires
a great deal of setup and configuration. In general, very little
of this work is transferable between verification tools.
- Resource intensive: Separate sets of verification
tools require tool specialists
- Risk intensive: The biggest potential problem
of multiple verification environments is the very real possibility
of incomplete or faulty testing. Moving from simulation to emulation
requires a "leap of faith," since successful simulation results
are no guarantee that the emulation will work.

Figure 2. The Verification Gap Today
Domain-Specific Designs
Many design teams find that they spend larger
portions of their effort on the "standard" parts of their SoC as
opposed to developing their own unique and differentiated IP circuitry.
For example, consider a graphics OEM who wants to develop a single
graphics SoC for a 3D graphics card. Most SoCs for this market segment
have a similar block diagram (see Figure 3.)

Figure 3. Graphics SoC, Block Diagram
Much of the design effort for this project
involves specifying, locating, qualifying, procuring, implementing
and testing the vendor IP blocks (shown in solid blue outline).
For most projects, the design team starts from scratch. Yet the
major project differentiation occurs in the OEM's IP block shown
in dotted red outline. The ability to start the design effort with
the vendor IP blocks chosen and in place would provide a significant
time-to-completion advantage to the design team.
Platform Verification Offers
a Solution
Just as the design world is turning to a platform-based paradigm
for SoCs, the same methodology can be used for verification tools.
Platform verification is an integrated functional verification methodology
supporting all levels of abstraction concurrently throughout the
entire design flow. Such a methodology would provide design teams
with a powerful new way to address the needs of the next generation
of SoC designs.
What are the attributes of platform verification
methodology?
Simultaneous verification: Where traditional
verification methodologies have a gap between simulation and acceleration
on one side and emulation on the other, platform verification allows
designers to flow smoothly between simulation, acceleration and
emulation in both directions. Simultaneous verification brings consistency
and predictability to the verification process by integrating the
entire environment. Platform verification requires a hardware architecture
that supports the full range of verification functions in a single
hardware architecture (see "RCC Architecture").
Co-verification: SoCs that include programmable
blocks such as embedded processors pose a special challenge in the
verification process because the operation of the SoC involves a
complex interaction of hardware and software. To effectively test
a programmable SoC, designers must be able to verify the software
and hardware simultaneously (co-verification). Platform verification
supports co-verification at any stage in the design process.
Verification consistency: A great deal
of engineering effort goes into creating the models used in the
verification environment. In traditional systems, these models must
be recreated as the design flow proceeds, for example, models created
in C++ during early proof-of-concept simulation must be recoded
as RTL for later simulation. Platform verification supports a heterogeneous
set of models through the design process to allow reuse of models
(see "Abstraction Binding").
Scalable capacity: Verifying an entire
platform requires a significant increase in the total capacity of
the verification hardware. The ability to verify a design of 10
million gates can be considered a minimum for today's system-level
designs. Furthermore, the hardware must be able to grow gracefully
as designs increase in size. High capacity and scalability are fundamental
requirements for platform verification (see "High Capacity and Scalability").
Advanced debugging tools: To track and
isolate quickly the location of design problems, a platform verification
environment must include a suite of integrated, highly effective
debugging tools. This need also implies having total visibility
into the verification history at all times.
Pre-validated domain-specific solutions:
For many domain-specific applications such as networking, wireless
and graphics, the general architecture of the SoC design is fairly
standard. A platform verification environment that included the
block architecture and pre-qualified IP modules would provide an
enormous head start for the design team, allowing them to focus
more development effort on their own IP design. Such a reference
point also eliminates risk by providing a known stable starting
point (see "Domain-Specific Solutions").
The Platform Verification
System
Implementing the methodology requires an environment tailored to
the specific needs of platform verification. The Axis verification
system provides these key elements:
- RCC architecture
- In-circuit verification
- Abstraction binding
- High capacity and scalability
RCC Architecture
The Axis system incorporates a massively parallel
architecture in which computationally intensive tasks are mapped
onto millions of ReConfigurable Computing (RCC) elements formed
in an RCC cluster . Computational efficiency is derived from the
ability to build and use custom configurations of RCC elements for
a particular function. RCC enables the unification of the verification
system by supporting simulation, acceleration and emulation with
a single hardware platform, thus closing the verification gap (see
Figure 4).

Figure 4. Simultaneous Verification
In-Circuit Verification
The Axis verification system features In-Circuit
Verification (ICV), a new concept in SoC verification . ICV offers
designers three distinct yet interrelated modes of operation:
In-Circuit Simulation (ICS): The
Device Under Test (DUT) is simulated in the software simulator while
the stimulus is provided by the target system. ICS offers flexibility
and ease of debugging and operates at speed similar to traditional
simulation, up to 100 cycles per second.
In-Circuit Acceleration (ICA):
As the SoC design grows, ICA can be used to run a large portion
of the simulation model in an acceleration mode using the RCC hardware.
A mixture of software testbenches (running in the host) and target
system signals is used for stimuli. ICA is extremely flexible and
operates at speeds up to 100,000 cycles per second.
In-Circuit Emulation (ICE): For
maximum performance, the entire DUT is run on the RCC hardware.
Speeds for ICE can reach 1 million cycles per second.
Abstraction Binding
An important concept in platform verification
is the handling of the various levels of abstraction that are used
in the design process. Traditional verification systems have a distinct
division between simulation and emulation that dictates different
abstraction levels in each world, with the only area of overlap
occurring at the RTL and gate levels.
The Axis verification system incorporates the
concept of abstraction binding, in which all levels of abstraction
are unified in a single platform. Abstraction binding provides the
maximum reuse of models throughout the entire verification process
and leads to high levels of productivity gain and reduced model
translation cost. (see Figure 5).
High Capacity and Scalability
The size of SoCs can be expected to continue
to grow at a rapid rate for the foreseeable future. By one estimate,
chip sizes will exceed 100 million gates by 2017 . The Axis architecture
has been designed with large chips in mind, from today's 10 million-gate
systems up to 100 million and beyond. Design teams can install a
system today and extend the system as their needs grow, thanks to
the inherent scalability of the Axis architecture.

Figure 5. Abstraction Binding in the Design Flow
Domain-Specific Solutions
Design teams reap huge benefits if they can start their design effort
from a predefined reference point. Many vertical markets in principle
lend themselves to this approach, including:
- Embedded processors
- Graphics
- Multimedia
- Networking
- Communications
- Wireless
- PDAs
Axis is in the process of developing pre-qualified
domain-specific solutions to meet the needs of key vertical markets.
An example is the computer graphics subsystems using an embedded
processor (see Figure 6). This domain-specific solution includes
an ARM9 embedded processor as well as RGB and PCI/AGP interfaces.
With this architecture as a starting point, an OEM can use the platform
verification methodology to ensure a consistent and predictable
design flow throughout the development process. This environment
supports a wide range of possible verification configurations (see
Table 1).

Figure 6. Domain-Specific Solution for Graphics Subsystem
Table 1. Verification
Modes

Benefits
The platform verification methodology offers important benefits
to SoC and system design teams:
Increased Productivity: Simultaneous
verification reduces the need for test engineers to learn multiple
verification tools and shortens the time spent on verification.
Abstraction binding eliminates the need for recreating models, a
time drain in traditional verification methodologies. Advanced debugging
tools track and isolate quickly the location of errors and reduce
total debugging time.
Risk Reduction: The ability to
reuse known-good models throughout the process reduces the risk
of introducing errors into later stages of verification. Simultaneous
verification brings consistency and predictability to the verification
process by integrating the entire environment. Also, the in-circuit
verification capability allows software models to be replaced by
actual system hardware as it becomes available, more closely modeling
the behavior of the target system.
Shortened Time to Market: The
unified approach to platform verification helps design teams shorten
the total development process and meet today's more demanding time-to-market
goals. Using pre-qualified domain-specific solutions can further
decrease development time.
Summary
Platform verification methodology can offer substantial benefits
to OEMs who want to hit shorter market windows while controlling
resource costs. The Axis architecture offers an ideal environment
to support platform verification and reap the potential benefits.
Pre-qualified domain-specific solutions complement the platform
verification methodology and increase the benefits to OEMs.
|