APB Driver

Toggling the DUT Interface

In the last module we discussed the generator class which included the mailbox to send the transaction object to the driver class. In this module, we would implement the driver class to get the transaction from the generator mailbox and use it to toggle the input pins of our design under test. The driver class allows the testbench to drive the randomized stimulus to the DUT while ensuring that all the input constraints specified by the DUT are indeed met.

Since the testbench here is used to verify the APB Master system and the inputs are just the apb_pready and apb_prdata signals, there aren't any timing relationship/constraints specified. The driver is free to randomly drive both of these input signals without any timing relationships. However, if the DUT was an APB slave then the testbench would have been responsible for generating the APB transactions and would have needed to have the inputs driven correctly. This would have meant things like the apb_psel should be asserted a cycle before the apb_penable signal is asserted. The other attributes should remain stable until the transaction is accepted by the slave and few other things. But our testbench is simple since the goal here is to learn about the testbench architecture by verifying a simple design and then later use these principles to verify a more complex design like a RISC-V Processor!

The driver class would introduce you to the concept of virtual interface and the clocking block. Through the use of virtual interfaces, the dynamically created driver class is able to access the input and output pins of the DUT and drive the input pins. As we will see in the module, the use of clocking blocks helps us design fundamentally correct testbenches free of race conditions while driving and sampling the DUT signals.

Let's see how the driver class gets the randomized object from the generator and then uses the virtual interfaces and clocking blocks to toggle DUT pins.

Testbench_Architecture

Virtual Interface

The driver class for the testbench is responsible for fetching the random transactions from the mailbox (connecting the generator and the driver class) and then using it to toggle the pins of the DUT. The driver class gets access to the DUT pins via the virtual interface. In simpler terms, the virtual interface is just the handle pointing to the actual interface. In our case,

Loading the interactive workspace...