Posted by Michael Posner on May 22, 2015
While the Xilinx UltraScale VU440 FPGA device looks to rocket FPGA-based prototyping forward in respect to ASIC gate capacity is sadly does nothing to help you debug your prototype. If anything it amplifies the engineers debug challenge by enabling huge volumes of RTL to be modeled. The HAPS and ProtoCompiler integrated solution debugging capabilities have revolutionized FPGA-based prototype debug but engineers still want more. Proof of this can be seen below in the contrast between the 2011-2012 and 2013-2014 FPMM survey data. The question asked is to rate the most challenging aspect of FPGA-based prototyping. You can see that the priority on debug increased significantly in the 2013-2014 timeframe over the 2012-2013 range.
This is a long blog but I hope you read to the end as it’s filled with great technical data and a previews of what’s coming in the HAPS next generation systems.
This shift could partly be due to HAPS ProtoCompiler successfully solving the 2012-2013 main challenge of Time to Prototype. It’s logical that the quicker you can get your DUT onto the prototype the quicker the need for debug. HAPS ProtoCompiler can generate results in as little as 5 days from initial RTL drop and incremental FPGA images overnight making HAPS prototypes highly productive. The other factor driving the increased need for debug is that the overall size(in ASIC gates and number of FPGA’s) of the FPGA-based platform has increased significantly. Whereas 1,2 and 4 FPGA platforms used to be the mainstream maximum sized prototype this has been superseded with prototypes of 8,12 or more FPGA’s (we even have customers using HAPS systems consisting of 32 FPGA’s) thanks to the HAPS seamless scalability and the modularity of the HAPS ProtoCompiler tool flow easing the modeling of the SoC DUT. When you add the Xilinx UltraScale VU440 device into the mix with 2.2x capacity over the Virtex-7 2000T you can understand why debug is a priority for prototypers.
Debug must no longer be treated as an afterthought, I see a lot of this when I visit and chat with prototypers. HAPS ProtoCompiler has helped as it moved some decision making on debug to the top of the flow ensuring that engineers don’t just focus on partitioning and implementation. Always accounting for debug is the key to success.
Here is a simple example of the impact of not accounting for debug upfront. In our picture below the SoC have been partitioned and implemented across four FPGA’s. Note that debug was NOT considered when the partition was created. (I should note, this is a real life case, engineer does not use HAPS or ProtoCompiler). You can see the clouds of logic and the arrows of interconnect between FPGAs.
However the engineer needed to debug (of course) their DUT so they then tried to force fit debug into the partitioned design. Unfortunately as they had not accounted for debug when they did the original partition the addition of the debug logic, even though it was pretty light, still forced the partition and interconnect between FPGA’s to change. In the picture below you can see that the logic in one FPGA was over utilization and had to be split into another FPGA. This is hugely invasive to the prototype. Basically the engineer had to begin from scratch, re-partition the design, re-do the interconnect and pin multiplexing. It was horrible.
Synopsys does not want other prototypers to face this challenge in the future so we have solved it as part of our next generation solution. In essence a debug infrastructure which has the capability to capture 1000’s of debug signal bits per-FPGA at prototype platform speed is built-into directly into the HAPS hardware and the HAPS ProtoCompiler tool flow automated the implementation ensuring its seamless and minimally intrusive to the user DUT. As with the solution today, the engineers view the debug data in familiar RTL and waveform formats compatible with Synopsys’ Verification Continuum tool set.
Dedicated debug data storage memory and dedicated debug interconnect communication scheme is built into the HAPS hardware so you are not utilizing FPGA embedded memory blocks or precious FPGA standard IO’s for debug. The HAPS debug IP infrastructure is pre-compiled and instantiated automatically by HAPS ProtoCompiler making the addition of debug almost seamless to the user. As its pre-compiled and validated, we ensure that timing within the debug hub IP and infrastructure is always met. The design interface to the debug interconnect infrastructure is asynchronous and pipelined minimizing any effect of timing closure based on the users design and performance constraints.
As the debug infrastructure is automatically and always accounted for during the partition and implementation phase within HAPS ProtoCompiler its minimally invasive and overall seamless to the engineers. This is in respect to both the debug logic IP and the debug interconnect communication as that is all handled via dedicated routes. As noted above, these dedicated debug routes are not FPGA standard IO’s. FPGA standard IO’s are prioritized for user defined interconnect between FPGA’s in the same flexible HAPS manor maximizing system performance.
Finally, this new solution is modular and scalable across system so as your prototype scales from 4 to 8 to 12 to more FPGA’s, so does the debug. There was a little preview to this in last week’s blog when I posted a picture of one of the new systems. The systems include an external debug panel that enables debug to be chained across systems. Simply connect the dedicated debug routes between systems and the HAPS ProtoCompiler tool flow does the rest by providing a unified debug view back to the RTL golden source code regardless of the number of FPGAs in the prototype partition.
There we go. Built-in, always available, minimally intrusive debug where the data is presented in context of the original source RTL for a simulator-like debug experience. Don’t forget, you still have other great HAPS and HAPS ProtoCompiler debug capabilities such as Real Time Debug, where design signals are routed seamlessly to a daughter board for capture using a logic analyzer. You can also create custom debug capabilities utilizing the HAPS Universal Multi-Resource Bus, UMRBus.
I hope you found this blog interesting. To get my blogs sent directly to you subscribe now.
To SUBSCRIBE use the Subscribe link in the left hand navigation bar.
Another option to subscribe is as follows:
• Go into Outlook
• Right click on “RSS Feeds”
• Click on “Add a new RSS Feed”
• Paste in the following “http://feeds.feedburner.com/synopsysoc/breaking”
• Click on “Accept” or “Yes” or whatever the dialogue box says.
I’m traveling again next week so I might be tardy in respect to the next blog. Stick with me though as I have some more exciting progress and capabilities to share with you.
Oh, if you liked this blog, post a comment and let me know. If you didn’t like this blog post a comment and let me know that as well. You only improve with feedback and I welcome it. Of course this is blog post ~150 so you might have wanted to post a comment sooner if you didn’t like what I write.