(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.
Next page >