Debugging FPGAs with an internal logic analyzer

Reasons driving the change in FPGA debugging techniques

The reprogrammability of FPGAs is a key advantage when debugging the functionality of hardware designs. In the early days of CPLDs and FPGAs, engineers used a "debug hook" approach if they found that the design did not work properly. First, the internal FPGA signal to be observed was connected to the pin, and then the data was captured with an external logic analyzer. However, when the complexity of the design increased, this approach was no longer suitable for several reasons. The first is that the number of pins on the device has slowly increased while the functionality of the FPGA has increased. Therefore, the ratio of available logic to I/O has decreased, see Figure 1. In addition, when the design is very complex, there are usually only a few free pins left after the design is completed, or there are no free pins at all that can be used for debugging.

Figure 1 LUTs/available I/Os in a Lattice FPGA

Second, the complexity of today’s designs often requires observation of many signals, not just a few. A common technique is to implement wider internal buses to achieve high system throughput in larger FPGAs. If you suspect bad data on an internal 32-bit bus, it can be difficult to pinpoint the problem using just a few I/O pins.

Third, you often need to test complex functions in a system. In this case, access to some I/Os may be limited when debugging in the system. New types of packages also limit access to FPGA pins. System speed is also an issue, as probe connections may cause performance degradation or noise signals.

Finally, a key factor driving the change in FPGA debugging methods is the availability of new tools that use internal or embedded logic analyzers.

Having these tools gives you the best results, rather than using the same methods as previous tools. Resources, static parameters, and dynamic parameters often constrain internal and external logic analyzers. This article compares the constraints of these two types of tools and examines how to best use an internal logic analyzer.

External Logic Analyzer Constraints

External logic analyzers have been used for decades. The biggest advantage of external logic analyzers is the ability to store large amounts of signal information or to trace data. Configurations vary, but most external logic analyzers can store megabytes of data. In order to use an external logic analyzer with an FPGA, the data signals must be brought off-chip. This can be done in one of two ways. The first is to bring the signals directly to the I/O pins used for observation. Depending on the package type of the FPGA, access to the I/O pins may be difficult. Board designs designed for debugging with this method use connectors, such as the MICTOR connector, that connect to the FPGA. However, this method is not very efficient because each signal requires an I/O pin.

The second method is to insert a core that can bring the signals to the I/O. The advantage of this method is that the core is designed to multiplex the signals to the I/O pins, allowing pin sharing. The limitation of this method is that the signals must be captured in real time by the external logic analyzer, and multiplexing greatly reduces the possibility of quickly capturing the signals. For this reason, a 2x or 4x multiplexing scheme is usually used. This means that 32 I/O pins can now support 64 or 128 signals. This is a great improvement, but there are still limitations, such as when debugging wide buses. Once the signals are connected to the external logic analyzer, the trigger and data capture conditions are then set up.

The constraints of using an external logic analyzer are limited signals, high-speed trigger logic, and large amounts of trace memory. Most logic analyzers use a state machine trigger mechanism. The user specifies a value to wait for this signal, then capture this data, or enter another state and look for different conditions. The signals themselves are static, but the various conditions are dynamic and can change at any time. Given the constraints, this method works well. Because the number of signals is limited, the number of operations is reduced in the case of signal combinations. However, the trace memory is relatively large, and it is common to try to find a close observation point, and then capture a large amount of data to find the problem.

Using an internal logic analyzer

Using an internal logic analyzer can be used to debug FPGA functions in the same way as an external logic analyzer. An internal logic analyzer uses one or more logic analyzer cores embedded in the FPGA design. The designer uses a PC to set the trigger conditions in software and access the FPGA through JTAG. Once the logic analyzer soft core captures the data, the information is returned to the PC through JTAG, and the designer can then observe the data. The complexity of the trigger signal and the size of the trace memory limit the number of signals. In most cases, designers can observe hundreds or thousands of signals.

Triggering resources are limited by the FPGA, i.e., unused logic and RAM. Trace Memory Some implementations require RAM. Others require RAM or LUTs. However, the trace memory required is much less than with an external logic analyzer, typically thousands of bits versus millions of bits. Triggering and data capture occur at the full speed of the design because signals do not need to be multiplexed off-chip in the FPGA.

With an external logic analyzer, signals must be statically defined. Changing signals often requires re-implementing the FPGA, although some tools offer the ability to change some or all of the connected signals by simply adding FPGA routing. During debug, most implementations dynamically change some or all of the trigger conditions. However, the complexity of the triggering varies depending on the tool used. The more distinct the signals, the less memory is available. Different triggering options drive the need to use the internal logic analyzer for best results.

An example of complex debug is finding a specific pixel in a SMPTE SDI HD display. In a specific case, it is necessary to find the EAV (end active video) timing, then find a specific line number associated with the data, and then find the SAV (start active video) timing. Finally, the number of bytes is calculated based on the corresponding pixels in the line, see Figure 2.

Figure 2 SDI HD data stream example

To debug this data you need to look for the timing of the values, then the special value, then the end of the sequence, and finally count the number of clocks before capturing the data. To understand how this is done, you must look at the implementation. The Lattice Reveal hardware debugger uses trigger cells and trigger statements to determine the trigger point. The trigger cell is a comparator, and the trigger statement allows the trigger cell and sequence value to be combined.

For this SDI example, three trigger cells are used to define the EAV and SAV sequences, another trigger cell is used for the line number, and finally a count statement is used to wait before finding the data. An example of the trigger setup is shown in Figure 3. This setup can be used to find any required number of lines and pixels, because the value and count of the line number trigger can be changed dynamically.

Figure 3 Example of trigger setup

Conclusion

Engineers will continue to use external logic analyzers because they are valuable when analyzing system-level functions. However, for internal FPGA debugging, the number of signals that can be connected to the board is limited. Internal logic analyzers provide a lot of freedom in the number of available signals, but are constrained in terms of trigger logic and trace memory. However, careful use of trigger options allows the internal logic analyzer to start capturing data at the precise time to maximize the available resources. In this example, the complex implementation of the specific pixels (lines and words) in the SDI video signal that need to be analyzed is broken down into simple elements, which improves efficiency. This example is just a glimpse into the use and application of internal logic analyzers. As FPGA designs continue to increase in complexity, internal logic analyzers and similar tools are gaining popularity among designers for functional verification and debugging.