Corner Cases and Verification Thinking

A corner case is a boundary or unusual operating condition where a design is more likely to fail. Good verification is not about collecting the largest possible number of tests; it is about making each test probe a distinct promise.

Typical corner cases are:

• reset, including reset arriving while the design is busy rather than only at startup;
• the first step after reset;
• the smallest and largest values, and the step onto or past a limit;
• a control input changing, or holding one value for several clock edges.

For each proposed test, write one sentence: “This case could expose ___.” Fill the blank with a wrong design that would fail this test while the tests you already have pass. If you cannot fill it, or two tests complete it in exactly the same way, keep the clearer or cheaper one and look for an uncovered boundary.

A four-bit greater-than check shows the method. The test a = 5, b = 5 catches a design written with >= instead of >. The test a = 8, b = 7 catches one that ignores the top bit. A later a = 9, b = 3 adds little: the likely mistakes it could catch, such as ignoring the top bit, the a = 8, b = 7 test already catches.

Clocked designs add one more question: which state a test starts from. The same input can behave differently in different states, so a test that repeats the same inputs, from the same state, with the same checks, adds nothing new.

A compact suite should be deterministic, quick to run, and varied enough that different incorrect implementations fail for different reasons.