In-Circuit
Verification (ICV) Unifying Simulation and Emulation
Table of Contents
Introduction
This paper introduces a new methodology known as In-Circuit Verification
(ICV). It defines the three unique modes of ICV and helps you to
understand how to logically transition across these modes from simulation
to emulation by minimizing the number of variables introduced during
the transitions. Also, best practice debugging methods are discussed,
and an example of how to apply ICV methodology is provided.
Before delving into the ICV discussion, some
history and explanation for the evolution of ICV is presented.
The Verification Challenge
There is universal agreement that functional verification is one
of the major challenges facing the electronic design industry. Design
complexity is increasing rapidly, geometries are shrinking, more
functionality is required, and more IP is available to integrate
into a single device. Time-to-market pressures are resulting in
shrinking design schedules, and everyone is focusing on getting
chips into production as quickly as possible. Most engineers agree
that design verification is now taking 60 to 70% of the overall
schedule.
As today's designs push past 1M gates and move
toward 10M gates, engineers require new tools and methodologies
to verify these devices. Unfortunately, some engineers expect to
verify these chips using the same logic simulation tools that have
been used for the last ten years, when designs were 100k gates.
While it still plays a crucial role in verification, the speed of
software simulation is just too slow to continue as the primary
verification method. The simulation farm is one alternative, but
is effective only when many shorter tests can be run in parallel
across the farm. Many applications require long data streams, and
running many short tests is not possible.
Historical Emulation
Methodology
The emulation system was introduced nearly fifteen years ago to
address the speed of software simulation and to provide additional
stimulus for the design.
There are many benefits of emulation, including:
- Testing and debugging application software
before tapeout
- Verifying that the design meets all performance
requirements in a realistic environment
- Demonstrating working functionality earlier
in the design schedule
- Gaining increased confidence with more comprehensive
verification
However, emulation has traditionally been more
difficult to use than software simulation and, even though there
are benefits, some projects choose not to deploy emulation. One
of the difficulties of deploying emulation is the great disconnect
that exists between the world of simulation and the world of emulation.
Because of this disconnect, emulation is not usually started until
nearly all of the simulation tests have passed and a bug-free hardware
design is available, thus putting the primary verification burden
back on the simulation environment.
The discontinuity between traditional simulation
and emulation comes from the fundamental differences between their
technology and environment. Simulation uses an event-driven algorithm,
and emulation uses a cycle-based algorithm. Simulation uses behavioral
testbenches to stimulate the design, and emulation uses hardware
interfaces and requires synthesizable testbenches. Crossing this
gap takes valuable engineering time. Because of the number of new
variables introduced, it is common to see emulation system bring-up
times of eight to twelve weeks.
Moreover, the mapping process into the emulation
database is not always functionally correct, and the only way to
verify this mapping is by applying simulation vectors to the emulation
database and comparing the results with the software simulation
output. The differences in the results represent mismatches between
the two environments that may be correctable or may exist for the
entire project.
Characteristics
of Emulation
 |
Once the emulation system
is up and running, the major problem becomes database management.
The simulation and emulation netlists constitute a separate
but theoretically equivalent representation of the design. Simulation
is done using RTL code, and compilation times are relatively
fast. Integrating changes into the design and recompiling a
simulation executable is manageable using today's configuration
management tools. Emulation is done using a gate-level netlist
created from a logic synthesis process that may take many hours
to produce. The large data files produced by synthesis must
also be maintained using configuration management tools.
|
Add to that the possible requirement of making
manual emulation netlist changes, and maintaining two separate representations
of the design becomes a major task. When design errors are found,
they must be tested in simulation and emulation before being accepted
- a process that could take a few days. As a result, these two databases
are almost always out of sync during key portions of the verification
process.
Emulation is a useful technology, but the cost
of the necessary resources is too high for many projects that could
benefit from it. Maintaining an emulation setup usually becomes
a separate project from running simulation. To be successful, companies
have had to set up a separate team of engineers to maintain emulation.
Towards a New Emulation
Methodology
The methodology to achieve success requires unifying the simulation
and emulation domains so they are not two distinct verification
methods, but one in the same. A methodology that combines the benefits
of software simulation and the benefits of emulation provides an
integrated design flow that increases productivity much earlier
in the design process.
However, providing a simple bridge to allow
a testbench to drive an emulator is not enough-more needs to be
done. A new methodology, In-Circuit Verification (ICV), provides
a complete solution that unifies simulation and emulation, as well
as additional enhancements to make this unification truly useful
and workable.
In-Circuit Verification To
understand the unification of simulation and emulation requires
a review of existing and new verification terms.
Software Simulation refers
to an event-based logic simulator that operates by propagating input
changes through a design until a steady state condition is reached.
Software simulators run on workstations and commonly use Verilog
and/or VHDL as a simulation language to describe the design and
the testbench.
Simulation Acceleration refers
to the mapping of the synthesizable portion of the design into a
hardware platform specifically designed to increase performance
by evaluating the constructs in parallel. The remaining portions
of the design and environment are run in a software simulator. The
software simulator works in conjunction with the hardware platform
to exchange simulation data.
Removing most of the simulation events from
the software simulator and evaluating them in a hardware platform
increases performance. The final performance is determined by the
percentage of the simulation that is left running in software.
Emulation refers to the mapping
of an entire design into a hardware platform for maximum performance.
The hardware platform does not have a constant connection to the
workstation during execution nor does it receive any input from
the workstation. By eliminating the connection to the workstation,
the hardware platform now runs at its full speed and does not need
to wait for communication from the outside world.
In-Circuit refers to the use
of external hardware coupled to an emulation hardware platform.
The purpose of in-circuit is to provide a more realistic environment
for the design being simulated. This external hardware commonly
takes the form of a circuit board, called a target board
or a target system, and connects to the emulation
hardware platform via cables.
Three modes of In-Circuit Verification are
derived from these four definitions. The term In-Circuit Emulation
is the most familiar. Less familiar are the other two modes, In-Circuit
Simulation and In-Circuit Acceleration. Until now, there has been
no single product that has implemented these modes of In-Circuit
Verification.
In-Circuit Simulation (ICS)
refers to simulating the design under test (DUT) in a software simulator
while maintaining the interface to the target system for the purpose
of stimulus. The characteristics of ICS are flexibility and easy
debug. Speeds obtained using in-circuit simulation correspond to
software simulator speeds, usually 10 to 100 cycles/sec for large
designs.
In-Circuit Acceleration (ICA)
refers to running a large portion of the simulation database in
the acceleration hardware. This method allows some testbenches to
be executed in software simulation while others are obtained from
the target system. The software simulator is the master of the event
scheduling and provides the simulation clock. ICA is the most flexible
method for bringing up in-circuit emulation and can typically provide
performance of 1,000 to 10,000 cycles/sec.
In-Circuit Emulation (ICE)
refers to running the entire design in the emulation hardware platform.
The stimulus for the design is provided by the target system and/or
synthesizable testbenches. To maximize performance there is no constant
connection between the emulation hardware and the workstation. The
speed of ICE ranges from 100,000 cycles/sec to 1,000,000 cycles/sec.
All commercial emulation systems have this capability.
In-Circuit Verification (ICV)
refers to the methodology of combining the three modes of operation:
- In-Circuit Simulation
- In-Circuit Acceleration
- In-Circuit Emulation
This forms a complete verification solution
that unifies simulation and emulation. Inherent in ICV is the ability
to easily switch between modes and the use of a single representation
of the design that runs in all modes.
Characteristics of
In-Circuit Verification
 |
Instantaneous Simulation
Swap refers to the ability to dynamically swap the
simulation state between the software simulator and the hardware
platform. With Instantaneous Simulation Swap, a single design
database runs in software simulation and on the hardware platform.
Some uses for Instantaneous Simulation Swap include interactive
debugging and initialization sequences that are better handled
in a software simulation environment. Instantaneous Simulation
Swap enables dynamic transition between the three modes of In-Circuit
Verification.
In-Circuit Verification must also offer
debugging methods that are just as easy as with software simulators.
|
There is a need for a debugging methodology
that resolves the problems of large waveform files or the dilemma
about when to turn on waveform dumping and which parts of the design
to dump. Better debugging methodology further eliminates the gap
between simulation and emulation and offers capabilities beyond
the sum of individual simulation, acceleration, and emulation products.
In-Circuit Verification
Debugging
In-Circuit Verification debugging is more like using a software
simulator and is much different from other emulation systems. All
debugging is done using industry-standard VCD and FSDB waveform
files on a workstation instead of logic analyzer-based tools.
In-Circuit Verification utilizes an innovative
technique called VCD-on-Demand (VoD) that alleviates the limitations
associated with large waveform files and the struggle to decide
when to dump and what to dump into waveform files. With VoD, nothing
is specified ahead of time - you just enable recording and extract
waveform files for the required time periods and design hierarchies,
either during or after simulation. There is no need to re-run the
simulation for the purpose of capturing specific waveforms. Generating
a waveform file typically takes less than one minute, and the recording
mechanism minimally impacts simulation performance (typically less
than 5%) while producing very small files (about 1MB per one million
simulation timesteps).
Over the last few years, emulation debugging
has progressed from using a simple logic analyzer working with mangled
signal names and having to specify which signals to be included
in the trace (and recompiling to change probes) to more complex
logic analyzer functionality. Some emulators can now correlate logic
analyzer data to the source code and provide 100% visibility at
any time. However, these emulators are still physically limited
by size of the trace buffer.
| It is important to remember
that 100% visibility at any time is not the same as 100% visibility
at all times. In-Circuit Verification with VCD-on-Demand provides
the ability to see all signals at the source level at all times. |
 |
Another capability of In-Circuit Verification
called Testbench Callback unifies simulation and emulation by providing
event-based, interrupt-driven callbacks for software checkers and
testbenches during In-Circuit Acceleration or In-Circuit-Emulation.
When migrating from simulation to emulation, many common simulation
features are lost. Even very simple features, such as using the
$display statement to print a message when an error condition occurs
or $readmemh and $writememh to load and store memory contents during
the middle of a test, cannot be done.
Testbench Callback uses a hardware signal to
trigger a call to a software system task during acceleration or
emulation and allows the task to be executed in software on the
workstation. Testbench Callback maintains the performance levels
of In-Circuit Emulation without giving up the flexibility of common
simulation tasks.
Emulation systems have traditionally been measured
on raw speed, but the more important metric is how long it takes
to find and fix a problem when it occurs. Also important is the
ability to deploy emulation earlier in the project to get higher
simulation performance, well before other emulation methodologies
could be used. Techniques like VCD-on-Demand and Testbench Callback
provide access to important data without rerunning simulation, adjusting
trigger conditions, or trying to duplicate an emulation problem
in simulation.
In-Circuit Verification
Methodology
The transition from logic simulation to In-Circuit Emulation involves
many interdependent variables. Attempting to introduce all of the
variables at once and move from the simulation domain to the emulation
domain make it difficult to determine the cause of problems. The
process of compiling the design and mapping it into the emulation
platform, as well as building a target board, introduces many new
variables. An error in any part of the setup can cause the emulation
to function incorrectly. Some of these areas include:
- Functioning emulation database
- Working target board
- Proper clocking distribution and configuration
of target board and emulator
- Physical interface between target board and
emulator
The best way to minimize In-Circuit Emulation
bring-up time is by utilizing the different In-Circuit Verification
modes to logically introduce only one or two variables at a time
instead of introducing everything all at the same time. This methodology
combined with the debugging features discussed makes it the easiest
emulation system to set up and to use.
| To better understand how In-Circuit
Verification is used in practice, consider an example SoC design
with a PCI interface. A simplified example chip containing a
CPU, memory, register set, and PCI interface is shown in Figure
1. This example methodology demonstrates a unified simulation
and emulation environment. |
Figure 1: Example Chip
|
Step 1: Block-level Verification
Initial verification work on this design involves
using logic simulation to verify that each of the major blocks is
working correctly. A bus functional model for the CPU bus can be
used to test the memory control logic and register interfaces, and
a bus functional model for the PCI interface can be used to verify
I/O bus operation. Block-level verification is done using a software
simulator and block-level testbench. During this stage, lint tools
are used to check syntax and synthesizability and code coverage
tools are used to confirm that the block is sufficiently tested.
Other tasks may include protocol compliance checking, protocol coverage
checking, and directed and random testing.
Step 2: Full-chip Verification
After each block has been tested independently,
they are brought together to form a full chip simulation. Software
code for the CPU is loaded into the hardware memory models and executed.
A testbench is used to generate transactions on the PCI bus interface.
Assuming the design is in the one million-gate range, the simulation
environment will probably run about 100 cycles/sec. This is just
fast enough to see some of the software initialization and system
configuration runs, but not fast enough to simulate a meaningful
quantity of data traffic.
Simulation Acceleration:
To increase performance of the simulation environment,
simulation acceleration is used. The Design-Under-Test (DUT) and
memories are mapped into acceleration hardware while the PCI testbench
continues to run in software simulation. Simulation acceleration
typically provides a ten to one hundred times performance improvement
over software simulation - achieving runtime performance in the
range of 1,000 to 10,000 cycles/sec. At this performance level,
it is possible to simulate much more data being processed by the
design. And when errors occur, debugging can be done easily using
VCD-on-Demand and Instantaneous Simulation Swap.
Using simulation acceleration not only provides
faster performance sooner in the project, but it also provides a
method for verifying the mapping of the design into the emulation
hardware platform. When moving to In-Circuit Emulation, this is
one of the variables that can cause problems. Typical emulators
use a cycle-based algorithm and are difficult to transition from
an event-based simulation tool. To use the In-Circuit Verification
methodology, the algorithm in the logic simulator must match that
of the hardware platform. The ideal platform is an event-based emulation
algorithm to match event-based simulation.
However, even with event-based technology,
there are possibilities of mismatches when moving from simulation
into emulation. Common causes are race conditions and timing- or
delay-dependent behavior. For example, Verilog does not have well-defined
event-scheduling semantics, and it is common for code to work on
one IEEE compliant simulator and not another because of event-timing
dependencies.
Step 3: In-Circuit Simulation (ICS)
In this example, part of the design verification
plan requires In-Circuit Emulation to provide additional testing
of the PCI interface. In-Circuit operation can provide many more
combinations of bus transactions and error conditions that are too
tedious to create using a testbench.
Initial bring up is done using In-Circuit Simulation
(ICS). ICS connects the software simulator with the target board
by using the emulator as a pass-through connection to the target
system. The necessary target boards and test equipment are assembled
in the lab for In-Circuit Emulation.
ICS allows design changes to be recompiled
very quickly since no mapping to hardware is being done. Basic functions,
such as reset sequencing and system initialization, can be closely
monitored and easily debugged by single stepping through each clock
of the simulation. ICS also eliminates an important variable from
the emulation bring-up process - the emulation database. Keep in
mind that the majority of the database has already been verified
using software simulation and simulation acceleration. A diagram
of ICS is shown in Figure 2.
Figure 2: In-Circuit
Simulation (ICS)
Step 4: In-Circuit Acceleration (ICA)
After the interface between the target board
and the design in the emulator has been validated using ICS, the
next step is In-Circuit Acceleration. ICA offers all of the performance
benefits of simulation acceleration with the added feature of a
target system. With ICA, behavioral and C models can continue to
run in the software simulator while the DUT runs in the accelerator
interacting with the PCI interface driven by the target system.
ICA provides the most flexibility during in-circuit
bring-up by allowing incremental testing of the target interface
with the DUT. As each bus interface becomes available as target
hardware, they can replace the behavioral bus models running in
the software simulator. Instantaneous Simulation Swap, VCD-on-Demand,
and Testbench Callback are available for debugging. Performance
levels are equivalent to simulation acceleration. A diagram of ICA
is shown in Figure 3.
Figure 3: In-Circuit
Acceleration (ICA)
Step 5: In-Circuit Emulation (ICE)
When all desired test sequences have been verified
using ICA, the next step is In-Circuit Emulation. At the time of
enabling ICE, almost every variable of the transition from simulation
to emulation has already been verified. The DUT mapping to emulation
hardware was verified during ICA. The target system interface has
been debugged with ICS and tested again with ICA. The last step
is to remove all testbench code and enter In-Circuit Emulation mode.
In ICE, the emulator takes control of simulation event scheduling.
A diagram of ICE is shown in Figure 4.
Figure 4: In-Circuit
Emulation (ICE)
In-Circuit Emulation gives the highest runtime
performance, usually in the hundreds of thousands of cycles/sec,
depending on the design. However, even though performance levels
may be similar to other emulation methods, In-Circuit Verification
methodology provides much better debugging via VCD-on-Demand, Testbench
Callback, and Instantaneous Simulation Swap. Even in ICE mode, it
is possible to use Testbench Callback and stop the emulation using
Ctrl-C just like a software simulator. All of these features make
running emulation seem just like running a software simulator. ICE
delivers the performance needed to test additional software that
was not possible with simulation or even acceleration performance
levels. Now, real time operating systems (RTOS) and other application
software can be run at speeds acceptable to software engineers.
Summary
In-Circuit Verification methodology unifies the simulation and emulation
domains. A single system for simulation, simulation acceleration,
and emulation provides a smooth transition across the three unique
In-Circuit Verification modes, resulting in faster bring-up times
for In-Circuit Emulation and higher performance earlier in the design
cycle.
In-Circuit Verification provides debugging
features that are as easy to use as simulation debugging tools.
ICV offers true 100% visibility of every signal in the design for
all time without saving huge waveform files or overflowing trace
buffers. The use of a single database to represent the design greatly
simplifies the verification project management. A summary of each
verification mode is listed in Figure 5.
Figure 5: Benefits of
In-Circuit Verification
To unify the once disjoint world of simulation
and emulation, Axis Systems, Inc. has introduced a unique verification
product called XtremeŽ. Xtreme supports the ICV methodology by seamlessly
allowing In-Circuit Simulation (ICS), In-Circuit Acceleration (ICA),
and In-Circuit Emulation (ICE). By offering an easy transition among
all three modes, Xtreme offers in-circuit configurations for the
most demanding verification tasks while maintaining the ease of
use of a software simulator. Xtreme uses patented ReConfigurable
Computing (RCC) technology and is the first platform to combine
ICS, ICA, and ICE into a single product.
|
