FPGA Complexity Leads to Debug Crisis

Dave Orecchio, President & CEO, GateRocket, Inc.

The FPGA complexity race rolls on: The FPGA vendors have done amazing things with the new deep submicron 40 nm FPGA semiconductor devices. Altera’s Stratix IV debuted with over 680K logical elements, the highest density, highest performance, and lowest power FPGA at the time; followed by the Xilinx low-power, high-performance Virtex 6 family with up to 760K logic cells. The frenetic pace of advanced technology innovation that this duopoly of FPGA industry leaders brings to market is great news for systems designers across the globe.

This innovation has pushed FPGA complexity to the point where traditional verification is breaking and becoming a major bottleneck in the design process – something called the "verification productivity gap." It has two hallmarks – extremely slow simulation runs, accompanied by a debug crisis wreaking havoc on product schedules. The debug crisis is not just with the RTL version of the design but extends into the lab where the current debug tools are ineffective. The traditional lab debug tools reflect the day when FPGAs were small glue logic and were simple to design. Today, FPGAs are Systems on a Chip (SoCs) themselves as the industry shifts from ASICs to FPGAs and embedded IP cores proliferate. The resulting designs require a step function improvement in debug capability in order to maintain control of schedules and decrease the project risk.
With these slow simulations, designers must cut corners: For instance, 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 time. The result is inadequately tested designs, thus transferring the real debug work into the lab where the debug tools are no longer up to the task of finding errors in complex designs.
This nets out to unacceptably lengthy lab debug since simulation missed many of the error sources of the FPGA design process. Even if the designer simulated the entire design they would still encounter issues that can only be worked through with real silicon. Some of the common errors include:

  • Differences from IP simulation model from the physical implementation
  • Errors caused by faulty mapping of the design to the FPGA architecture
  • Overly aggressive optimization in place and route tools
  • Device errata that was missed in the design process
  • Functional errors not found in simulation resulting from issues like four state logic simulation versus two state device behavior or others

The debug crisis I mentioned is becoming acute because lab re-spins, builds of the FPGA, now routinely take eight to fifteen or more hours each time the chip is re-built! As a result, designers get one try to fix one bug a day minimizing their productivity, and all that extended debug time puts schedules further and further behind. Little wonder then that a recent EE Times survey of FPGA designers revealed that just 11 percent completed their designs on time, and most of those are simple, small designs and the number-one issue that users face is with functional verification.
Traditional verification approaches won't catch many of these FPGA-specific issues. Something new, encompassing the entire design implementation is required. Designers need an environment where software and hardware representations co-exist: where each functional block can reside in the software domain, or in the hardware realm, or in both; and where the designer can iterate through their debug cycle without having to rebuild the FPGA.
Suppose you could benefit from the actual behavior of the FPGA device early in your design process in your software simulation environment where bugs are less costly and more productive to resolve. Think of eliminating the "modeling" part of simulation and replacing it with the "native silicon" of the FPGA. This would eliminate the guesswork and the impact of ineffective or incomplete models, a major source of error.
Suppose you could also deterministically identify bugs in your design and then rapidly test a fix without rebuilding an FPGA, kind of like a soft patch as you would do in software development. In this way you would gain the benefit of working with silicon without the pain of the long and arduous FPGA build times. This approach would put the power back in the hands of the designer, where it belongs and restore the rapid innovation we expect from using an FPGA fabric. GateRocket delivers products that enable this new approach to FPGA debug.

The bottom line is that FPGAs are getting bigger and are more widely used. The coming year should see more growth and adoption of these devices in a wide range of applications with 80,000 new FPGA design starts according to a recent Gartner report – more than 30 times that for ASICs. As tool vendors, our challenge is to create new ways to deliver a step function in productivity so that designers realize the full potential of these magnificent programmable parts.