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.
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.
GOOD POINT: You clearly explained the use of callback.
ReplyDeleteBAD POINT: The code you put, it looks like it makes the test unreusable since it becomes heavily dependent on the environment since you put the driver there, etc.
It here main intention is to understand concept of UVM Callback not to utilize re-usability.
DeleteI have not added uvm_agent and uvm_env just to make code small.
Nice post for uvm_callback explanation.
ReplyDeleteHi sagar nice post my question is why do we need uvm_callbacks when we can always use set_type_override by type and replace original driver with child driver driver_err?
ReplyDeletePlease refer below post,
Deletehttp://sagar5258.blogspot.in/2016/08/callback-vs-factory-in-uvm.html
How can we send data from a monitor to scoreboard using callback methods? Means without using analysis ports.
ReplyDeleteHi Sujeet,
DeleteTo Transfer data/packet between two components we need some kind of mechanism, it could be either mailbox or Analysis port.
Hello Sagar,
DeleteIs there any callback methods through which we can send the data from monitor to scoreboard? Using analysis port I know it can be done.
Hi Sujeet,
DeleteNo, I don't know any other way.
Hi sagar,
DeleteNice explanation, but as you mentioned this point
"Callbacks can be used in a monitor for collecting coverage information or for hooking up to scoreboard to pass transactions for self checking"
any idea how to hook up monitor with sb so that we can transfer transaction?
You can use callback of monitor class to get transaction and compare it . But generally we do not use that approach. Third party VIP vendor provides callback and than you can use it based on your requirement . Like you want to drop some transaction going to scoreboard/coverage.
DeleteThis comment has been removed by the author.
ReplyDeleteHi Sagar. Good explanation..
ReplyDeleteI have a question here.. which UVM phases can support callback ? can I use callback at run time or in run_phase?
Hi Sagar,
ReplyDeleteIf instead of this mechanism, I simply create an object of my_dri_cb and then add the following line in place of line no. 70-72 of class my_driver:
my_dri_cb.inject_err(tr);
Wouldn't that provide the same output/functionality?
Hi Sagar, in my verification environment Driver is declare in agent, I have created some test cases which i wanted to inject error by using callback, I am confused with the object declaration of callback in class test, when my driver is already declare in agent.
ReplyDeleteHi Gaurav,
Delete"typedef uvm_callbacks #(my_driver,driver_cb) bus_driver_cbs_t;" remains as it is.
bus_driver_cbs_t::add(drv, cb); will change to bus_driver_cbs_t::add(agt.drv, cb);
similarly,
bus_driver_cbs_t::delete(drv, cb); will also change to bus_driver_cbs_t::delete(agt.drv, cb);
where agt is handle of agent class
How to connect driver to scoreboard
ReplyDeleteThis comment has been removed by the author.
ReplyDeleteHi Sagar,
ReplyDeleteCan you please provide any practical scenarios for using callbacks(Error injection) in VIPs for AMBA protocols like AHB, APB, AXI or even Ethernet?
HI Sagar,
ReplyDeleteNice explanation.Thanks ..
yes.
ReplyDeletetwo ways is their: one is creating your own way and another way is, Already before defined dummy methods likepre_*() and post_*() at basic code(UVM code) for phase(ex:in run_phase (reset_phase,config_phase,main_phase,run_phase....)).creating your own way,need to phase synchronization problems(difficult to resolve the issues). another way is simple and call where ever predefined the callbacks for particular phase.
Hi Sagar ,
ReplyDeletecould you help in out with the below questions
1.How callbacks will be used in drop the packet.
2.How callbacks will be used in coverage aspects.