Are FPGA Lab Re-Spins Delaying Your Time-To-Market?
Posted by Dave Orecchio on Sat, Mar 14, 2009 @ 03:10 PM
Are FPGA re-spins killing your project? Delays in the lab directly delay product release, are the most difficult bugs of all and require resolution when they are most costly to fix.
As FPGAs become more advanced and your project uses more of the features of these new devices it is common for lab re-spins - builds of the FPGA - to take five to eight hours or more each time the chip is re-built! As a result, the time it takes to debug a design in the lab takes longer and longer - there must be a way to break the vicious cycle. Solving this problem is strategic to most OEMs where time-to-market and innovation is the life blood of their company. Let's review the common practice and source of the difficulties.
With the traditional verification approaches, software simulation is used to check the design before synthesis and place and route to ensure the design will behave as desired.
FPGA designers commonly use Intellectual Property (IP) building blocks to manage complexity while developing sophisticated applications. In many cases they cannot develop new applications without the use of the IP blocks because they are built into the FPGA fabric. In these cases, the user receives a simulation model for the IP module which approximates its behavior.
All of the testing is done above the "Design Verification" line in the picture to the right. This verification approach does not take into account error sources - the introduction of differences in behavior - introduced by down stream synthesis, place and route tools or differences in behavior between the simulation model for the IP block and the actual physical IP.
The problem stems from the fact that FPGAs have process steps and design flow differences from a traditional logic design process. These differences result in errors - differences in the function of the design - that are injected after logic simulation.
Traditional verification approaches don't catch many of these FPGA specific issues - a new approach is required for the new, larger and more complex FPGAs. Verification of FPGA designs must encompass the design implementation - the bit file programmed in an actual device as shown in the picture to the left.
Example error sources that are not found in simulation:
- 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 resulting from four state logic simulation versus two state device behavior
If you experience delays in project completion of your FPGA because of lab re-spins and want to break the vicious spin cycle then I suggest you review the capabilities of GateRocket's products.
The RocketDrive product uniquely brings the implemented FPGA into the simulation environment enabling the designer to validate their design in-silicon while benefiting from their existing test bench and tests early in the design cycle where bugs are easier and less costly to fix.