Find out how to minimise development cycles and costs while significantly speeding time to market.
FPGA and SoC designers face many challenges to get their product into production. Typically, they start by evaluating the appropriate device for their design; then they implement the hardware description language (HDL) design, fit the device, and—finally—debug the entire FPGA before it can be brought into production.
The reality today is that, for many designs, particularly those in the industrial and embedded markets, any number of FPGAs will work. In most cases, the decision as to which FPGA vendor to choose comes down to experience with the development software. Although this should be a consideration, an even bigger factor should be the debug capabilities and support that is offered to speed the time to production. Today, many FPGA debug tools exist from vendors such as Altera, Lattice, Microsemi, and Xilinx, but there are a class of smarter debug tools that designers should consider when evaluating their future FPGA design strategy.
Debug basics—logic analysers
Every major FPGA vendor offers a logic analyser as a debug tool. This is a technique that uses internal FPGA logic elements and embedded block memory to implement functions. A designer can specify which signals to monitor and set up a trigger to tell the logic analyser when to start capturing data. After the logic analyser has been set up, the designer must rerun synthesis and place-and-route in order for the function to be incorporated into the design. After the design is recompiled and reprogrammed, the designer can begin to observe the logic signals captured by the logic analyser.
It is important to note that, because these signals need to be sampled, they are not capturing the real-time performance of the data. The logic analyser can only run at speeds that allow it to sample the data and save the values to internal memory. Because the design has to be recompiled to insert the logic analyser, this process can actually remove the bug that is being searched for. Although this may seem like a positive, not knowing what the original problem was means that it can be regenerated and reappear when subsequent synthesis and place-and-route operations are performed.
Despite this, one is able to see the status of signals based on a trigger condition and this does assist in debugging design problems. Using a logic analyser is an iterative process. A designer looks to see what is happening, makes an update, and then recompiles the design and reviews the new results, repeating the process until the bug is found. The time required for each iteration and for each specific bug is varied, and not all issues will be captured because of the sample rate of the logic analyser.
Next-generation debug tools
Because of the limitations of logic analysers for debugging, new debug tools have been designed to speed up FPGA and board validation. Some EDA vendors are offering tools that integrate logic analyser functionality into the synthesis tool to shorten the iteration of bug finding. When the logic analyser is integrated with the synthesis tool, this allows technology views into the design and easier trigger setup. A designer can also make design changes and have them automatically mapped back to the register transfer level (RTL) code. To conserve internal FPGA resources, some EDA tools can sample groups of signals and multiplex them. This is helpful early on in the debug process when the actual source of the problem is not known. Synopsys has implemented these features in its Identify logic analyser and Synplify synthesis tools. Despite the advances they deliver for the debug process, however, these approaches are all hampered by a re-compilation requirement, affecting the original design and the slower sampling of signals.
What an engineer could really benefit from is not only a logic analyser, but also an oscilloscope for the FPGA. This capability would allow real-time windows into what the design signals are actually doing. It would also be ideal to probe nodes inside the FPGA in real time and force different values on internal signals to observe the immediate effect on the design. Additionally, having the ability to probe the internal memory would be quite useful, as well as SERDES transceiver probe points. Delivering all of these capabilities without affecting the FPGA design would dramatically streamline the debug process.
One example of this approach is the SmartDebug toolset in Microsemi's Libero SoC software, which is used with the company's SmartFusion2, IGLOO2, and RTG4 FPGAs. This toolset enables designers to debug the FPGA fabric, memory blocks, and SERDES just as if they were using an oscilloscope. With smart debugging, it is possible to utilise the dedicated and specialised probe points built into the FPGA fabric, which significantly accelerates and simplifies the debug process. It also provides the ability to select different probe points without the need to recompile the design. Enhanced debug features give access to any logic element and enable designers to check the state of inputs and outputs in real time, without affecting the user's FPGA design. These features include:
Live Probe: This allows up to two dedicated probes that can be configured to observe a probe point which is any input or output of a logic element (Figure 1). The probe data can then be sent to an oscilloscope or even redirected back to the FPGA fabric to drive an internal logic analyser. These probe points are dynamic and real-time. No recompile or re-programming of the FPGA is required and the probe points can be changed on-the-fly via the software.
Active Probe: This feature allows dynamic asynchronous read or write to a flip-flop or probe point. This ability enables a user to quickly observe the output of the logic internally or to quickly experiment on how the logic will be affected by writing to a probe point. Any number of signals can be forced to specific values and, just like Live Probe, no recompile or re-programming of the FPGA is necessary.
Probe Insertion: This is used to insert additional probes into the design and bring signals out to the FPGA package pins to evaluate and debug the design. This feature does require an incremental place-and-route to add the signals to available I/Os, but it does not necessitate a complete recompile.
__Figure: __Example of Live Probe usage (Source: Microsemi).
FPGA designers typically spend about 30 per cent or more of their time in debug. This percentage could go even higher depending on the size and state of the project. Debugging can be painful because it involves many iterative cycles with limited observability and controllability, frequent re-runs of place-and-route, timing closure, and re-programming. By leveraging smart debugging tools, engineers can validate their FPGA designs much faster than just using a traditional inserted logic analyser. Allowing designers to observe signals in real-time and control signal states throughout their design unleashes much faster debugging.
Recently, a customer reported that they spent a week trying to debug a problem using an internal logic analyser. Replacing this approach with smart debugging enabled the engineer to identify the problem in just two hours. The issue was eventually traced to a completely different design module that the engineer had not originally observed using the logic analyser. This design was then further improved by forcing various values with the Active Probe feature and ensuring the circuit would respond appropriately.
Enhanced debug capabilities are a game-changing development for FPGA designers. The latest solutions can slash debug and validation times and provide unparalleled observability and controllability for a FPGA. The end result is that Designers who focus more heavily on an FPGA's debug capabilities before they select their next device can reduce development cycles and costs while significantly speeding time to market.
About the author
Ted Marena is Director, FPGA/SoC Marketing, at Microsemi.