Design, Verification: What's the Difference?

by Scott Sandler

The Genesis of Convergence

What is design? The Merriam-Webster Collegiate Dictionary defines design as "to create, fashion, execute, or construct according to plan." And verify? It is: "to establish the truth, accuracy, or reality of." Considering these ideas, it seems plain that when we fashion, execute, or construct according to a plan we are inherently attempting to do it truthfully, accurately, and realistically. So is this correct by construction? Indeed not! Hard as we may try, we make mistakes in design, often because of a lack of understanding.

Design and verification are two parts of a whole; there really is not, or should not be, a distinction between the two disciplines. Indeed, it is often useful to have different intellects applied to these two views of a single design element, but that doesn't mean there should be a wall between them. On the contrary, the two roles should be treated more like players on a team. The roles can and should be readily interchanged across design elements or through time.

Consider the design and verification process for a typical system on chip (SoC). The design team decides to reuse certain pieces from previous designs, purchase some pieces of intellectual property (IP) from other third parties, and construct some elements entirely anew. Some of the engineers are assigned to "clean up" the legacy code. Others get the job of evaluating and selecting IP from available vendors. And others get to start fresh with a blank sheet for their blocks.

As the engineers explore the "legacy design" elements, are they designing or verifying? They actually believe that these components worked correctly in the previous design, but they're not at all certain about how they work, or whether they'll work completely in the new design. So they need to explore the behavior of the existing logic, thoroughly understand it, and perhaps modify it for their purposes. This process is simultaneously "fashioning to a plan" and "establishing the truth."

Indeed, the engineers who are evaluating IP are doing exactly the same thing. They devise a scheme to check whether the commercial IP does what the vendor says - to establish the truth and accuracy of the claims. Is this evaluation or verification? Can we tell the difference? And once they procure the stuff, what will they do? Real-world experience says that more often then not, they'll need to modify the IP to re-construct it according to their specific plan.

And what of the engineers who got what is usually considered to be the best assignment, designing the brand-new blocks? Can they simply construct according to plan and let someone else establish the truth of their work? Typically not. They will likely construct at least a rudimentary testbench for their own blocks to check that they basically work, at least in isolation.

So we already see that the design engineers are performing a mix of tasks, both creating according to plan (designing) and establishing the truth of the work (verifying.) This has been going on all along, even though at times some companies have created organizations and flows that thwart the effort by encouraging designers to throw things over the wall to verifiers.