One of the most significant challenges facing verification teams using prototypes
based on field-programmable gate-array (FPGA) is understanding the prototyped
system’s internal behavior when it fails to perform as expected. A key
factor with regard to analyzing and debugging these designs is the difficulty
in observing internal signals.
Today’s state-of-the-art FPGAs provide tremendous capabilities with
regard to both capacity and performance. Members of the Xilinx Virtex-5 family,
for example, can contain hundreds of thousands of logic cells that may be configured
as logic, RAM, or shift registers. Furthermore, this programmable logic can
be used with hard IP blocks, such as megabits of RAM and hundreds of 25-by-18
multiplier/DSP functions, all running at up to 550 MHz.
These devices, which may also include multiple hard and/or soft processor
cores and associated peripherals, can be used as powerful prototyping platforms
for ASIC and system-on-a-chip (SoC) components.
New tools, improved methodologies, and higher levels of abstraction are helping
engineers to experiment with different macro- and micro-architectures, as well
as increase their overall design productivity.
In terms of verification, the
sheer size and complexity of these designs coupled with their dramatically increasing
software content makes FPGA prototyping an appealing option, both to increase
verification throughput via hardware acceleration and to provide an early software-development
platform. However, successful prototyping requires due consideration of what
happens when the device doesn’t operate as expected and the engineer must
debug.
As was previously noted, a key factor with regard to analyzing and debugging
prototyped designs is the difficulty in observing internal signals. The problem
is that there may be tens of thousands of these signals, but only a limited
number of input/output (I/O) pins on the device by which these signals may be
exposed to the outside world.
Furthermore, the act of observing internal signals impacts both design and
verification. Selecting the appropriate signals to monitor is a non-trivial
task, and modifying the design to observe these signals consumes engineering
and FPGA resources. Also, it takes time to capture, dump, and record any signal
values that are being observed.
Depending on the approach used, the tasks of accessing and analyzing signals
internal to an FPGA can be complex, tedious, and time-consuming. Having said
this, the overall process can be broken down into just five main steps:
1. Determine a set of signals to be observed.
2. Modify the design to observe the selected signals.
3. Observe and retrieve data while the FPGA is operating in-situ.
4. Map the retrieved data to the original RTL representation.
5. Compute data for additional signals that were not in the initial observed
set.
This article first discusses the limitations of existing techniques with regard
to performing these activities. Next, an emerging visibility-enhancement technology
is introduced; this new approach includes the auto-interactive selection of
a reduced set of signals to be observed coupled with “data expansion”
techniques that can fill in the “missing pieces,” those being unobserved
signal values.
Limitations of Conventional Techniques
As just mentioned, locating, analyzing, and debugging problems in FPGAs using
traditional approaches can be extremely tedious and time consuming. The reasons
for this can be summarized in brief.
The first step in the process is to decide which signals need to be observed
(captured and dumped). But any increase in the number of signals to be observed
increases the logic resources required to capture them and the time taken to
convey their data values to the outside world. For both of these reasons, it’s
possible to observe only a limited number of signals at any particular time
(for any particular verification run, that is).
The problem here is that selecting the best signals to monitor is a non-trivial
task. For example, a register that appears to be a prime candidate for monitoring
may actually provide limited visibility into the design's operation. By comparison,
a seemingly innocuous register may provide a great deal of visibility into the
design.
Once a set of signals to monitor has been selected, the design must be modified
so as to allow the signals to be observed directly, or to allow them to be captured
and dumped to the outside world. In the broadest sense, this is referred to
as Design-for-Debug (DFD). In the case of the former approach, the design may
be augmented with multiplexers and control logic that can be used to present
selected internal signals to the outside world via primary output pins. Generally
speaking, implementations of this approach tend to be homegrown and ad hoc,
and they require significant effort to gain limited insights as to what is happening
inside the chip.
An alternative technique is to use internal logic analyzers (ILAs). These
may be homegrown, but are more commonly provided (along with a corresponding
configuration application) by the FPGA vendor or by a specialist third-party
vendor. Each ILA is constructed using a combination of configurable logic cells
and RAM blocks. The control logic for the ILA is designed in such a way as to
allow a specified trigger condition (or combination of trigger conditions) to
initiate the capture of one or more specified signals and to store attributes
associated with these signals, such as data values and time stamps, in on-chip
memory. At some stage, these values have to be dumped to the outside world.
A common technique in this case is to use the chip’s JTAG port.