(Ed's note: I was chatting with my chum Dave Orecchio recently. Dave used to be president and CEO of GateRocket. Sadly, GateRocket is no more, but it's no secret that I was a big fan of its technology -- specifically the RocketDrive hardware and the RocketVision software. In fact, I penned a few columns about the little scamps, including "Arrgghh! My FPGA's not working: Problems with the *RTL*"; "Eeeeek! My FPGA's not working: Problems with the *IP*"; and "Oooof! My FPGA's Not Working: Problems with *Synthesis Gotchas*." Dave is now working with the Embedded Instrumentation team at Tektronix. He was telling me about everything they are doing, and it all sounded jolly interesting, so I asked him if he would care to pen a few words on the topic. Here's what he sent me.)
For longer than I care to admit, I have been chasing the dream of a better way to debug FPGAs, SoCs, and advanced ASIC prototypes built with multiple FPGAs. As anyone who has ever developed an ASIC prototype using large FPGAs knows, all the potential debug solutions available to date each have significant limitations. Briefly, these can be summarized as follows:
Software simulators offer great debugging capabilities, but they also offer only limited functional coverage; because of performance limitations, there is no way to exhaustively test the design. Models must be used for device I/O, and simulators aren't suitable for live testing of firmware or software applications.
Some hardware emulators and accelerators provide an enhanced debugging environment, but they are very expensive and also don't run fast enough to test real-world firmware, applications, and interfaces.
FPGA-based prototype boards are affordable and speedy, but they offer very limited -- if any -- internal visibility out-of-the-box, and existing add-on debug tools involve 8- to 18-hour synthesis-place-route cycles in order to gain access to a handful of signals.
These limitations, by definition, mean that debugging an ASIC design in an FPGA-based prototype is inordinately complex and time-consuming. At the same time, the pressure to produce first-time correct silicon continues to grow, and intense competition means that sacrificing features and functionality is not an option, so smart engineers continue to muddle along as best they can. The passion of my search is to find a better way.
For me, the journey has spanned multiple years, beginning with a startup company called DAFCA that developed a solution for debugging and post-silicon bug-fixing for SoCs. Later, I joined GateRocket, where I served as the president and CEO. This company developed an FPGA solution (and even claimed a patent) that combined hardware and software that improved FPGA debug by merging the power of the simulator with the physical accuracy and speed of the FPGA. It had the potential of being the best of both worlds, but unfortunately the cost of the solution limited its scalability. I recall hearing users say over and over again "Can you get your debugging capability to work in my ASIC prototype?" The users' unmet need existed, but the GateRocket solution was tied to proprietary hardware, not the users' prototype boards.
But all is not lost...
In the past months, I have been working with the Embedded Instrumentation team at Tektronix. This is a brilliant team of engineers led by Brad Quinton. They brought Brad's PhD research from the University of British Columbia to market. Since Brad has designed and led ASIC projects in the past, he understood the gaps with existing ASIC prototype solutions. His research and the experienced team behind the product have created a solution that is clearly a breakthrough versus all other ASIC prototype debug products.
In the final analysis, FPGA-based ASIC prototypes are the most effective and affordable debug platform for designs when scalability, software development, and/or exposure to real-world interfaces is important. Now, if only there were some way to access a useful number of signals and samples -- if not all of the internal signals -- at your whim. The solution would have to eliminate the numerous, useless, and time-consuming process steps (specifically the synthesis-place-route of the FPGAs) that current methodologies impose on the user.
Re: Another common use is looking at DSP functions in Matlab
Sure. Will do so brad. I have one mis calculation to be fixed which I figured out yesterday when I tried to be too smart with the app amd messed it up. Will send as soon as its done.
brad_quinton 11/20/2012 11:08:01 AM User Rank Beginner
Re: Another common use is looking at DSP functions in Matlab
I am unaware of Minilab, can you send me a pointer?
We use open, standard formats throughout most of our software, so connecting to other software is normally easy, but if you send me a link I can let you know for sure.
brad_quinton 11/19/2012 3:31:35 PM User Rank Beginner
Re: Another common use is looking at DSP functions in Matlab
Yes. We do have a number of customer using captured data in Matlab. They are doing so through conversion of our output VCD to a Matlab text file. This is a simple conversion and we are happy provide example Perl or Python scripts for through our applications support for customers that are interested.
brad_quinton 11/19/2012 10:55:16 AM User Rank Beginner
Re: One of the more comon uses of FPGA prototypes of SOC's is to check Firmware prior to Silicon
I agree William, I'd say that at least 50% of our customers are using their FPGA Prototypes for firmware development and debug. We do not do instruction decode in our tool, instead we have worked to build time correlation from traces gathered with our tool to existing software debug tools, like GDB, that have this ability. In fact, I recently wrote an article explaining this approach:
There is still lots to do in this area, and with the rise of multi and hertrogenous core SoCs I expect there will be continued innovation in in this area.
One of the more comon uses of FPGA prototypes of SOC's is to check Firmware prior to Silicon
One of the more comon uses of FPGA prototypes of SOC's is to check Firmware prior to Silicon -- Does the tool allow instruction decode for common processors, and bus decode?
brad_quinton 11/16/2012 11:18:12 PM User Rank Beginner
Re: Inferring values
You are correct outputlogic, most ASIC Prototypes use clock rates lower than production FPGA designs. Certus, our product focused specifically on ASIC Prototyping, is spec'd to run at 150MHz, more than enough for most of our prototyping customers. We do, however, have customers using Virtex-7 running at 200MHz using Certus. We have a case study that we did with the Dini Group discussing one such case. You can find it (and some other stuff) here:
The good news is that there is nothing fundamental about the architecture or base technology that limits the frequency. Over time, as we plan to broaden our focus beyond ASIC prototyping and have plans for pushing the clock frequencies well over 200MHz in high-end FPGAs.
To save this item to your list of favorite All Programmable Planet content so you can find it later in your Profile page, click the "Save It" button next to the item.
If you found this interesting or useful, please use the links to the services below to share it with other readers. You will need a free account with each service to share an item via that service.
Tweet This
