2.3.  Model Verification

Of course, if a VC is created, it has to be ensured that it does work correctly. This task is very complex, because there are different chip designs, different development environments and different physical implementations, many different tools. All the discrepancies have to be flattened to produce one final result: the answer to the question if there are any errors to fix. It is quite obvious that there are several methodologies and techniques to verify VCs. They can be split up into four categories (all quotes taken from [VSI01a, p. 2]):

Intent Verification.

“Process of determining whether a design fulfils a specification of its behavior.” The question is: Is it that what we wanted to do?

Equivalence Verification.

This is the process of determining whether multiple levels or formats of a design match in terms of functionality. Mostly the newly created model is verified against the “golden model”. The question is: Is it that what we had to do?

Integration Verification.

“Process of verifying the functionality of a system-on-chip (SoC) design that contains one or more virtual components.” The question is: Is it usable?

VC Verification.

“Process of verifying the functionality of a virtual component, i. e. unit test of that component.” The question is: Does it work?

A large overlap is between these categories without doubt. Many processes are shared e. g. between VC and integration verification, although the actual test code will be diverse for the divergent tasks. The VSIA Functional Verification Development Working Group has produced a taxonomy document reflecting the verification classes and their techniques, see [VSI01a]. In the subsequent sections the four main categories and their methodologies will be discussed. For a specific test, usually not only one technique is used but a combination of some of them. Some depend on others whereas some exclude each other.