Synopsys Cloud
Cloud native EDA tools & pre-optimized hardware platforms
Request a Free Trial →
Table of Contents
Debug Matters!
By the time you have exhausted your bug questing by exploiting the full potential offered by simulation and emulation, the “easier-to-find-bugs” have been revealed and neutralized and your RTL is pretty stable. Great! Unfortunately, your job as a verification lead is not complete.
The problem is that bugs in highly complex chip designs are often buried deep in your system and they will not be found by simulation and emulation alone. They tend to manifest themselves in non-deterministic ways based on complex and unpredictable interactions between hardware and software. Detecting these hard-to-reach bugs often requires extremely long and time-consuming test payloads. A long time-to-failure presents many challenges in repeatability and debuggability, requiring significant or even impractical amounts of time and effort.
In their article, “Deep Cycles (Approximating Silicon with FPGA Prototyping), ” Joe Convey and Bryan Dickman talk about the challenge of getting enough performance to run real-life software pre-silicon, at speeds approximating those available in silicon. Deep FPGA prototyping allows you to scale out validation by depth and volume (deep cycles). This makes finding those unexpected interactions between the hardware and the software possible at fast enough performance and early enough in the design process to avoid bug disasters post-silicon.
Of course, it’s not just about achieving cycle targets or debugging software. What happens when hardware bugs occur? You need to be able to observe bugs when they happen and to be able to debug them efficiently when using an FPGA-based prototyping system. So, the challenge is to make your debug turnaround cycle fast and easy to manage, as this is often the aspect of deploying FPGA prototyping in a hardware verification flow which makes it less attractive compared to, say, emulation. Additional challenges exist around the provision of sufficient visibility into the internal workings of the design for debugging purposes.
As Joe and Bryan point out in “Deep Cycles,” you are likely running system software-based validation payloads on a scaled-out FPGA prototyping farm, and you are doing this because it is the closest approximation to actual silicon in terms of cycle throughput. Your RTL is stable. Your testing payloads are not falling over due to endless and frequent RTL bugs. You’ve already wrung out most of the hardware bugs with simulation and emulation. This leaves behind a class of bugs that, without scaled-out FPGA prototyping, are likely to only be found in actual silicon. Not good!
This trade-off between slower technologies like simulation and emulation, offering excellent visibility and ultra-fast FPGA prototyping, is where innovation helps achieve new levels of performance and debug productivity. It’s central to success in your quest to find those deeply hidden, hard-to-reach bugs.
Historically, when hardware bugs are encountered while running system software validation payloads on the FPGA prototyping platform, much effort is expended to reproduce the failures on a more debug-capable platform. This can be a difficult and lengthy process using binary chops to narrow down to a testcase that is small enough to replay on your emulation or simulation platform. The whole process can take days or weeks and is often unsuccessful. Modern FPGA prototyping platforms such as the Synopsys HAPS®-100 prototyping system change all that with high debug productivity capabilities. The ability to efficiently debug hardware problems on your FPGA platform is a huge shift and a time saver for FPGA prototyping as a hardware verification platform.
Improve Debug Visibility AND Run Faster
Debug is a process of detection and elimination as we know. You start with the software and debug it using the standard software debug tools. But if the evidence is pointing towards the hardware, you then need to debug the RTL, which involves capturing and analyzing waveforms. So how do you get waveforms out of an FPGA?
The HAPS system offers two types of debug capability for the capture of RTL waveforms.
The ability to monitor many multiple thousands of signals per FPGA without impacting the system speed has become possible through the introduction of HAPS Deep Trace Debug (DTD) technology in conjunction with the HAPS ProtoCompiler implementation and debug tools. Users pre-select probe points at FPGA build time and choose key signals and bus monitor points that will give them the best shot at debugging most problems. The HAPS solution saves this data to on-board trace buffers that can be read out for debug later. If the chosen probe points turn out to be insufficient for hardware debug, you have the ability to reconfigure with a fast incremental compile.
HAPS DTD Debug Flow with Synopsys Verdi® debug and data expansion technology.
In some debug situations, however, you really do want full signal visibility, without having to revert to testcase creation for emulation or simulation debug. HAPS ProtoCompiler Global Signal Visibility (GSV) allows the state of registered instances (full system state) to be captured from the DUT without the need for pre-defined debug probe selection and without knowing what portions of your design are active on initial design bring-up. As with HAPS DTD, there are several ways GSV can be set-up and deployed to help debug different scenarios. Perhaps one of the most interesting is through the control of the DUT clocks (Synchronous GSV) to hold parts, or even the complete DUT, in a static state while capturing the registered instance values.
See Finding Hardware Bugs Faster with Full Visibility Debug for more details on DTD and GSV.
The HAPS-100 prototyping system offers a significant increase in productivity by delivering multiple debug modes, 4x signal capture, and 4X debug performance compared with previous generations. This is supported by the Verdi technology, which ensures a common unified debug solution across all platforms and offers an automated way for setting up the complete Verdi debug environment for design analysis in ProtoCompiler flow, thus providing improved RTL signal correlation for data expansion.
What’s more, the HAPS-100 system now offers support for SVA assertions. Incorporating your RTL SVA assertions into your FPGA-based system validation environment can significantly reduce time spent in debug by efficiently flagging up the precise point of erroneous RTL behavior.
Debug Landscape Shifted
So, HAPS technology really does shift the landscape for debug on FPGA prototyping systems: system validation teams can perform RTL debug! The Synopsys FPGA prototyping platform is now the platform where you run fast, with no need to fall back to simulation and emulation when you encounter a hardware debug requirement, potentially saving days, or weeks, on testcase reproduction appropriate to those slower platforms.
Look out for Part 2 of this story, where we will explore some of the debug productivity challenges of FPGA debug in more detail and show how the latest generation of HAPS technology is meeting these challenges head on.