YARP Generator

The transaction class implemented in the last module is responsible for generating the random stimulus which will be applied to the DUT. The generator class uses the transaction class to generate transactions which can then be sent to the driver. However, apart from generating transactions, the generator class also allows us to override the functionality of the base transaction class by the classes which extend from it.

As we discussed, the transaction class would include all the inputs to the DUT and will try to randomize those under certain constraints to ensure the random values still meet the design specifications and do not generate any illegal stimulus. However, a lot of times it is required to have a better control on the kind of stimulus which gets generated by the transaction object after randomizing it. As an example, if you would want the transaction class to only generate R-type instructions only, you could add a constraint in the transaction class to specify that opcode is always of R-type. This would work well but is not a good solution since you have to make changes in an already implemented class. An important testbench guideline suggests making as few code changes as possible to the existing testbench classes. Hence, it would be better to have a way to override the functionality of the transaction class. As we saw in the APB generator class, the generator class allows us to override the functionality of the transaction class with the help of a blueprint pattern.

Let's see how the generator class allows us to not only generate transactions using the transaction object but also give a way to override functionality.