HAVEN: Non-accelerated version

The non-accelerated version of HAVEN presents a similar approach to functional verification that is commonly used in verification methodologies. This version is highly efficient in the initial phase of the verification process when testing basic system functionality with a small number of transactions (up to thousands).

In this phase it is desirable to have a quick access to the values of all signals of the system and to monitor the verification process in a simulator. Coverage statistics (code coverage, functional coverage, path coverage, etc.) provide a feedback about the state space exploration and allows the user to arrange constrained-random test cases properly to achieve even higher level of coverage.

Despite all these advantages the application of the non-accelerated version is very inefficient for verification of complex systems and/or large number of test vectors. The rising complexity of verified hardware systems increases the time of simulation and also memory requirements on the storage of detailed simulation runs.

Architecture of software framework

Basic components of the non-accelerated version of the framework are illustrated in figure and their detailed description follows.

  • Design Under Test (DUT) - the verified hardware system which is connected to the software verification environment through a set of interface signals created in SystemVerilog. During the software version of verification the DUT runs in a simulator.
  • Testcases - are written by a user, who builds verification environment either from available components (defined in SystemVerilog packages, or methodology libraries) or her own components. The Testcase is the reserved place for setting generics and parameters like transaction count, delays between or inside transactions or the version of the framework to run. The user creates a test sequence, which contains instructions for the Input Controller to manage constrained-random stimulus generation, sending of directed stimuli or synchronization between transactions. We support two types of transactions: data transactions, which are either randomly generated or direct, and control transactions (start, wait, waitforever, delay, stop).
  • Input Controllers - interpret instructions from testcases. The class hierarchy defines basic Input Controllers to manage randomly generated or direct transactions. If random stimuli are required, it is necessary to call the software Generator. For the following processing of transactions, the Input Controller hands over the control to the Software Driver. It is recommended to create an independent Input Controller for every interface protocol through inheritance from basic classes.
  • Generator - produces constrained random stimuli, which are typically random data and random delays between and inside transactions in the range specified in the Testcase. SystemVerilog provides a set of functions that can be used for randomization.
  • Software Drivers - receive instructions from assigned Input Controllers in the form of task calls and also transactions through the Transaction Mailbox. The driver breaks data transactions down into individual signal changes and supplies them on the assigned input interface of the simulated DUT. The copy of the data transaction is sent to the Scoreboard. The driver may also inject errors or add delay parts.
  • Software Monitors - drive simulated DUT's output interfaces, observe signal transitions, group them together into high-level data transactions and pass them to the Scoreboard.
  • Scoreboard - compares expected transactions (received directly from a Software Driver or modified according to the evaluation function of the DUT) with transactions received from a Software Monitor. If they do not match, the Scoreboard reports an error. The Scoreboard contains special functions for preprocessing (data transformation before sending a transaction to the DUT, e.g. to meet special requirements of the input interface protocol) and postprocessing (data transformation before sending the transaction to comparison function in the Scoreboard to catch data modification in the DUT).