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.
Reprints
