Practical Chip Design

Jun 4 2007 12:13PM | Permalink | Email this | Comments (3) |
Blog This! using:  Blogger.com | LiveJournal |
Digg This | Slashdot This | add to Del.icio.us

During last night’s panel discussion (see my previous entry) panelist Riko Radojcic made a fascinating observation. We were discussing why it was that logic verification still scored so high in designers’ lists of most serious challenges. After all, we’ve been doing it for years, and huge amounts of tool R/D have been poured into the problem.

The conversation started with Broadcom director of engineering David Crohn making the observation that even though we’d been working on verification all this time, system complexity has continually outpaced our growing ability at verification. So at the end of all the investment, new tools and learning, we are further behind than we were five years ago. He and others on the panel added that some of the new advances that really do have some leverage over complexity, such as the widespread use of embedded assertions, have not been widely adopted by engineers, many of whom are either too buried in work or too set in their ways to pick up a new way of thinking about design.

At this point Radojcic suggested that maybe in the context of SoCs, traditional logic verification was the wrong definition of the problem. He pointed out that SoCs really do comprise systems now, not subsystems, and that we should be thinking not in terms of logic verification but in terms of system verification—an altogether less precise approach. The question in system verification is not whether every element in the system is functioning perfectly in every possible state. The question is whether the system does what the designer intended and the user expected.

This raises a host of interesting issues. To begin with, it is predicated on the assumption that there is someway of capturing both the designers’ intent for the system behavior and the user’s expectations, presumably in a machine-useful form. That challenge in itself seems to me significant, perhaps similar in difficulty to creating an effective Electronic System Level (ESL) language.

Second, the idea seems to assume that there is some way of comparing simulations of system behavior against expected behavior so that ambiguity is tolerated. This introduces the whole concept of “close enough” to the verification process. Clearly comparisons of output vectors are not sufficient. (At this point analog designers must be rocking back and forth in their chairs over the irony of it all.)

In fact, qualitative system verification is already practiced in some areas, even in digital design. Audio and video compression engines, for example, not only undergo traditional hardware and software verification cycles, but they get listening and viewing tests—in dark and quiet rooms with the golden ears and golden eyes carefully cultivated for the purpose by systems vendors. If a CoDec is logically correct but Ms. Goldenear doesn’t like the sound coming out of the speakers, then the design’s not right yet. (See, for instance, this article on testing audio ICs.)

Can such approaches be used for verification of entire SoCs? It’s an open question, but a very interesting one, suggesting lots and lots of good thesis projects. But it has one huge factor in its favor: how else can verification hope to cope with the escape-velocity growth in system complexity?