Callback in SystemVerilog

One of the main guidelines of this book is to create a single verifi cation environment that you can use for all tests with no changes. The key requirement is that this testbench must provide a “hook” where the test program can inject new code without modifying the original classes.

Your driver may want to do the following:

• Inject errors
• Drop the transaction
• Delay the transaction
• Put the transaction in the scoreboard
• Gather functional coverage data

Rather than try to anticipate every possible error, delay, or disturbance in the flow of transactions, the driver just needs to “call back” a method that is defined in the top-level test.
The beauty of this technique is that the callback method can be defined differently in every test. As a result, the test can add new functionality to the driver using callbacks, without editing the Driver class.
For some drastic behaviors such as dropping a transaction, you need to code this in the class ahead of time, but this is a known pattern. The reason why the transaction is dropped is left to the callback.

As shown in "Developer code" the Driver::run task loops forever with a call to a transmit task. Before sending the transaction, run calls the pre-transmit callback, if any. After sending the transaction, it calls the post-callback task, if any. By default, there are no callbacks, so run just calls transmit.



You could make Driver::run a virtual method and then override its behavior in an extended class, perhaps MyDriver::run. The drawback to this is that you might have to duplicate all the original method’s code in the new method if you are injecting new behavior. Now if you made a change in the base class, you would have to remember to propagate it to all the extended classes. Additionally, you can inject a callback without modifying the code that constructed the original object.

A callback task is created in the top-level test and called from the driver, the lowest level of the environment. However, the driver does not have to have any knowledge of the test – it just has to use a generic class that the test can extend.
 

Limitations of SystemVerilog callback (w.r.t. uvm_callback).

• You cannot control particular nth number of transaction. Callback affects all the transaction or in random manner if you use randomization in extended callback as I had used in above both examples. For example you want initial some (n) transcation to drive without any modification, then for particular (n+1) transaction you want to modified its content. Then again for rest of all transaction you don't want any modification. This is not possible with SystemVerilog callback.
• You cannot Add or Delete callback runtime.

UVM Callback with example

Callback mechanism is used for altering the behavior of the transactor(also called BFM) without modifying the transactor. One of the many promises of Object-Oriented programming is that it will allow for plug-and-play re-usable verification components.
Verification Engineers will hook the transactors together to make a verification environment. In SystemVerilog, this hooking together of transactors can be tricky. Callbacks provide a mechanism whereby independently developed objects may be connected together in simple steps.

Some requirements are often unpredictable when the transactor is first written. So a transactor should provide some kind of hooks for executing the code which is defined afterwards. In uvm, these hooks are created using callback methods.

For instance, a driver is developed and an empty method is called before driving the transaction to the DUT. Initially this empty method does nothing. As the implementation goes, user may realize that he needs to print the state of the transaction or to delay the transaction driving to DUT or inject an error into transaction. Callback mechanism allows executing the user defined code in place of the empty callback method without changing the behavior of the transactor(BFM).

Sometimes we are using third party VIP in our verification environment. Third party wants their code to be encrypted and also wants to give facility to their customer to change the behavior of driver(BFM) without allowing to modify driver code. In this case they provide hooks at some particular places like just after getting transaction from sequence (after get_next_item), just before start driving to the interface, etc. These hooks are created using callback.

Other example of callback usage is in monitor. Callbacks can be used in a monitor for collecting coverage information or for hooking up to scoreboard to pass transactions for self checking. With this, user is able to control the behavior of the transactor in verification environment and individual testcases without doing any modifications to the transactor itself.

Let's go through one callback example in which error is injected through callback of driver.