The Cost of a Bug
Posted by Chris Schalick on Wed, Jul 23, 2008 @ 10:18 PM
The best judge of product quality is the customer. That's a good argument for serial design flows - a design is not done until the downstream user validates it. Companies with infinite time and resources can work this way, but short product life cycles force more practical teams to design in parallel. Running in parallel encourages developers to focus only on the task at hand at the expense of big-picture system behavior. Throw into this a soaring complexity of modern digital devices and you've got bug soup.
As a design progresses through its development phases, the cost to resolve a bug skyrockets and the difficulty in finding its source increases. Typos are easy to find, hardware-software interactions triggered by customer configuration are not. The mantra of verification is to preemptively find and resolve bugs before they hit the customer. Still, rapid design schedules mask design issues in complex systems that result in late-stage design changes, the most costly bugs of all.
As FPGAs proliferate, so does the false sense of hope of an inexpensive, quick fix for these late-stage defects. Hey, it's just software right? FPGA designers generally come from two camps, those who have used small FPGAs and now are using the largest of the devices and those who previously designed ASICs and have moved to FPGAs for all new products. The ASIC to FPGA converts like to follow an ASIC-like methodology and rigorously verify the design at each step. The small to large FPGA designers are used to the blow-and-go method of validation whereas they program the device and put it into the system board or prototype to see if it lights up.
The late stage bugs each camp faces are the same. Both use intellectual property (IP) blocks to build the sophisticated FPGA design. Both experience issues in the lab where the physical IP behaves differently than simulation or discover other functional defects. The blow-and-go technician must now employ more formal ASIC-like design and verification approaches, since the blow-and-go methodology is a divergent approach as the design size grows.
The capability that they both need is to see the real chip behavior early in the design cycle. Since FPGAs are a significant part of the design complexity, how can they see the real world behavior early in the hardware design phase? Nothing beats Device Native verification for ensuring a quality product.