THE VLSI HOMEPAGE

Verification consumes more than 70% of the effort and is on the critical path to tapeout in today’s complex, multimillion gate ASICs. To expedite the time-to-market duration, current methodologies focus on parallelizing verification effort with design, automate the verification process partly and also verify at higher abstraction layers.

A typical verification flow is shown in the figure below.

Design Verification Flow

The architecture spec details the chip functional requirements and features to be supported and is the starting point for both design and verification. The Verification plan clearly defines the features that will be verified in the design and prioritize testcases based on the schedule and critical features. The entire testsuite will be covered in the plan and both the design/verification teams review this VP to ensure that there are no holes in verification and that all features will be verified.

The verification environment can be a black-box model with no knowledge of implementation details - it applies the appropriate stimulus at the design inputs and checks the outputs against expected behavior. The entire design is black-boxed and advantages is reusability of generic verification IPs. Alternatively, it can be a white-box model with full controllability and observability in the design.

The verification environment integrates the stimulus generators, bus functional models, checkers and scoreboards usually written in a high level verification language (HVL) like specman ‘e’ or Vera. We will cover these modules in detail in another post.

Testcases can be either random or directed - directed testcases as the name indicates stimulate only one particular feature in the design and observe the response. Random testcases exercise the design within bound but random constraints. The VP determines the number of testcases to be written and the regression suite covers all these testcases.

Coverage metrics track the progress of verification and help in identifying the holes in verification. Any bug uncovered in the regression suite is filed in a bug-tracking database and fedback to the design team for correcting the design. Verification is said to be 100% done when the coverage metrics meet the goals defined in the verification plan.

Janick Bergeron’s “Writing Testbenches” covers the entire verification cycle in detail and is highly recommended for any newbie/experienced verification engineer.

Share This