Verification solutions that help reduce bug cost

I think very few engineers would argue with the claim that the longer a bug goes undetected, the more expensive it is to fix. In fact, the general rule-of-thumb is that the cost to fix a bug increases by an order of magnitude as a project progresses from one milestone to the next. Bugs found before simulation obviously have the lowest cost. Bugs found at block or subsystem simulation are generally easier to debug and incur a lower cost to fix versus bugs found at high levels of integration—such as chip- and system-level simulation. Bugs found during post-silicon validation might require a new spin of the chip, while bugs found after product release can be devastating, costing millions of dollars to fix.

Years ago, while conducting an assessment on a project team trying to improve their processes, I learned that a simple bug had escape through the project’s verification process and resulted in a  respin. I refer to this as a simple bug since it could have been easily caught by running a static linting tool. The interesting fact related to this particular bug was that the project team was fairly mature in its verification processes—having adopted constrained-random and coverage-driven verification approaches.

Now, don’t misunderstand what I’m saying—I’m certainly not claiming that you only need static linting to solve all your verification challenges. The same could be said for any single verification solution—after all, verification is an exponential problem. However, there are a few valuable lessons in the simple bug example I just gave. That is, the longer a bug goes undetected, the more expensive it is to fix—and that multiple verification solutions are required to minimize risk for today’s complex designs.

One interesting verification solution that has emerged recently uses formal verification technology to automatically perform a set of design checks for a common set of RTL problems. The key point here is that the user does not need to be an expert with formal technology. This aligns well with my philosophy that any solution that is easy to use and finds bugs as early as possible within a verification flow is worth investigating. What’s interesting about this verification solution is that it can verify a class of problems that cannot be found using static linting tools as well as a class of problems that cannot be found with traditional four-state RTL simulation.

If you are interested in learning more about this verification solution, I would like to invite you to check out the web seminar “Questa Formal’s AutoCheck – The Push-Button Way to Find Bugs,” which is part of our free Transforming Verification On Demand Series of webseminars.