Fault Dropping Improves Certitude™ Efficiency & Quality of Results
One important goal of the Certitude development team is to continually improve the quality of the results presented to the user for analysis. By quality, we mean relevance to “big problems” in the user’s verification environment and uniqueness – the likelihood that any given non-detected (ND) fault from a particular iteration of the tool points to a problem that is different than the other ND faults. A related goal is efficiency – the quick isolation of a few important problems that should be investigated and fixed before continuing. One of the processes that greatly improves both quality of results and efficiency is fault dropping.
Concept & Benefit
The motivation for fault dropping is the idea that if a particular fault
cannot be detected (i.e., is ND), then many related faults will not be detected
for the same reason (e.g., missing or weak checker in the verification
environment). Thus, if we can find a
good definition for “related faults”, then we can present the user with a
single ND that, if addressed, is likely to fix many other potential ND
faults. The benefits to the user are
significantly reduced analysis and debug overhead and overall faster
qualification of the verification environment.
For example, instead of sorting through and investigating 20 ND faults
that together point to the same five checker weaknesses in the user’s
verification environment the user is presented with one ND for each of the five
unique weaknesses.
Finding Related Faults: Logic Cones
One
reasonable way to identify related faults is to group faults based on their
proximity from a logical perspective.
More to the point, faults in the combinational cloud of logic that
impact (feed into the data input of) the same register or set of registers can
be said in some ways to be in “close proximity” to one another and therefore
related. Of course, this is not a
perfect measure, but in practice it turns out to be highly relevant, at least
from a qualification standpoint. In
Certitude, the cone of logic is first calculated forward from the fault to the
impacted registers, and then back through the logic to the previous rank of
driving registers. Figure 1 illustrates
this concept.
Figure 1: Logic cones in Certitude
Applying Fault
Dropping for Higher Quality Results & More Efficient Operation
In Certitude, the task of grouping faults by cone falls to the Optimizer, a
process that runs during the model phase and performs a static analysis of the
design. The Optimizer tags faults that
are in the same logic cone. Later,
during the detect phase, when Certitude finds an ND fault, it uses the
information from the Optimizer to drop the related faults. In this case, “drop” simply means “defer the
qualification of these faults until later”, with “later” being after the user
fixes the verification environment and qualifies the initial ND. After the original ND is qualified and
detected (D), Certitude will attempt the qualify the previously-dropped
faults. In the typical case, many of
these faults will now be found to be D due to the same fix. Using this technique, Certitude enables
finding and fixing important problems quickly with a minimum of simulation and
analysis time.
