Fragmentation of the IC Verification Process
Rita Glover, EDA Today, L.C.
October 2003
The traditional simulation/verification market was nearly a $1 billion
market in 2002, mostly VHDL and Verilog simulators. Although that
market is fairly saturated, there is still an important business need for
dramatic improvements in verification productivity.
A typical fabless design project costs about $20 million to undertake,
and roughly half of this cost is verification. About 70% of first
silicon comes back with errors, not because of problems with yield or
timing, but because of functional problems that were missed during
verification.
Most design groups address this issue through a collection of
verification approaches. You hear about system-level modeling and
testbenches that use different flavors of languages, proprietary and
standard. You hear about acceleration, emulation, assertion-based
verification, formal verification, analog/mixed signal solutions. Any
or all of these solutions are improvements, but none of them by itself is a
silver bullet.
Mitch Weaver, vice president of marketing for Cadence's functional
verification group, terms this problem "verification fragmentation."
He says the typical verification methodology employs multiple tools, and
each tool is an island of automation with its own IP, user interface,
debugger, and way of dealing with data.
The product "design chain" amplifies the problem. Weaver explains,
"If you think of a single-chip cell phone, it might use ARM as the
microprocessor supplier, Texas Instruments as the integrator of a DSP with
that ARM block, and then TI's customer differentiates the product with
software. In this case you have a verification design chain that spans
three or four companies. The companies themselves may have several
variations of this, so fragmentation exists within projects, within
companies across projects, and throughout design chains.
"Suppose that single-chip cell phone maker wants to develop embedded
software -- their differentiation -- long before silicon is available.
A common reference model for that chip is needed downstream, as well as
upstream during the design process. The fragmentation problem results
in longer times to get to silicon, missed market windows, and possibly major
business disasters."
Today customers deal with verification using different languages,
different levels of abstraction, and different approaches for each of those
languages and abstractions. When you throw in advanced approaches like
formal and assertion-based verification, you're using a little bit of
everything. In the end you have to ask whether you have verified
enough. A high percentage of the time, the answer is no.
Cadence's Incisive verification platform has a single-kernel architecture
that takes in multiple standard languages -- VHDL, Verilog, System C, and
PSL -- in a transparent and consistent way. It offers a single
debugging, analysis, and testbench environment that transcends languages,
techniques, and levels of abstraction. This single-kernel architecture
provides a single coherent view into the design, and maps a design
description into three ways to do verification.
Figure 1: Cadence’s Incisive verification platform
enables a unified methodology to deliver the ultimate in speed and
efficiency.
The first is traditional simulation, but using a single-kernel simulator.
The second is what Cadence calls "acceleration on demand" -- which is
hardware-assisted simulation, but accelerated by three or four orders of
magnitude. With a single-chip cell phone, the power-on sequence alone
takes 3 or 4 seconds, and it executes perhaps several couple hundred million
instructions. To simulate the power-on sequence, you have to run a
hundred million simulation cycles just to see if it comes life, let alone
see if it actually works. Traditional simulation approaches are not
enough. You need a 2-5X performance improvement to do even the simple
sequences.
Cadence's hardware accelerator/emulator -- Palladium -- is "domesticated"
into the verification environment. Previously, hardware emulation was
one of those verification fragments, and required a design description to be
"ported," or changed so that it can be moved to a traditional hardware
accelerator/emulator that uses a completely different representation.
But then you're verifying something that is not quite the same as what you
originally built and modeled in your simulator. Palladium is connected
to the network (even a wide-area network) and the user can easily offload
simulation tasks as needed, without translation.
The third way to do verification is through a static, formal approach
where you evaluate questions about the design without having to write test
vectors. The Procedural Specification Language (PSL) is becoming a
standard for assertion-based verification. The PSL Consortium was
formed at DAC 2003 with 20 members (both EDA vendors and IP vendors) who
would like for all IP to become "instrumented" with PSL. That IP would
already come with its own verification environment—tests and monitors in
PSL. A tool that can interpret PSL (like Incisive), would be
self-verifying, to some extent. When you stitch these IP blocks
together, you get some verification for free when a PSL implementation is
part of the deliverable.
Incisive is about multiple languages in a single, unified environment;
multiple verification approaches -- static, dynamic, and emulation or
hardware-assisted -- in a single environment; and different
abstraction levels in a single environment.
Cadence is committed to keeping the Incisive verification platform open
and standards-based. Given that certain new companies are now
providing high-level descriptions which are algorithmic in nature, Incisive
also offer an algorithmic capability to handle areas where there are no
standards yet. Realizing that no one company can do it all, Cadence
built high-performance interfaces into this product in order to encourage
the "ecosystem" of third-party tool and IP providers.
Top
