Designers and Verification Engineers: Living in Different Worlds Together

As I discussed at last week, there are many different engineering roles involved in the development of a large, complex semiconductor device. The EDA industry attempts to serve nearly all of these groups, from the architects and product marketing engineers who dream up the new ideas to the technicians who test production parts on the factory floor. Today I’m focusing on the work of two of EDA’s most traditional customer bases: hardware designers and hardware verification engineers.

Perhaps I’d better explain my title. It comes from an old expression “we went to different schools together” that I remember hearing as a youngster. Sometimes this refers to two people who didn’t actually attend the same school but who are nevertheless longtime close friends. But I’ve also heard it used to refer to two people who did in fact go to school together but had very different experiences. This latter context is the one I have mind for design and verification engineers who work on the same project yet inhabit different worlds.

The main catalyst for this week’s topic was a recent blog post by Brian Bailey on the SemiconductorEngineering site. In discussing ideas gleaned from events at the DVCon show, he said “one of the trends that struck me this year is the growing divide between design and verification.” That’s a strong statement, and it immediately started me thinking. Is this really the case? Are the worlds of designers and verification engineers really growing further apart?

At first thought this seems counter to recent trends. For years the EDA industry and many chip project managers have tried to break down the walls between the different roles and groups. Linking architectural simulation to RTL verification, passing assertions from designer to verification engineer, and deriving production test vectors from simulation test suites are just a few examples of the efforts that have been made. It seemed to me that some real progress has occurred in some of these areas.

Digging deeper into Brian’s comments, I realized that he brought out some important differences in the ways that design and verification is performed today. As one example, the advent of constrained-random stimulus, especially as standardized by the Universal Verification Methodology (UVM), has largely automated the process of generating functional tests for RTL designs. Portable stimulus solutions such as Breker’s Trek family of products generate tests even more quickly, and target multiple platforms.

Brian noted that this same level of automation is not currently available to designers. “The industry is talking about most of the design complexity being in the selection, configuration and integration of IP blocks.” Indeed, there are not many EDA tools or methodologies to help in these tasks. The lack of correct-by-construction solutions not only makes the job of the designers harder, but also passes on the burden of verifying integration to the chip-level verification team.

The good news is that design reuse, both internal and via commercial semiconductor IP, is widely adopted. Even if the process is far from ideal, in practice only a small portion of most new chips is designed from scratch. In contrast, verification reuse is still limited. The UVM supports only certain forms of model portability across testbenches, with no links to other verification or validation platforms. Portable stimulus addresses this domain very well, but is not yet universally adopted.

The history of chip development hold many examples of technologies being passed around between design and verification. Code coverage began in software, passed to RTL, and finally took hold in testbenches. Functional coverage started primarily with testbenches and is still gaining traction in hardware and software design. Assertions were used for software reliability and for formal analysis of hardware designs, and have met in the middle as a common way to capture design intent.

But not all techniques work as effectively for all users. Brain reported the DVCon statement that “verification engineers are three times more productive in the creation of properties and assertions” than are designers. He cites this situation as an example of the “technological divide between design and verification” that “continues to grow.” Apparently, assertions are not yet fulfilling their promise as an effective intent communication vehicle.

Assertions are not the only example; in the same post Arturo Salz of Synopsys points out that verification teams incrementally adopt new techniques all the time and move faster than designers who are “still stuck using RTL.” Indeed, proponents of high-level synthesis (HLS) argue that the design side would benefit greatly from greater abstraction, object-oriented coding, and other technologies already widely used in verification. So far, not that many designers have made the move.

So how can we improve the situation? Brian mentions “buddy” teams of design and verification engineers working closely together. He also states that the off-shoring of verification away the design teams has been “a rather disastrous trend that has since reverted to some degree.” Another idea that was quite popular a few years ago was the “tall, thin engineer” responsible for design, verification, and even layout (in contrast to the “short, broad” specialists).

Here at Breker, we have seen our graph-based scenario models become popular with both designers and verification engineers, serving to communicate verification intent among different teams. I believe that portable stimulus will help bring architecture, design, verification, and validation all closer together. What do you think?

Tom A.

The truth is out there … sometimes it’s in a blog.

Tags: Accellera, assertions, Breker, code coverage, coverage, dvcon, EDA, formal analysis, functional coverage, functional verification, graph, graph-based, IP, portable stimulus, PSWG, reuse, scenario model, SemiconductorEngineering, simulation, SoC verification, system coverage, test generator, uvm

This entry was posted on Tuesday, April 19th, 2016 at 5:01 pm. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.