Experienced verification engineers know that most killer bugs lurk deep in the corners of the design, triggering only when certain combinations of conditions occur. Most modern functional verification techniques, from formal analysis to constrained-random stimulus backed by functional coverage, are expressly designed to try to catch corner-case bugs. But what about corner-case conditions in our lives? It's too bad that we have no methodology to catch these!
An example comes to mind that I'd like to share; the impending holidays seem like the right time for a light-hearted blog post rather than another rant against Accellera's ongoing slippage of the Universal Verification Methodology (UVM) release schedule. I recalled this example yesterday when I read a nice profile of Gordon Bell on the Electronic Design Website. Gordon is truly a legend in the electronics world -- the second engineer ever hired at Digital Equipment Corporation (DEC), founder of Encore, NSF computing guru, and currently a principal researcher at Microsoft.
I had the great pleasure of working with Gordon at Ardent Computer and its successor Stardent, but it was at DEC where I first met him and where he taught me about corner-case conditions. That was way back in 1979, when I was an undergraduate working as a summer intern in DEC's corporate research group at "The Mill" in Maynard, MA. My job was to write a Pascal computer program to allow users to enter data in tabular form and then graph it using a variety of formats. Looking back, it was basically a primitive spreadsheet, but designed more to show off the capabilities of some spiffy new DEC graphics terminals than to do actual financial analysis.
At the end of the summer, I gave a presentation and demonstration of my program to a group of senior DEC engineers, including Gordon. He was VP of R&D at that time and already an industry heavyweight. I was naturally a bit nervous presenting to him and his colleagues, but I seemed to be doing OK when Gordon suddenly asked me about the maximum number of rows and maximum number of columns allowed. When I told him, he instructed me to request a table using these maximum values. I did so, and my program promptly crashed. I had done some ad hoc testing as a natural part of development, but certainly had never done anything like real verification.
I think that I redeemed myself a bit by finding the bug and fixing the program on the fly; I had reversed the variables MAXCOLS and MAXROWS in bounds checks for the user-requested table values. But I never forgot the valuable lesson I learned from Gordon Bell that day. He knew quite well that people often don't consider corner-case conditions. Granted, the combination of maximum rows and maximum columns was hardly a tricky one, but my minimal testing meant that it was enough to crash my program.
Now that I'm in the verification business, I offer this example to remind you all to think a lot about your corner cases and to exercise them thoroughly. A million-dollar chip turn is a lot more embarrassing and much more of a career risk than a public lesson from an engineering guru!
Tom A.
The truth is out there...sometimes it's in a blog.