HAVEN

The accelerated version of HAVEN moves the DUT to a verification environment in the FPGA. As gate-level simulation takes the biggest portion of verification time, this approach may yield a significant acceleration of the overall process. Complex systems can be verified very quickly and with much higher number of transactions (in the order of millions and more. Behavioural parts of the testbench, such as planning of test sequences, generation of constrained-random stimuli, and scoreboarding, remain in the software simulator. This partitioning is possible because the generic nature of currently prevalent verification methodologies, such as Open Verification Methodology (OVM) or its extension Universal Verification Methodology (UVM), and transaction-based communication among their subcomponents enables to transparently move some of these components to a specialized hardware, while maintaining good readability for verification engineers.

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

• Design Under Test (DUT) - the verified hardware system is synthesized and placed in the reconfigurable hardware platform (FPGA). This can fully exploit the inherent parallelism of hardware.
• Testcases - are made according to the same principles as in the non-accelerated version. But in addition, the user builds verification environment not only from software components but also connects hardware components. These are defined in special hardware packages.
• Input Controllers - interpret instructions from testcases similarly as in the non-accelerated version, but for the following processing of transactions an Input Controller hands over the control to a Sender. It is also recommended to create an independent Input Controller for every interface protocol through inheritance from basic classes.
• Generator - produces constrained random stimuli.
• Senders - receive instructions from assigned Input Controllers in the form of task calls and data transactions through the Transaction Mailbox. The copy of a received data transaction is sent to the Scoreboard. According to the instruction, the Sender builds data and control transactions for a specific component in the hardware part of the verification environment. In order to deliver the transaction to the correct Hardware Driver, the Sender provides each transaction with transfer protocol headers. Transactions created by all Senders are buffered in the Input Mailbox.
• Input Wrapper - opens a communication channel with the hardware platform at the beginning of the verification run and closes the channel after all prepared data are sent.
• Driver Switch - routes received transactions from the software to the proper Hardware Driver according to the fields in transfer protocol headers.
• Hardware Drivers - perform similar function as their non-accelerated counterparts. The Hardware Driver receives transactions from the Driver Switch and checks transfer protocol headers. Depending on the information in headers the Driver recognises the nature of the transaction: whether it is data or control. In the case of a data transaction the Driver parses the data and propagates them as signal changes to the proper input interface of the DUT. If a control transaction occurs, the Driver performs a specific task depending on the type of the control transaction. Moreover a single driver can manage several interfaces connected to the DUT.
• Hardware Monitors - drive DUT's output interfaces, observe signal transitions and group them together into high-level data transactions. For correct delivery to the proper software Output Controller they also add transfer protocol headers to every data transaction.
• Monitor Switch - collects transactions from Hardware Monitors and prepares them for transmission through the communication channel to the software part.
• Output Wrapper - retrieves transactions from the hardware part using the communication channel. After transactions are correctly received, the Output Wrapper buffers them in the Output Mailbox.
• Sorter - takes transactions from the Output Mailbox and routes them to the proper Output Controller according to the fields in transfer protocol headers.
• Output Controllers - receive transactions from the Sorter and extract transfer protocol headers. According to the information in headers, an Output Controller classifies transactions to data and control. Data transactions are sent in the correct format to the Scoreboard and control transactions are appropriately interpreted.
• Scoreboard - in the accelerated version compares expected transactions (received directly from the Sorter or modified according to the evaluation function of the DUT) with transactions received from an Output Controller. If they do not match, the Scoreboard reports an error. Again there are special functions for preprocessing and postprocessing of data transactions.