1 Reasons Driving Change in FPGA Debugging Technology The reprogramming capability of FPGAs is a key advantage in the functional debugging of hardware designs. In the early days of using CPLDs and FPGAs, when a design was found to be malfunctioning, engineers would use the “debug hook” method. They would route the internal signals of the FPGA to pins and then use an external logic analyzer to capture data. However, as designs have become more complex, this method has become 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 shown in Figure 1. Additionally, in complex designs, 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 rather than just a few. A common technique is to implement a wider internal bus to achieve high system throughput in larger FPGAs. If there is a suspicion of bad data on an internal 32-bit bus, it is difficult to pinpoint the issue using just a few I/O pins. Third, there is often a need to test complex functionality within the system. In such cases, access to some I/O may be limited during in-system debugging. New types of packages also restrict access to FPGA pins. System speed is also a concern, as probe connections may introduce performance degradation or noise. Finally, a key factor driving the change in FPGA debugging methods is the introduction of new tools that utilize internal or embedded logic analyzers. Having these tools can yield optimal results, rather than using the same methods as previous tools. Resources, static parameters, and dynamic parameters often constrain both 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 in use for decades. The biggest advantage of external logic analyzers is their ability to store large amounts of signal information or track data. The configuration is 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 in one of two ways. The first method is to directly send the signals to I/O pins for observation. Depending on the type of FPGA package, accessing I/O pins can be challenging. Board designs intended for debugging using this method need to include 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 involves inserting a core that routes 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 approach is that signals must be captured in real-time by the external logic analyzer, and multiplexing significantly reduces the likelihood of quickly capturing signals. For this reason, 2x or 4x multiplexing schemes are often used. This means that 32 I/O pins can now support 64 or 128 signals. While this represents a significant improvement, there are still limitations, such as debugging wide buses. Once signals are connected to the external logic analyzer, trigger and data capture conditions must be set. The constraints of using external logic analyzers include limited signals, high-speed trigger logic, and large tracking memory. Most logic analyzers use state machine triggering mechanisms. Users specify a value to wait for that signal, then capture that data or enter another state to look for different conditions. These signals are static, but various conditions are dynamic and can change at any time. Given the constraints, this method is effective. Because the number of signals is limited, the number of operations is reduced in the case of signal combinations. However, tracking memory is relatively large, and it is common to try to find a close observation point before capturing a large amount of data to identify the issue. 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 set trigger conditions in software using a PC and access the FPGA via JTAG. Once the logic analyzer soft core captures the data, it returns the information to the PC through JTAG, where the designer can observe the data. The complexity of trigger signals and the size of tracking memory limit the number of signals. In most cases, designers can observe hundreds to thousands of signals. Trigger resources are constrained by the FPGA, namely unused logic and RAM. Some implementations of tracking memory require RAM. Others may require RAM or LUT. However, the required tracking memory is greatly reduced compared to using external logic analyzers, typically in the thousands of bits compared to millions of bits. Triggering and data capture occur at full design speed because signals do not need to be multiplexed off-chip. When using external logic analyzers, signals must be statically defined. Changing signals often requires the FPGA to be re-executed, although some tools offer the ability to change part or all of the connected signals by only adding FPGA routing. During debugging, most implementations dynamically change part or all trigger conditions. However, the complexity of trigger changes depends on the tools used. The more different the signals, the smaller the available memory. To achieve optimal results, different triggering 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 timing of EAV (end active video), then look for the specific line number associated with the data, and finally find the timing of SAV (start active video). Finally, based on the corresponding pixel in the line, the byte count is calculated, as shown in 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 data. To understand how this is done, one must examine the specific implementation process. Lattice’s Reveal hardware debugger uses trigger units and trigger representations to determine trigger points. The trigger unit is a comparator, and the trigger representation allows the trigger unit and sequence values to combine. For this SDI example, three trigger units are used to define the EAV and SAV sequences, with another trigger unit for the line number, and finally a counting statement before data discovery for waiting. The established trigger example 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 changed dynamically. 
Figure 3 Example of Trigger Setup 4 Conclusion Engineers will continue to use external logic analyzers as they are valuable for analyzing system-level functionality. However, debugging internal FPGAs requires connection to the circuit board, and the number of signals is limited. Internal logic analyzers offer great freedom in the number of available signals, but are constrained in triggering logic and tracking memory. However, careful use of triggering options allows internal logic analyzers to start capturing data at precise times, maximizing available resources. In this example, the complex implementation of analyzing specific pixels (lines and words) in SDI video signals is broken down into simple elements, which enhances efficiency. This example only scratches the surface of the use and applications of internal logic analyzers. As the complexity of FPGA designs continues to increase, internal logic analyzers and similar tools are becoming favored by designers for functional verification and debugging.
Welcome to join the Zhixin Technology FPGA WeChat Learning Group, where there is a group of outstanding FPGA engineers, students, and teachers. The atmosphere for FPGA technology exchange and learning is strong here, with mutual sharing and assistance. Invite your friends to join!
Click to view your best look