High-performance, low-power FPGAs like the Altera Stratix IV are game changers as they find their way into designs that were recently “ASIC-only” zones. With advanced features, and without expensive mask costs, today’s programmable parts let design teams innovate with this powerful and customizable canvas.
Challenges remain, particularly for those who transitioned from designing ASICs to FPGAs. GateRocket CTO Chris Schalick, made this transition a few years back and found design verification of large FPGAs different than ASICs and particularly challenging due to the nuances of these devices. Similar to the ASIC trends of the early 2000’s, design complexity of FPGA devices like the new Altera Stratix IV have increased so much that traditional verification approaches cannot scale with the complexity of these new chips. This trend is called the verification productivity gap and FPGA designers have found themselves front and center with the same dilemma as ASIC designers but with additional challenges unique to FPGAs.
The verification productivity gap manifests itself in two ways. The first is very slow simulations, which forces designers to take every shortcut possible, like not simulating sections of the chip, not simulating the whole chip or writing their own simplified behavioral models just to get the job done in a reasonable amount of time. In the end designers are not testing what they are building, leaving the real work to be done in the lab. The second indication of the productivity gap is extremely long lab debug because software simulation does not catch many of the error sources of the FPGA design process. Even if the designer were to take the time to simulate the entire design they would still encounter issues that can only be worked through with real silicon. It’s where the silicon meets the road, if you will. These productivity limiting events come at a time where each day in the lab prevents your product from reaching the market on time.
Both of these classes of problems can be resolved by integrating the silicon into the simulation environment. However, it has to be done right or the value of faster simulation and device native accuracy would be negated.
GateRocket identified these problems and saw that no one was addressing them. Few had the vision to understand that these problems would only get worse with time and increasing FPGA device complexity. GateRocket had the vision to address the core issues that cause the verification productivity gap in an environment where software and hardware representations co-exist and where each functional block in a design could reside in the software domain, in hardware domain or both. By doing this, the user would be able to accelerate the long simulations and gain early visibility of chip behavior during software simulation with no methodology change. This approach uniquely closes the verification productivity gap caused by the rapidly escalating complexity of these new mammoth chips, while significantly enhancing the productivity of the FPGA design process.
Knowing that existing approaches were insufficient, GateRocket took a different path by bringing the FPGA device into the simulator, packaging it with software that made it very easy to use and enabling seamless integration into the existing design tools and test benches. GateRocket created the RocketDrive product, developed the software and hardware and introduced what is now called “Device Native” verification. “Device Native” verification uses the actual FPGA device, and integrates it into the HDL simulator, to verify the FPGA design.
Now let’s drill into some of the specific challenges designers face with the new larger FPGA devices and understand how a solution that brings the native FPGA device into the simulator is a very powerful advantage.
FPGA Verification and Debug Challenges:
- Design size is increasing to the point that software simulation slows to a crawl where it is unproductive, leaving the user to search for acceleration options. This problem is worse whenever gate level FPGA IP simulation models are used, which is a typical occurrence.
- Many communications and video applications require long unbreakable tests to validate key functionality. The longer the test, the more difficult it is to find errors and the length of the cycle increases the long debug times. These two market segments represent more than half of all FPGA designs, making this a widespread problem.
- Nearly every design uses IP blocks. The configuration permutations for them are endless and each option creates an opportunity for error, which takes considerable lab time to discover.
- When working in the lab, the FPGA build cycle (Synthesis and Place & Route) can take many hours to complete, sometimes taking up to 12 hours or more. This extended time frame significantly hampers debugging of the design since only one fix/verify cycle can be accomplished in any given day.
The issues of design size, long unbreakable tests, significant use of sophisticated FPGA IP and long build times are significant ones and there are more. To help manage this complexity and remove risk from your project schedule, GateRocket allows early and simple testing of your design in the FPGA without changing your verification approach. This solution merges the best of both worlds by providing the native FPGA device behavior with simulation environment control and all of the richness of your software debugging tools.
This solution automatically leverages the power of the Altera Quartus II software and your simulator so the following benefits are delivered without a change in your tool flow:
- Device Native FPGA behavior in the software simulation environment exposes bugs early in the design process
- Accelerated verification because the FPGA executes the design code natively, making it easier to test the entire design simultaneously and run more thorough tests
- Advanced debugging features that deliver pinpoint detection and diagnosis of bugs in-silicon, while also allowing most what-if tests to be performed without rebuilding the device
- Eliminates slow and complex models of advanced FPGA intellectual property components, like the popular XAUI, SPI4, DDRx, GMAC, QDR, etc, because they are running in the FPGA
- No changes to the FPGA design source enable both interactive and script based control and as you make changes to your design rerunning tests is automated
- Can be used with many designs because of rapid start-up process unlike the lengthy setup cycle of traditional emulator products
- Does not change the methodology of existing design verification methods and tools empowering you to find more bugs even faster
The RocketDrive (pictured below) is a hardware appliance that plugs into the standard 5¼-inch drive bay of your PC and contains the largest member of the Altera device family with which you are working, for example the Stratix IV.

To use the RocketDrive, start with software simulation, verifying the design at a high level of abstraction. Using the GateRocket software (see the setup diagram below) you can direct the system to place some or all design blocks in the drive and keep the others that are being interactively developed in the simulator. This lets you benefit from the acceleration and device behavior of much of the design, yielding faster simulation iterations. As new blocks are completed, they can be promoted to run in the RocketDrive. In many cases when running regressions the entire design is placed in the RocketDrive and the test bench remains in the simulator. The diagram below shows the simple setup process.
RocketDrive Setup
Unlike an emulator, all of the parameters associated with the I/O pins are also verified in a physical FPGA and, unlike a development board, the design does not require modification to use this approach. Add to this a software suite called RocketVision that delivers advanced debug and visualization in silicon, and you now have a workhorse solution that drops into an existing design environment as both a hardware and software complement to your industry-leading simulators from Cadence, Mentor or Synopsys. In fact, the debug and visualization features are enabled and controlled from within your software simulator, which means there is no methodology change and a very little to learn. The picture below shows a RocketDrive in use and controlled by the simulator.
Using a RocketDrive
The “device native” part is actually seeing how designs behave in a physical chip, running just as they would in-system, while having access to all the capabilities and flexibility of a software simulator. In this way you can detect, identify, and correct differences between the original RTL and the physical chip quickly.
For more information check us out at http://www.gaterocket.com or come visit us at DAC/San Francisco July 27-30, Booth 3550 and ask us about our new Stratix IV RocketDrive. Not going to DAC? Sign up for one of our Webinars!
We look forward to helping you solve your FPGA verification and debug challenges.