Anyone who has worked on a microprocessor design in recent years knows that verification has become a larger and larger share of the effort to bring a product to market. Designs are becoming increasingly complex and this complexity is often magnified in verification. Since completed verification is always the final stage in the design cycle, the additional time, effort and resources required are in the critical path to get the design out the door. For this reason, selection of verification tools has a direct effect on the total cost of the design and on meeting the time-to market criteria.
Through a series of upcoming postings, we will seek to outline several usage models and technologies while highlighting their strengths and weaknesses and providing a platform to judge the best verification strategy for a given product.
The goal of verification is to achieve bug-free first silicon on schedule. However, determining the absence of implementation flaws is no easy task; engineers must find an undetermined number of design flaws in an infinite space.
Determining when verification has reached completion is also a difficult task. This is typically based on heuristics, statistical measurements and experience. On all but the simplest designs, there is no point where the verification lead can say that the design has been completely tested and is known not to contain any hidden errors. Instead, verification engineers rely on proven methodologies, apply legacy test suites, and create sample applications to simulate real world conditions to the best of their abilities.
Functional verification typically involves running a large number of assembly level tests in RTL simulation. Figure 1 depicts a simple environment in which an external stimulus is applied to the device under test (DUT). The more random tests that are run in RTL pre-silicon, the greater the chance the DV team has of finding all the bugs.
Figure 1. A Simple Verification Testbench Environment
