Protect your goal with post-silicon formal verification

7/19/2010 8:03 PM EDT

One of its most valuable features is the ability to find bugs fast. Usually, finding counter-examples (a stimulus sequence from a legal design state that violates an assertion) with formal is much faster than reaching full proofs on the same property, and this technique lends itself very well to bug hunting. Using formal verification the user can “freeze” a specific state in a specific cycle, and then continue the analysis from just that point, making it unnecessary to analyze the entire design. Additional insight is gained through the use of the Visualize feature in Jasper formal tools to automatically generate and manipulate waveforms without a testbench, answering “what-if” design questions and providing visual confirmation of design functionality.

Finding the bug with formal follows almost the same process as in a pre-silicon formal verification flow. There are, however, some significant differences:

·         Search is for one specific bug, one specific scenario

·         Not looking for full proof or coverage completeness

·         Just need to find the scenario that leads to the illegal behavior

·         Can allow over-constraints to simplify the process (e.g., don’t allow Write transactions because the bug happens with Read transactions only)

A couple of powerful examples of formal use in the post-silicon lab illustrate its value and what we like to call formal’s ROI – or when your technology investment pays huge dividends. One of our newer customers was using simulation and emulation only, but even after weeks of exhaustive testing, a corner case and cycle-dependent bug was found, something easy to miss with traditional methods. After modifying the design they checked their results using formal and in a short amount of time (mere hours rather than weeks) it was learned that the fix was broken, resulting in yet another scenario that would cause the bug. Another ECO followed and formal verification showed the same bug in a different part of the logic which led to a third and final fix that passed the formal check with no problem.

An even more serious instance involved a customer’s large SoC hanging up in the field, resulting in a silicon recall. The post-silicon debug team used directed random-simulation starting with the little information available from the lab. They knew the chip was hanging and the problem was coming from the memory controller when it performed a read transaction. Without formal they worked more than three months and still did not isolate the bug’s root cause. Imaging sitting in those progress meetings! It was identified in the memory controller, sending its data to the wrapper block in a very specific pattern that activated a bug in the wrapper and caused a violation of the bus protocol. This timing alignment of different events in the system was very hard to hit with random simulation, hence it escaped as a silicon bug and was extremely difficult to detect in post-silicon simulations.

Formal was then used to root cause the bug and the engineer was given exactly the same information that the simulation team started with. In this case, the bug was found after just 2.5 weeks, and much of that time was spent ramping up on the design and protocols involved. Actually, once the setup was finished, and properties written, the runtime to find the counter-example was less than a minute – compared to weeks of simulations trying to hit the bug randomly. Afterward, formal was re-run on the fixed RTL code and uncovered two more bugs that the post-silicon simulations missed, saving the chip manufacturer another re-spin.

Just like the goalie, protecting your net by keeping those little bugs from sliding past in the post-silicon lab is essential since mistakes there can have devastating consequences. Given the exhaustive analysis performed by advanced formal verification techniques conclusive answers can be generated – often in minutes vs. days – as to whether or not a particular verification component is the source of the undesired behavior, enabling quick isolation of the root cause of the problem, and then verifying that resulting design modifications are valid.

About the author:

Lawrence Loh is Vice President of Worldwide Applications Engineering for Jasper Design Automation.

He holds overall management responsibility for the company’s applications engineering and methodology development. Loh has been with the company since 2002, and was formerly Jasper’s Director of Application Engineering. He holds four U.S. patents on formal technologies.

His prior experience includes verification and emulation engineering for MIPS, and verification manager for Infineon’s successful LAN Business Unit. Loh holds a BSEE from California Polytechnic State University and an MSEE from San Diego State.