Debugging is the whole point of prototyping

The prototype is obviously the end goal of FPGA-based prototyping, however success of the journey relies on how quickly defects can be found and rectified. Winning in the debug phase involves a combination of methodology, capability, and planning. Synopsys recently aired a webinar on their HAPS environment and its debug ecosystem.

We say ecosystem because there are different debug tools for different intents and different designer preferences. Rather than forcing users into one type of debug, HAPS brings several types of debug tools together.

Achim Nohl, Technical Marketing Manager for Synopsys, talks about controlling the defect space. Running straight to the full-up prototype with actual software is tempting, but the potential defect space is huge at the onset. A better methodology uses incremental bring up, starting from RTL simulation and working through a prototype using that same test bench, then moving to the full-up design and software.

EDPS Symposium: FPGA Prototyping IOT Designs
SemiWiki-EDPS2016 promo code for a $50 savings

Nohl also explains how Synopsys uses the UMRbus in conjunction with Client Application Interface Modules (CAPIMs). What struck me here is this is the point where others are using AXI-based transactors. CAPIMs can go into any logic block, including an AXI transactor but also into other points to inject stimuli, perform setup and configuration, and monitor results.

If prototyping starts without debug planning, there are several big risks. Defects can actually be introduced, and in a worst-case scenario adding debugging can impact FPGA partitioning. HAPS ProtoCompiler adds instrumentation automatically so debug is synthesized in with minimal overhead. Probes and trigger points can be changed rapidly using a reroute feature in Xilinx’s place & route system.

ProtoCompiler also works with the Deep Trace Debug capability in HAPS. There is much more involved in DTD than just data capture capacity – multiple signals must be correlated, and complex triggers may be needed. Getting a complete picture of IP interaction is important. HAPS uses both FPGA memory-based trace debug or add-on DDR3 SDRAM that can grab up to 250 signals at 160 MHz, or 2K signals at 20 MHz. SATA or optical links also allow using an external HAPS-DX7 configured as a debug hub, adding more analysis and storage.

Nohl also looks at a unique feature: pre-configured, pre-armed triggers that are up immediately after reset. Often, FPGA-based prototype debuggers have difficulty seeing defects that happen right out of reset while getting set up. There is also global state visibility (GSV), the ability to snapshot all registers in an FPGA instantly with data mapped into RTL namespace. GSV can run asynchronously, or synchronously with correlation by adding a clock control module. This is a handy feature for power domain debugging such as wake-up problems.

We’ve just brushed the surface of Nohl’s presentation. The array of debug capability in HAPS – again, the combination of the hardware platform, the ProtoCompiler software, and a methodology – is impressive. For anyone who has struggled with multi-level or real-time debug of an SoC design, or is looking for more information on how HAPS really works beyond just the datasheets, this webinar is very educational.

How Flexible Debug Can Speed Physical Prototype Bring-Up and Software Development

Nohl’s punchline sums it up nicely: “The question is not whether you have bugs or not; the question is whether you are able to deal with them.” Debugging designs in FPGA-based prototype platforms is absolutely essential to success with SoC designs, and the Synopsys team has thought through the entire process in the HAPS environment.

EDPS Symposium: FPGA Prototyping IOT Designs
SemiWiki-EDPS2016 promo code for a $50 savings