THE VLSI HOMEPAGE

Traditional verification strategies involve writing directed testcases to exercise all known features of the Design under Test (DUT) and the environment is often written in HDL or ‘C’. This method has proved very tedious and inadequate in addressing all possible scenarios, not to mention the effort/time taken.

A solution to this productivity issue has been to raise the level of abstraction and use constrained random stimulus to stress the design - Hardware verification languages (HVL) like ‘e’ or Vera use Object Oriented Programming (OOP) features, complex data types for higher abstractions, automated configurable tasks and also understand the hardware concepts of time and concurrency.

A typical transaction level verification environment is shown below comprising of two major components - Test functions and Test Harness (from Janick Bergeron’s Writing Testbenches). The Test harness integrates all the transaction layer components necessary to exercise the DUV and is self-contained. Test functions use procedures from the test harness to generate data items and configuration constraints.

Self-checking scoreboards with data extractors, reference models and checkers are also critical parts of Test functions. The coverage analyzer with functional coverage items and cross coverage items also gathers statistics from the generator/monitor to track the verification progress.

Transaction layer verification environment

Traffic generator - As the name implies, the traffic generator generates data items (packets, cells, frames) using OOP cencepts to stimulate the design. These data items are generated randomly but with proper hard and soft constraints so that no illegal data types are generated.

Bus Functional Model (BFM) - BFMs also known as Drivers, model the physical interface of a standard protocol like PCI, SATA to exercise the DUT at one end and at the other end, offer a transaction layer level inteface to the Test functions using procedures.

Protocol Monitors - do not drive any signals, monitor the DUT outputs, identifies all the transactions and report any protocol violations.

Scoreboards - Self-checking, integrates a reference model that dynamically processes the input stimulus to generate the expected output. The transformation is purely functional and does not include any latency and physical interface behavior. The Scoreboard records all transfer function outputs and compares them against Rx BFM outputs for integrity.

Coverage - Random testcase environments are coverage driven - only coverage can track the progress of verification to check if all the possible scenarios have been covered.

Two types of coverage - functional coverage that answers if functionality of the design has been verified and code coverage that answers if particular piece of code has been exercised.

Code coverage includes FSM coverage (if all transitions from one state to another are covered), line coverage (if all the lines in a module are covered), toggle coverage (if all signals are toggling from 0 -> 1 and 1 -> 0) and conditonal coverage (cover all conditions like in a if-else statement).

We will revisit each of these modules in detail with examples in ‘e’ or Vera in another post.

Share This