Tuesday, 29 December 2015

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.

No comments:

Post a Comment