XpertT:
Software Debugging Targeted at Embedded Software Designs
Table of Contents
Overview
The term hardware/software (HW/SW) co-verification was coined in
the mid 1990s to describe a process that allows embedded system
software to be executed on a simulated representation of the hardware
design. The simulated representation of the hardware has usually
meant a Verilog or VHDL description running in a logic simulator.
The concept of logic simulation has since been extended to allow
for other representations of the hardware that are not the final
implementation, including logic emulation systems or other prototyping
methods. However, none of these solutions has focused on software
debugging.
Beyond execution of hardware and software,
a true co-verification product also provides control and visibility
for both software and hardware engineers and uses the types of tools
they are familiar with, at the level of abstraction they are familiar
with. This means that for a product to be considered a true co-verification
product it must provide -- at minimum -- software debugging using
a source code debugger and hardware debugging using waveforms. A
full-functional model of a microprocessor fetching and executing
code in a logic simulator is not co-verification if the only means
of debugging software are waveforms and assembly language traces.
Current Methods for Debugging
Software
Many complex system-on-a-chip (SoC) projects are using nothing more
than a full-functional model of the microprocessor core in a logic
simulator to verify the design. Software debugging with waveforms
requires a true guru who understands hardware and software.
The most common tool used by software engineers
is the microprocessor evaluation board. This board has a processor,
memory, and other peripherals like UARTs and Ethernet connections
to test software. Unfortunately, this configuration does not include
a design's custom logic but at least it does run fast and it gives
software engineers a way to verify some of their code and learn
more about the processor.
Projects that are too large for software-based
logic simulation have long turned to logic emulation systems to
gain speeds of up to 1 MHz and access to hardware interfaces to
real world stimuli. More recently, a need has developed to run at
speeds of 20 MHz or more. This has fueled the use of prototyping
for higher speeds at the expense of visibility.
No matter what kinds of verification methods
are deployed, there are trade-offs. No one has yet built the ideal
product that provides desired performance, flexibility, ease-of-use,
and cost.
The Debugging Loop
A typical debugging project will first partition the system into
hardware and software and follow with a register map specification,
usually written with a word processor, that describes the software
interface to the custom hardware. As time passes, these registers
are changed, but the specs are not updated. The written descriptions
are either incorrect or not clearly understood by the software engineers.
Hardware and software engineers have different concepts and methods
for describing the system functionality. For example, software engineers
don't usually have a concept of logic signals being "active low."
To debug these systems, the process starts
when software engineers compile code and prepare memory image files
for execution. Because they are unfamiliar with logic simulation
and emulation tools, they pass the image file over to the verification
engineers who run the test.
When the test fails, the verification engineer
tries to isolate the problems, and presents the result to a design
engineer who is familiar with the specific part of the design that
may have a problem. The design engineer analyzes and fixes the problem
and runs the test again.
If the problem is in the software, then the
software engineer must be called in to inspect the problem. For
the software engineer to debug the problem, he needs the help of
the verification engineer who understands waveforms from the simulation
and can correlate it to the software.
Finally, the software engineer generates a
fix, and the process starts all over. This iterative cycle of throwing
results over the wall among the three groups, struggling to work
together, can really slow down the progress of the project.
Co-verification tools must tighten this debugging
loop by allowing all groups to work independently and concurrently
as much as possible. Tools that empower software engineers to find
and fix problems with less intervention by verification and hardware
design engineers are needed.
Xpert Addresses the Limitations
of Existing Co-Verification Solutions
One drawback of co-verification for software engineers is that they
can no longer run their code at real-time speed. However, the benefits
of testing software much earlier in the design process, long before
the prototype is available, within the context of the complete SoC
design, has outweighed the performance limitations of co-verification.
Xpert delivers a single integrated system
with access to accelerated embedded processor models. The combination
of the fastest hardware verification possible and a debugging environment
that meets the needs of software engineers eliminates the logic
simulator bottleneck. Xpert leverages Axis' ReConfigurable Computing
(RCC) technology and extends the capabilities of the XciteŽ and
XtremeŽ
products to enable better software debugging for complex SoC projects.
Simply Better Software
Debugging
When running co-verification, the most important requirement remains
the ability to effectively debug the software as it will run on
the hardware system. For example, software engineers should never
have to view a waveform to see what happened. In addition, a capability
that offers something more than interactive debugging is necessary.
To bridge the gap between the performance expectations of software
engineers and the accuracy and visibility requirements of hardware
engineers, a solution that makes the best trade-off between these
requirements is needed.
Instant Tracing of Software
Code Execution in One Debugging Window
Hardware designers are accustomed to using batch-mode simulation
and post-processing debugging methods to debug their designs. By
using post-processing debugging, designers can view logic simulation
results in a waveform viewer or source-code debugger, after the
simulation has completed.
Xperts' Instant TraceT feature allows software
engineers to take advantage of post-processing debugging capabilities.
With Instant TraceT, software engineers can step through software
execution in a post-processing mode, after a long simulation is
completed. It provides a faster way to debug the software execution
of all processors, since running interactive debugging on a logic
simulation can take a long time and is not very effective. Even
with RCC performance, which is orders of magnitude faster than software
logic simulators, the simulation could take a few hours when running
a long test. It is not feasible to sit by the keyboard and wait
for failures to occur, and then try to set software breakpoints
in an interactive simulation.
Instant Trace allows the history of the simulation
to be saved so that software engineers can quickly isolate problems,
after the simulation has been completed. Instant Tracing is done
at the source code level in a way that software engineers are familiar
with. It correlates the program execution with the simulation timestamps
so that when a problem is identified, timestamps can be communicated
to the hardware engineers. After all, the simulation timestamp is
the only true means of communication between software and hardware
engineers.
Today, many SoCs include multiple processors,
either multiple copies of the same type or a number of different
types of processors. Whether they are homogenous or heterogeneous
models, current debugging solutions do not provide a correlated
view of all the processors. Ideally, engineers would like to trace
how the code execution moved from one processor to the next without
looking at multiple debugger windows associated with each processor.
Also, when using interactive debugging methods with a prototype
system, setting a breakpoint in one processor does not necessarily
stop the execution of other processors. This makes controlling the
software execution for debug much more difficult.
Since Instant Trace is based on post-simulation
data, the software execution trace between all the processors can
be viewed in a single debugging window. Software engineers can easily
follow the execution thread to see which processor executed an instruction
at a particular time, throughout the entire simulation.
Instant Resuming of Software
Execution from Any Point in Time
Some problems can be identified and solved using the Instant Trace
technique alone, similar to the way in which print statements can
find software problems. Other problems will require more debugging
to find the exact cause of the problem. For these problems, Xpert
provides a capability called Instant ResumeT, which is based on
the same existing RCC technology that provides the VCD-on-Demand
feature for hardware engineers.
As simulations are run, RCC stores checkpoints
on the disk of the workstation that contain values for all of the
memory elements of the design. Hardware engineers use these checkpoints
to regenerate waveforms for any window of simulation time. Checkpoints
can also be loaded into RCC to resume simulation from a specified
time.
This same technology can be applied to software
debugging. When software engineers have identified a general area
where the problem occurred, they can resume an interactive debugging
session at that specified time. This enables software engineers
to inspect additional memory locations and control execution to
get a detailed view of how and when the problems happened. Best
of all, it does not require the simulation to be started again from
the beginning, saving valuable debug time.
The combination of Instant Trace and Instant
Resume provide a logical software debugging flow to run and trace
software problems, resuming at a point where the problem is identified.
This flow is not available in any other co-verification tool. The
flow maximizes the use of Axis hardware by efficiently using it
to run tests and perform the majority of debugging using post-processing
methods.
Conclusion
Today, more and more focus is being placed on system-level design,
viewing the total project as a complete system instead of the individual
parts: chips, boards, chassis, and software. Managers are looking
for ways to shorten the project schedule and increase confidence
in the design. At the verification level this translates into selecting
the best tools to build a productive environment for both hardware
and software engineers.
Axis' Xpert product family provides a single
integrated system for logic simulation, simulation acceleration,
and system emulation along with the concurrent debugging capabilities
of both hardware and software. Xpert deliver the verification environment
needed for the next generation of designs.
|
