1 Reasons for Changing FPGA Debugging Techniques

During functional debugging of hardware design, the reprogramming capability of FPGA is a key advantage. In the early use of CPLD and FPGA, if a design was found to be non-functional, engineers would use the “debug hook” method. They would first route the internal signals of the FPGA to the pins, and then use an external logic analyzer to capture the data. However, as the complexity of designs increased, this method became less suitable for several reasons. First, while the functionality of FPGAs has increased, the number of pins on the devices has grown slowly. As a result, the ratio of available logic to I/O has decreased, as seen in Figure 1. Additionally, when designs are complex, there are often only a few spare pins available after the design is completed, or there may be no spare pins at all for debugging.

Figure 1: LUT/Available I/O of Lattice FPGA

Second, the complexity of current designs often requires monitoring many signals instead of just a few. A common technique is to implement a wider internal bus to achieve high system throughput in larger FPGAs. If there is suspected bad data on the internal 32-bit bus, it is difficult to pinpoint the issue with just a few I/O pins.

Third, complex functionalities often need to be tested in the system. In such cases, access to some I/O during in-system debugging may be limited. New types of packages also restrict access to FPGA pins. System speed is also a concern, as probe connections may cause performance degradation or noise.

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

Having these tools yields better results compared to the previous methods. Resources, static parameters, and dynamic parameters typically constrain internal logic analyzers and external logic analyzers. This article compares the constraints of these two types of tools and examines how to best utilize internal logic analyzers.

2 Limitations of External Logic Analyzers

External logic analyzers have been used for decades. The main advantage of external logic analyzers is their ability to store large amounts of signal information or track data. Configurations are constantly changing, but most external logic analyzers can store megabytes of data. To use an external logic analyzer with an FPGA, data signals must be routed off-chip. This can be done using one of two methods. The first method is to directly send the signals to the I/O pins for observation. Depending on the packaging type of the FPGA, accessing the I/O pins may be difficult. Boards designed for debugging using this method need to use connectors, such as MICTOR connectors connected to the FPGA. However, this method is not very effective, as each signal requires an I/O pin.

The second method is to insert a core that can route the signals to the I/O. The advantage of this method is that the core is designed to multiplex signals to 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 significantly reduces the possibility of capturing signals quickly. For this reason, 2x or 4x multiplexing schemes are typically used. This means that 32 I/O pins can now support 64 or 128 signals. This represents a significant improvement but still has limitations, such as when debugging wide buses. Once the signals are connected to the external logic analyzer, trigger and data capture conditions must be set.

The constraints of using external logic analyzers are limited signals, high-speed trigger logic, and large amounts of trace memory. Most logic analyzers use state machine triggering mechanisms. Users specify a value to wait for this signal, then capture the data, or enter another state to look for different conditions. These signals themselves are static, but various conditions are dynamic and can change at any time. Given constraints, this method is effective. However, the number of signals is limited, reducing the number of operations in cases of signal combinations. But 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.

3 Using Internal Logic Analyzers

Internal logic analyzers can perform functional debugging of FPGAs just like external logic analyzers. Internal logic analyzers use one or more logic analyzer cores embedded in the FPGA design. Designers use a PC to set trigger conditions in the software and access the FPGA via JTAG. Once the logic analyzer soft core captures the data, it returns the information to the PC via JTAG, where the designer can observe this data. The complexity of the trigger signals and the size of the trace memory limit the number of signals. In most cases, designers can observe hundreds or thousands of signals.

Trigger resources are limited by the FPGA, specifically the unused logic and RAM. Some implementations of trace memory require RAM. Others require either RAM or LUT. However, the required trace memory is greatly reduced compared to using external logic analyzers, typically in the thousands of bits versus millions of bits. Triggering and data capture occur at full design speed because the signals do not need to be multiplexed off-chip.

With external logic analyzers, signals must be statically defined. Changing signals often requires the FPGA to be re-executed, although some tools provide the capability to only add FPGA routing to change part or all of the connected signals. During debugging, most implementations dynamically change part or all of the trigger conditions. However, the complexity of changes in triggering depends on the tools used. The more differences in signals, the smaller the available memory. To achieve the best results, different trigger options drive the need to use internal logic analyzers.

An example of complex debugging is finding a specific pixel in SMPTE SDI HD displays. In special cases, it is necessary to find the EAV (end active video) timing, then look for the specific line number associated with the data, and finally find the SAV (start active video) timing. Based on the corresponding pixel in the line, the byte count is calculated, see Figure 2.

Figure 2: Example of SDI HD Data Stream

To debug and find this data, it is necessary to look for the timing of values, then find special values, and finally count the clock cycles before capturing the data. To understand how this is done, it is essential to look at the specific implementation process. Lattice’s Reveal hardware debugger uses trigger units and trigger representations to determine the trigger points. The trigger unit is a comparator, and the trigger representation allows the trigger unit and sequence values to combine.

For this SDI instance, three trigger units are used to define the EAV and SAV sequences, another trigger unit for the line number, and finally a count statement before discovering the data to wait for. The example of the trigger setup is shown in Figure 3. This setup can be used to find any required line number and pixel, as the line number trigger values and counts can be dynamically changed.

Figure 3: Example of Trigger Setup

4 Conclusion

Engineers will continue to use external logic analyzers because they are valuable for analyzing system-level functionality. However, for internal FPGA debugging, the connection to the circuit board limits the number of signals. Internal logic analyzers provide great freedom in the number of available signals, but are constrained in terms of trigger logic and trace memory. However, careful use of triggering options allows internal logic analyzers to start capturing data at precise times, maximizing the available resources. In this example, the complex implementation of analyzing special pixels (lines and bytes) in SDI video signals is broken down into simpler elements, improving efficiency. This example only scratches the surface of the use and application of internal logic analyzers. As the complexity of FPGA designs continues to increase, internal logic analyzers and similar tools are favored by designers for functional verification and debugging.

Want to know more about FPGA? Here are some shared examples, ZYNQ designs. Follow our official account to explore.