Building better debug facilities for bigger FPGA-based prototypes

Mick Posner is Director of Product Marketing for Synopsys' FPGA-Based Prototyping Solutions. He has held various product marketing, application consultant and technical marketing manager positions at Synopsys.

The introduction of Xilinx’s Virtex UltraScale VU440 FPGA may boost the capacity of FPGA-based prototyping, but it does little to help users debug a prototype. If anything, it increases the debug challenge by enabling much bigger RTL code bases to be modeled.

The debugging capabilities in Synopsys’ HAPS and ProtoCompiler integrated solution have changed debug strategies in FPGA-based prototypes, but engineers still want more.

Our regular FPMM survey shows this. We asked users to rate the most challenging aspect of FPGA-based prototyping, and the importance attached to debug visibility rose considerably between the 2011-12 survey and the 2013-14 survey.

This may be due to the way that ProtoCompiler, design automation and debug software exclusive for HAPS systems, has helped reduce time to prototype, which was the leading challenge revealed in the 2011-12 survey. It’s logical that the faster you can get your DUT into prototyping, the sooner you need to debug.

The other factor driving the increased need for debug is that the capacity of FPGA-based prototyping systems has grown a lot. Whereas 1, 2 and 4 FPGA platforms used to be mainstream, we now see prototypers using 8, 12 or even 32 FPGAs, thanks to the scalability of the HAPS hardware and the modularity of the ProtoCompiler tool flow.

Debug cannot be treated as an afterthought in such large prototypes. ProtoCompiler has helped change team thinking by moving decisions about debug to the start of the flow, ensuring that engineers think about more than just partitioning and implementation at the start of a project.

What happens if you don’t account for debug upfront? Your SoC logic will be partitioned across, say, four FPGAs, entirely on the basis of the interconnect requirements of the logic. Implementing the debug logic separately is then likely to lead to what can often amount to a complete ‘re do’ of the logic partitioning, interconnect and pin multiplexing of the prototype. It’s horrible.

Synopsys builds debug infrastructure capable of capturing thousands of debug signal bits per FPGA, at prototype platform speed, into the HAPS hardware and ProtoCompiler tool flow. Implementation is automatic and is meant to intrude on the DUT as little as possible. Engineers view the debug data in familiar RTL and waveform formats compatible with Synopsys’ Verification Continuum tool set.

The HAPS hardware includes dedicated debug data storage and a dedicated debug interconnect communication scheme, so that users don’t have to use up FPGA embedded memory blocks or I/O for debug. The HAPS debug data acquisition infrastructure is pre-compiled and instantiated automatically by ProtoCompiler, making the addition of debug almost seamless to the user. ProtoCompiler also ensures that timing within the debug hub and infrastructure is always met. The design interface to the debug interconnect infrastructure is asynchronous and pipelined reducing the effect of timing closure based on the user’s design and performance constraints.

With Xilinx introducing Virtex UltraScale FPGAs with 2.2 times the capacity of the previous largest Xilinx parts, it looks like prototypes are only going to grow. The latest HAPS hardware includes an external debug panel that enables debug signals to be chained between systems on dedicated cables. The ProtoCompiler tool flow knits all these signals back together to provide a unified debug view back to the RTL golden source code, regardless of the number of FPGAs in the prototype partition.

The end result of this combination of dedicated hardware and implementation and analysis software is a minimally intrusive debug facility for large (and growing) FPGA-based prototypes, with the debug data presented in the context of the original source RTL for a simulator-like debug experience.

If this doesn’t satisfy your debug needs, you can use HAPS’ Real Time Debug facility to route design signals to a daughter board for capture using a logic analyzer, or even create custom debug capabilities through the HAPS Universal Multi-Resource Bus. Now all you need to do is work out what is going wrong and fix it.