How do you define and hit corner cases?

Newsletter · Original Contribution Joined: Dec 08, 2003 Posts: 1107

(Originally from Issue 4.4, Item 1.0)

From: Hans Jurgen Vetter

I'd like to raise few questions to the audience of your Verif Guild
email letter:

1. Do you see conceptional limitations of the "directed random testing"
methodology?

2. What is your definition of a "Functional Verification Corner Case"?

3. What qualifies a functional test scenario as a "corner case"?

4. Can you assure the completeness of a set of corner cases and how?

I'm a so called product specialist for functional verification tools
at Mentor Graphics, based in Munich. My experience (3 years ASIC
design (Fujitsu+MHS), 5 years silicon foundry backend (MHS), 8 years
ASIC emulation (QDS+MG)) so far led me to the following:

1. There is no way to assure completeness of functional coverage, you
just try (hard) to come as close as possible ...

2. Minutes-of-realtime funtional verification is a dimension better
than millisecond or even just microseconds ... ;-) ... so what?

3. The quality of data streams used for functional verification is the
key aspect, but still not something, which is measureable ...

So if project managers starts using, lets call it "test-IP" or
pre-verified testbenches (of all sort of abstraction), they have to
think deeper into the aspect of functional verification coverage or in
this sense "quality of test-IP" ... what have you as a project leader
experienced so far?

I really appriciate all sort of responses (good+"bad") of you experts
out there fighting the next ASIC respin ... (or do you do all FPGA
prototyping by now? ...)

- Hans Jurgen Vetter, Mentor Graphics

Newsletter · Original Contribution Joined: Dec 08, 2003 Posts: 1107

(Originally from Issue 4.5, Item 7.0)

From: Richard C. Ho

When it comes to functional verification, coverage generally only
tells you when you missed something. And a "corner-case" is nothing
more that a functional event that is _likely_ to be missed.
Traditionally a corner case is just something that happens rarely,
whether in real operation of the device or just in simulation. A
typical example of a corner case is the situation of an interrupt
arriving at a processor on the same time as a cache line miss is being
serviced. Intuitively, this is a rare event and something that the
designer of the hardware may have overlooked. Hence, the general
assumption is that untested corner-cases equals bugs!

So the question that has floated around for a while is how to define
and measure all these corner-cases in a design? There have been a
number of proposals, but one that is relevent today in the context of
assertion-based verification is to use the information in assertions
to identify them. An example of this is the 0-In CheckerWare library
of verification IP. These components wrap up assertions and
instrumentation to measure corner-cases together. So users who place a
CheckerWare component to monitor a fifo are also placing verification
code to measure the corner-cases associated with the fifo. In a sense,
the corner-cases come for "free" by using the verification IP. This
provides an easy way to not only check the functionality of the
design, but also to measure verification effectiveness.

- Richard C. Ho, 0-In Design Automation