Posted by Michael Posner on February 6, 2015
I traveled from Oregon to California this week and visited the new Synopsys offices aka “The 690!” all I can say is wow, I want one. The Synopsys offices in Hillsboro Oregon are nice but we don’t have the new technology that the Synopsys CA offices got. Gym, cafeteria, bright nice cubes/office and Champagne on tap….. Of course one of these is a lie, can you guess which? Yes that’s right, no cube space can ever be nice. There is a HUGE hardware lab and I was able to wing it and get someone to flash me in, apparently I’m not on the authorized entry list “yet”. There are many HAPS stations for development and regression testing, one of the stations that caught my eye is pictured below
This pictures one of the development & regression stations for HAPS Multi-FPGA Deep Trace Debug. This is the HAPS debug simulator like experience, debugging at the RTL source code with an almost seamless flow for your HAPS-based multi-FPGA prototype and external deep trace capture. I’ve blogged about this before a number of times, the last time in my “Top 3 Myths of FPGA-based prototyping BUSTED” blog which blew apart the stagnate mindset that you only get very, very limited debug visibility in FPGA-based prototypes. We have a nice video about this and other debug capabilities integrated into HAPS: http://www.synopsys.com/prototyping/fpgabasedprototyping/pages/troubleshoot-debug.aspx
If we look at the recent survey data that Synopsys commissioned
You see that debug is rated almost equally challenging to multi-FPGA partitioning, ASIC clock conversion and a hair above performance. Synopsys has been focusing on addressing these debug challenges.
Prototype debug visibility is like the tree with roots picture I posted above. The top of the tree is your ASIC/SoC and the roots are the network of debug visibility points. You don’t need to look at everything to successfully debug. Hold it right there you say, we want 100% visibility….. This is a common request as it’s what you get in an RTL simulator or emulator, but remember, in comparison to even the fastest simulator (VCS), or emulator (ZeBu), HAPS FPGA-based prototyping is magnitudes faster. The problem is that there is that thing called Physics which gets in the way. As you add real hardware logic for debug instrumentation you start having to trade off available FPGA capacity for the actual design with the debug logic. Yes you can do this but the result is that you need many, many more FPGA’s to support the design size plus the debug logic and this could become cost prohibited.
To manage this you need to make smarter choices on debug points. This is exactly what we do in the DesignWare IP Prototyping Kits, these are pre-instrumented with a set of debug points which aid debug of the design and interface once the IP integrated. RTL developers should be doing the same for your code, identifying critical debug points early in the design cycle and carrying those through to the prototype.
But what if your RTL developers throw the code over the wall with no debug points identified? In this scenario the Verdi and Siloti tools help. The Verdi/Siloti tools are used to derive a minimum set of “essential” signals to be recorded. This essential signal database is then used to generate the instrumentation list within the prototype. HAPS with ProtoCompiler supports this in an automated flow. The visibility automation technology in the Siloti system combines visibility analysis techniques and a data expansion engine to reduce the impact of observation on the prototype maintaining performance and significantly reducing the instrumentation capacity overhead.
The end result, less overhead, more root like debug, but still high debug visibility.
This is just one type of FPGA-based prototype debug and HAPS has multiple others depending on what you are debugging.
Traditional FPGA debug utilizing the FPGA embedded memories still play an essential part in the debug methodology. While the depth of storage is narrow when using FPGA resources, the capture performance is high, typically at the same speed the internal logic is running. This can be helpful when debugging high speed logic and interfaces. HAPS Real Time Debug, the process to connect internal FPGA signals to external FPGA IO’s and capture with a logic analyzer is also essential. One such example is when you want to debug the interface from the FPGA to the DDR memory. The HAPS debug interposer card can be placed between the HT3 connectors and the DDR3 daughter board enabling the signals to be traced with almost unlimited storage on a logic analyzer. The use and setup of HAPS Real Time Debug is automated through the ProtoCompiler flow, you don’t even need to modify your source code as passive Cross Module References, XMR’s, are used to “hook up” the signals. Multiplexed sets enables multiple debug groups to be created and then selected at runtime reducing the need to go back and add additional debug. Compression and smart tracing is used to more efficiently store debug data for expansion off-hardware. And of course the HAPS deep trace debug, the ability to trace 1000’s of signals and store the data off-FPGA. This has the added advantage of reducing the debug logic overhead.
How do you debug your design in FPGA-based prototype? Drop me a comment and let me know. I would love to hear about other debug methods such as bus monitors which are implemented into the prototype. I have seen the HAPS UMRBus capabilities used for built-in protocol monitors, I will blog details about those in the future.