GateRocket is a Cadence Connections partner that focuses exclusively on verification and debugging solutions for complex FPGAs. The company's RocketDrive "device native" verification solution uses a real FPGA to complement simulation, providing both acceleration and debug visibility. In this interview Dave Orecchio, GateRocket CEO, talks about FPGA verification and debug challenges, the device native verification methodology, and how RocketDrive works with the Cadence Incisive simulation environment.
Orecchio also notes how GateRocket supports the primary requirements of EDA360 Silicon Realization -design intent, abstraction, and convergence. A newly published paper on the GateRocket web site shows how the company's technology closes the Silicon Realization gap for advanced FPGA design.
Q: Dave, can you give us some background on GateRocket and its mission?
A: Sure. The company was founded by [CTO] Chris Shalick, an ASIC designer who transitioned to FPGA design. He had difficulty debugging his FPGAs in the lab, and he saw that if he could identify bugs earlier in the design process, then the problems he saw in the lab would have been solved. He felt that every FPGA designer would have more success with such a capability, so he quit his job and started GateRocket in 2004.
I joined the company in 2006 when we received our first funding. I'd been involved with FPGAs since the early 1990s when I worked at Viewlogic. I saw an inflection point occurring with FPGAs because of the capacity increases of devices. The purpose of GateRocket is really to help designers keep ahead of advancing complexity in FPGA devices.
Q: What challenges are FPGA developers having with verification and debug today?
A: What people often overlook is that FPGAs are fundamentally different from ASICs when it comes to technology and back-end flows. Fundamentally, there is no deterministic path to get a design working in silicon. You can't see how the implemented device will behave by looking at your simulator.
In the last few years FPGA devices have more than doubled in capacity, and that doubling is occurring again in the coming year as both of the major vendors roll out 28nm devices. Capacity is driving the need for modern verification methodologies and hardware assistance - the same trends that occurred with ASICs. Better performance and more thorough verification are required.
Q: Are you seeing more use of ASIC-like tools and methodologies for FPGA design and verification? For example, are FPGA developers using capabilities like random stimulus generation, coverage, and metric-driven verification?
A: Absolutely, these approaches are being adopted by FPGA designers. Traditionally, FPGA designers have been slow to adopt new methodologies, but two events are changing that. First, ASIC and ASSP engineers are moving to FPGAs and bringing their methodologies with them - the same high-end methodologies used for verification, like SystemVerilog and so on.
Secondly, as complexity increases and FPGA designers are designing larger chips, they're moving up - they can no longer rely on the "blow and go" approach. If they try to take a design that's barely verified into the lab, then they thrash in the lab, because there are so many interacting bugs and no effective way to find them. Simulation and verification tools are rich in capability, but you lose all that when you go into the lab.
Q: How is FPGA verification and debugging different from ASICs?
A: FPGAs are coarse-grained architectures that are continuously changing. There are no good tools to ensure that the design is being implemented correctly in the device. There is no LVS [layout versus schematic] for FPGAs, no way to assure that design intent is implemented in silicon. In essence, there's no closed loop for FPGA design.
Q: How does device native verification help?
A: As an ASIC engineer turned FPGA designer, our founder, Chris Shalick, believed that if he could bring the FPGA into the simulator, he could close the open loop that existed. He could see what's happening in the device while testing it with the same testbench used to design the device. He implemented it in a way that it fits with your existing tools and methodologies, and you don't need to change the source code of your design.
As a result, you get visibility into the device, in the same way that you would see an RTL model in a simulator. You also get very fast execution so that you can process many more tests than you otherwise could. And you've got the accuracy of the device so you see exactly what you'd see in the lab.
Q: How does GateRocket technology compare to building an FPGA prototype?
A: Because we are integrating the device with the simulator, our approach is the only one that preserves design intent from HDL [hardware description language] all the way down to silicon implementation. When you go into the lab with a prototype board, you lose the investment you've made to create your design and test the design versus your intent, because the tools you use in the lab are embedded logic analyzer tools. It's a complete context shift with no controllability and visibility back into the design verification world.
Q: What does GateRocket offer in terms of debug visibility?
A: Our solution provides internal visibility into the device, and all that internal visibility is delivered through the simulator, with whatever waveform viewing tool the engineer is using. We provide a direct comparison between any RTL block the user wants to select in their HDL versus that RTL block physically implemented in silicon. By doing that comparison, you have a deterministic debug methodology where you can identify the exact source of the bug very quickly.
Once you find that bug, we give you the ability to patch the bug, without going through a long place and route process. That capability, called SoftPatch, won the Design Vision award for best IC design tool at DesignCon and is a finalist in this year's EDN Innovation Awards.
Q: You have customers who use RocketDrive with the Cadence Incisive simulation environment. How does it work with Incisive?
A: It's tightly integrated with Incisive, and all the features we've talked about work with Incisive. You can see the behavior of your design running inside the silicon, compare the silicon to the design intent, and use the SoftPatch capability. For the Incisive user everything is the same, except for the debug features added to Incisive. It's kind of like a turbo charger for Incisive to find FPGA bugs very quickly during the design process.
Q: Finally, how does GateRocket fit into the EDA360 Silicon Realization concept?
A: What I've learned about Silicon Realization is that it's all about creating a deterministic path to a successful silicon device. With conventional FPGA tools, there's no real linkage between what you get in silicon and what you verified in simulation, because the synthesis, place and route tools are very different in the FPGA world.
GateRocket preserves design intent from the simulation model all the way down to the silicon, by giving the user the ability to see whether the intent is implemented in that silicon. We can work with multiple levels of abstraction - for example, we have demos that show how you can do a DSP design in Matlab and verify an FPGA inside RocketDrive. And we support convergence of that high-level abstraction all the way down to the physical device.
Also, GateRocket fits very nicely with the [pin optimization] technology that Cadence acquired from Taray for validating the pinout of the FPGA. We can take the design all the way to the pins, and the Taray technology takes it all the way down to the PCB implementation. The combination of GateRocket with Incisive and the [Taray] tool is really the only solution that gets you from design intent all the way through and past Silicon Realization. It's convergence all the way down to the physical PCB.