|
Co-Verification Debugger Enables Hardware
and Software Communication for SoC Verification
Table of Contents
The State of Verification
Verification efficiency is the latest topic of discussion among engineers
and EDA vendors. To address this topic, it is best to identify the
major tasks in verification:
- Test creation is the time spent constructing the verification
environment, including testbenches, testcases, and models mostly
manual with some automation.
- Test execution is the time spent running tests; this
time is usually reduced by increasing raw performance.
- Interpreting test results and debugging is the time spent
finding and fixing nonworking tests (mostly manual).
Leveraging point tools to create a single, cohesive methodology,
referred to as unified verification, is also frequently discussed
among verification professionals.
Three Components of Verification
A unified methodology must provide not only best-inclass point tools
in each area, but also complete interoperability among the three components
of SoC verification:
- Verification platform
- Hardware verification tools and techniques
- Embedded system software testing and debugging
Verification Platform
The verification platform, also called the execution engine or
virtual prototype, is the method used to execute the hardware design
description. The hardware design process consists of describing
the hardware using one of the two common hardware description languages,
Verilog or VHDL, then executing the HDL representation using a verification
platform. SoC commonly uses four platforms:
- Logic, or software, simulation
- Simulation Acceleration
- Emulation or in-circuit emulation
- Hardware Prototyping
Each platform has specific debugging techniques, each with its
own set of benefits and limitations. Methods range from the slowest,
with the most thorough debugging, to the fastest, with the least
thorough debugging. Here are brief explanations of how these methods
work:
- Logic, or software, simulation refers to using an eventbased
simulator to propagate input changes through a design until a
steady state condition is reached. Software simulators run on
workstations and describe the design and testbench using Verilog
or VHDL.
- Simulation Acceleration refers to the process of mapping
a design's synthesizable parts into a hardware platform; this
increases performance by evaluating the HDL constructs in parallel.
The nonsynthesizable parts are not mapped into hardware, but run
in software simulation. The software simulator works with the
hardware platform to exchange simulation data. Moving simulation
events from the software simulator to the hardware platform increases
performance; final performance is determined by the percentage
of simulation left running in software simulation.
- Emulation refers to the process of mapping an entire
design into a hardware platform; this significantly increases
performance. The hardware platform runs at full speed because
no there is no required connection to the workstation.
- In-Circuit Emulation refers to using external hardware
coupled to a hardware platform to provide a more realistic environment
for the design being simulated.
This hardware commonly takes the form of circuit boards, sometimes
called target boards or a target system, and test equipment cabled
into the hardware platform. Emulation without the use of any target
system is defined as targetless emulation.
- Hardware Prototyping refers to constructing custom hardware
or using reusable hardware (breadboard) to create a hardware representation
of a design. A prototype can be constructed faster than the actual
product, by making tradeoffs in product requirements, such as
performance and packaging, for example, substituting programmable
logic for ASICs.
Hardware Verification
Hardware verification describes the tools and techniques used to
determine if a hardware design is operating correctly. An entire
industry provides products that augment the verification platform
to help engineers develop tests and interpret the results. Special
hardware verification languages (HVLs) have been designed to improve
efficiency and verification quality. Other commonly used tools are
code coverage, lint tools, and debugging tools to visualize results,
such as waveform viewers.
2002 saw the widespread introduction of assertions as a way to
document a designer's assumptions and design properties. [1] Assertions
are a powerful tool to crosscheck a design's actual versus intended
behavior. Verification and system engineers can use assertions to
formally specify the intended behavior of a system.
This year, as SystemVerilog and SystemC evolve, there will surely
be growth in design and verification languages.
Embedded System Software
The final test for a hardware design is to correctly run embedded
system software. While not a guarantee that all bugs are resolved,
this means the design is fairly healthy. HW/SW co-verification provides
significant benefits:
- Software engineers have much earlier access to the hardware
design, letting them develop and test software concurrently with
hardware design and testing. Doing this in parallel reduces design
time, compared to the serial method of waiting for prototypes
to begin software testing. Also, the earlier a software team starts,
the better their understanding of the hardware.
- Co-verification provides additional stimulus for a hardware
design; it can even provide the true stimulus occurring in the
embedded system. This improves hardware verification, compared
to a contrived testbench that may not represent real system conditions.
By running co-verification, a wide range of softwareand hardware-related
problems can be resolved prior to silicon, such as register map
discrepancies, problems in boot code, errors in DMA controller programming,
RTOS boot and configuration errors, bus pipelining problems, and
cache coherency issues.
Co-verification requires that software engineers have accurate
microprocessor models and software debugging tools as early as possible
and a verification platform with optimal performance and debugging
for working with hardware engineers.
Here are the five types of embedded system software, in order of
increasing software content (lines of code):
- System initialization software and hardware abstraction layer
(HAL)
- Hardware diagnostic test suite
- Real-time operating system (RTOS)
- RTOS device drivers
- Application software
Matching Software with Platform
Matching software with platform is a major source of confusion, as
shown in Figure 1. With five types of software and four verification
platforms, where should the connections occur? Which type of software
should be run on which type of platform? Are all platforms required?
Figure 1. Methodology Confusion
System Initialization and HAL
Writing and testing processor initialization software, the first
software coding task, includes configuring operating modes and peripherals
(cache configuration, memory protection unit (MMU) programming,
interrupt controller configuration, timer setup, DRAM initialization).
The hardware abstraction layer (HAL), the next layer, works with
initialization code to provide a common interface for higher-level
software to hardware-specific functionality after the system is
initialized. The HAL abstracts the underlying processor architecture
hardware and platform to a level sufficient for the RTOS kernel
to be the platform.
Diagnostic Suite
When the initialization software and HAL are stable, the next phase
of software development is to develop a detailed test suite for
the hardware design. In the past, this was usually a hardware testbench.
While testbenches are still needed to provide stimulus for external
interfaces, such as networking protocols, the software is now the
testbench for the CPU core bus. A comprehensive set of diagnostic
tests should be developed to verify each subsystem and peripheral,
starting with the memory subsystem, then interrupt testing and other
IP blocks, such as timers, DMA controllers, video controllers, MPEG
decoders, and other specialty hardware. Most of these tests are
not included in the final product, but build the case for solid
hardware design. Creating these tests gives software engineers an
understanding of the hardware and of hardware specifics in a more
secluded environment.
Real-time operating system (RTOS)
The first assumption of an RTOS engineer is that the hardware is
stable, which is true if the diagnostic suite was done well. Initial
RTOS work consists of simply getting it to boot on the platform.
The amount of work required for the RTOS depends on how standard
the platform is and how well the HAL was designed. During the initial
porting phase, device drivers for application-specific hardware
may be missing, but the RTOS can still boot.
Device Drivers and Application Software
When the platform is complete, it is time to test device drivers
and application software. At the application level, hardware is
assumed correct and becomes more like workstation programming. If
the application crashes, it can be safely assumed it is a software
problem, not something wrong with the hardware. Applications usually
want to interface to real network traffic, see things on the screen,
and use the pointer or mouse. During application development, hardware
and lower-level software bugs are rare, and software engineers are
focused on providing robust applications with differentiating features
for end users.
Software and Hardware
Perspectives
The following sections present a brief review of the different perspectives
of software and hardware engineers.
Software Engineer's View
To the software engineer, the entire world revolves around the
programming model that is,
Programming model is a model used
to provide certain operations to the
programming level above and requiring
implementations on all of the architectures
below. [2]
More practically, a programming model for a microprocessor consists
of the CPU attributes necessary to abstract the processor for software
development. For example, the programming model of an ARM9E-S implements
the ARM v5TE instruction set, which includes the 32-bit ARM instruction
set and the 16-bit thumb instruction set [3]. Also included are
CPU operating modes, memory format, data types, general purpose
register set, status registers, and interrupts and exceptions. All
of these details are important to a software engineer.
Beyond the microprocessor, software engineers are interested in
the memory map for the embedded system. For a 32-bit address space,
4 GB of physical memory addresses can be accessed. All embedded
systems use only a subset of this physical address space, and the
memory map defines the location in the address space of various
types of memory and other hardware control registers. The memory
map may also define what happens if addresses are accessed where
no physical memory exists.
Types of memory used in an embedded system are ROM to hold the
initial software to run on the CPU, flash memory, DRAM, SRAM for
fast data storage, and memory- mapped peripherals. Peripherals can
be any dedicated hardware programmable from software, which can
range from small functions, such as a UART or timer, to more complex
hardware, such as a JPEG encoder/decoder.
In summary, a software engineer's view of an embedded system includes
a microprocessor programming model, a memory map, and individual
hardware control registers. This information, the ultimate authority
for all software development, is available in the form of technical
manuals on the microprocessor, along with the systemspecific memory
map supplied by hardware engineers.
Hardware Engineer's View
Hardware engineers have a different view of an embedded system:
the bus interface is most significant, and the microprocessor's
operation is much less important. For a hardware design to work
correctly, the logic connected to the microprocessor must obey all
rules of the bus protocol; if these rules are obeyed, the details
of the software tasks are not important. To hardware engineers,
the microprocessor is nothing more than a bus transaction generator.
All microprocessors use some type of protocol to read and write
memory. To a hardware engineer, the microprocessor is viewed as
a series of memory reads and writes. used for fetching instructions,
accessing peripherals, doing DMA transfers, and so on, but ultimately,
they are only a sequence of reads and writes on the bus. For years,
hard-ware engineers have used a bus functional model (BFM) to abstract
the microprocessor into a model of its bus; this is now described
as transaction-based verification, since it views the microprocessor
as a bus transaction generator.
Co-Verification Methodology
A good co-verification methodology requires:
- A single platform that provides logic simulation, simulation
acceleration, and in-circuit emulation
- Application-specific solutions for co-verification and transaction-based
verification
Considering an SoC with an ARM microprocessor, hardware engineers
are interested only in CPU bus transactions, which require a transaction-based
interface that works well with the verification platform used for
logic simulation, acceleration, and emulation. Software engineers
require good CPU models and debugging tools. For each of the five
different types of software, they prefer either a software or hardware
model of the ARM CPU. The three primary verification platforms and
the three representations of the ARM microprocessor form a matrix
of nine modes of operation, as shown in Figure 2.
Figure 2. Verification Operating Matrix
The following sections show how each software type can be executed
using either an ARM CPU software or hardware model and one or more
verification platforms.
System Initialization and HAL Development
Many complex SoC projects use only a full-functional model of
the microprocessor core in a logic simulator to write and debug
the code. Software debugging with waveforms requires an expert who
understands hardware and software and can disassemble instructions
using instruction fetches on the data bus.
Again considering the ARM SoC, the ideal debugging solution for
early development of system initialization and HAL code would be
a cycle-accurate instruction set simulation model tightly coupled
to a logic simulator containing the SoC hardware design. Software
engineers would have interactive graphical software debugging to
single step through the code and verify register and memory contents
with flexibility and control. Simulation performance would be less
important because the code must be verified line-by-line, and the
number of lines of code is relatively small. This situation is labeled
as box 2 in Figure 2.
Diagnostics
During the development of diagnostic tests, the logic simulator
becomes the bottleneck of the verification environment. As tests
run longer and the number of tests increases, it becomes more difficult
both to verify the entire hardware design and to continue to run
old tests as hardware and software errors are fixed. This phase
is also most crucial as most hardware bugs are found at this time.
The best solution uses simulation acceleration to increase performance
beyond that of an ordinary software simulator. A simulation environment
running at 10 to 100 Hz is not fast enough; also, memory optimization
techniques commonly used by co-verification tools are not useful
since the main purpose of diagnostics is hardware verification.
A simulation acceleration system running at speeds of 1 to 10 kHz
is the ideal platform for simulation performance and debugging.
Simulation acceleration with the ARM software model is labeled as
box 5 in Figure 2.
RTOS and Device Drivers
The initial RTOS port is a good place to take advantage of memory
optimizations commonly used in co-verification, such as software
memory models. These optimizations retrieve instructions at a rate
much faster than the rate of logic simulation, which results in
a less-detailed simulation of the ARM SoC, but increased performance.
Since the instruction fetch path is well verified, using memory
optimizations makes sense, instead of returning to the diagnostic
test suite to workaround a low-logic simulator. The initial RTOS
boot requires box 5 in Figure 2.
When the RTOS is booted and stable with selected device drivers,
as shown in box 8, a faster method, such as in-circuit emulation,
can be used in the future. The number of hardware bugs is small,
so increased performance is worth the tradeoff in hardware debugging.
This shifts the focus of a software engineer from box 5 to boxes
6 and 9.
Application Software
Application software requires the highest performance and possible
stimulus from other sources, such as graphics, I/O interfaces, such
as USB, or networking, which makes in-circuit emulation (ICE) the
ideal fit. Initial bring up for ICE 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, interfaces and test equipment
are assembled in the lab for ICE. This represents a shift from box
3 to box 9 in Figure 2.
Testbench Development
Hardware engineers focus on assuring correct functionality of
bus interface logic connected to the microprocessor. By not requiring
a full-functional model (FFM) and software to run on the CPU, a
bus functional model (BFM) does this more efficiently. A variety
of BFMs are available from IP companies, EDA vendors, and microprocessor
suppliers; unfortunately, all were created with C/C++, hardware
verification languages (HVLs), or behavioral Verilog or VHDL. While
fine for logic simulation, they are not efficient for simulation
acceleration or emulation.
Co-verification methodology requires a BFM that runs well for all
phases of verification, from the start of a project, as shown in
box 1 in Figure 2, moving to acceleration and emulation for directed
and random testing, as shown in boxes 4 and 7. To achieve this,
a transactionbased interface to a synthesizable BFM for the CPU
bus is ideal. By operating at the transaction level, communication
is minimized between the testbench and the verification platform.
A synthesizable BFM and a transactionbased interface to the verification
platform optimize performance, while simultaneously allowing for
the use of C/ C++ or HVLs to create testbenches. A BFM that provides
consistent performance from simulation to emulation, while following
the industry trend of verification automation, is critical to a
unified verification methodology.
Matrix Coverage Not Enough
If all nine boxes in Figure 2 were covered by different tools for
logic simulation, acceleration and emulation, and point tools were
used for co-verification, bus models, and bus protocol checking, you
would still need to integrate the tools: more than coverage, interoperability
is required.
Communication Gap
A common communication medium for problem resolution is required for
co-verification. Debugging a co-verification issue may take longer
than running the test, because problem isolation involves multiple
teams withdifferent expertise working in a lab environment and viewing
verification data in different formats. Compounding the problem, software
and hardware teams debug using different techniques and view problems
from different perspectives. Software teams work with software models
and debug using software source-level tracing and memory and register
viewing. Hardware teams work with hardware design languages and debug
by viewing waveforms with history values associated with simulation
times of read and write operations. As a result, when software teams
detect a potential hardware problem, it cannot be described in hardware
terms (time and signal value), nor is it easy to transfer an independent
testcase to hardware engineers for further review. This conflict can
be resolved by using a tool, such as the Co-Verification Debugger.
Transaction-Based
Verification
Transactions with simulation timestamps are the communication link
between software and hardware, as shown in Figure 3. The transaction
process flow begins when software engineers initiate bus transactions
(register and memory read/write operations), which are then driven
into the hardware design block with time and signal values.
Hardware engineers, already familiar with transactionbased techniques
for testbench development, benefit from a transaction-based channel
to simulation, acceleration, and emulation with a common interface
to synthesizable models for the AHB protocol for ARM designs. This
allows all types of tests - block-level tests, directed system-
level tests, random tests - to be run without any changes to testbenches
or models as performance requirements vary. Verification and hardware
engineers benefit from boxes 1, 3, and 5 in Figure 2.
Software engineers already have a good understanding of transactions
and how register and DMA operations translate into bus transactions.
The new Co-Verification Debugger enables the transparent capture
of transactions to correlate lines of software with time values
and to package transactions for use in the software or hardware
view.
Figure 3. Transactions Link Software and
Hardware
Co-Verif. Debugger/Transaction
Instrument
The Co-Verification Debugger implements transaction capture and the
replay of transactions for both hardware and software engineers, serving
as a common communication medium. By capturing transactions during
a software in-circuit emulation session, a software engineer can stop
at a particular line of code, get the simulation time, and send a
set of transactions to the hardware team to debug at the exact emulation
time that the error occurred.
The Transaction Instrument captures bus transactions for use with
Instant Replay, the playback mechanism that displays captured transactions
within a self-contained environment, as shown in Figure 4. The Co-Verification
Debugger takes the captured bus transactions from the Transaction
Instrument and associates the emulation time value with the software
line that activated the transaction.
Figure 4. Transaction Instrument
Instant Replay of Software
Execution
Software engineers are concerned only with how an ARM CPU executes
instructions. A long diagnostic test may run for hours, even with
simulation acceleration. If the test fails, a software engineer does
not want to guess where to put a breakpoint, restart the test, and
debug interactively. Rather, they want to run a single simulation
and save a compressed file containing bus transactions at the processor
interface. Memory transactions, including address, data, and simulation
timestamp along with interrupt information, would be recorded into
this file. At completion of simulation, the engineer could start the
ARM CPU software model and software debugger and re-run the execution
sequence; however, instead of interacting with hardware simulation,
the results would be read from the recorded file; this bus interface
playback replicates the exact software execution sequence, as shown
in Figure 5. Because the simulation now runs at MHz speeds, the engineer
can re-run the software as often as needed. The simulation timestamp
is also provided at any time to correlate software and hardware execution.
This record and playback methodology is a good way to debug long simulation
tests that make interactive debugging unproductive.
Figure 5. Instant Replay for Software Execution
Instant Replay of Hardware
Execution
When a diagnostic developer identifies a true hardware problem, hardware
engineers would rather not start a software debugger, load a program,
and run it to reproduce the problem (hardware engineers care only
about bus transactions). Ideally, software engineers would pass bus
transaction stimulus to hardware engineers, so the test is an AHB
transaction set, instead of an ARM CPU model, enabling transaction-based
verification techniques. For all diagnostic tests, a history of transaction-based
stimulus files can be saved as a set of regression tests. These tests
can be modified and augmented to test what-if scenarios on the bus.
Instant Replay for hardware is shown in Figure 6.
Figure 6. Instant Replay for Hardware Execution
Conclusion
Effective and efficient co-verification methodology for SoC verification
requires a single platform with logic simulation, simulation acceleration,
and in-circuit emulation and application-specific solutions for co-verification
and transaction-based verification. Combining point tools does not
provide interoperability between platforms and application of transaction-based
verification and HW/SW coverification. Transactions and simulation
timestamps give hardware and software teams a way to pinpoint the
exact cause, time, and location of problems and provide standalone
testcases to replicate problems in each environment.
References
[1] Jason Andrews, "Assertion Processo," 2002
[2] ACM Computing Surveys, Skillicorn and Talia, 1998
[3] ARM9E-S Technical Reference Manual (Rev 2), ARM Limited,
2002
|
