Had a follow up question on the same topic. I am trying to create a driver callback which basically writes random(incorrect) data on the interface. However I cannot do a uvm_config_db get to get the virtual interface since the callback is an uvm_object. Is there a way I can get a handle to the interface in a callback or a uvm_object.
Here is the callback I want to implement, the idea is the callback generates junk output values which would be caught in the scoreboard.
class alu_drv_cb extends uvm_callback;
function new(string name = "alu_drv_cb");
super.new(name);
endfunction : new
virtual task corrupt_data();
// Drive random data on interface output, something along the lines of
// intf_handle.intf_c = 'h1234_5678;
endtask : corrupt_data
endclass : alu_drv_cb
In reply to JDoe:
This does not have much to do with the original question. It would have helped to start a new one.
You can call uvm_config_db::get from a class derived from uvm_object. It would just take some work to get the context. A much better OOP approach is not using callbacks and extending alu_driver with the corrupt_data virtual method.
class alu_driver;
`uvm_component_utils(alu_driver)
...
task get_and_drive();
basic_seq_item req;
drv_vif.intf_a = 0;drv_vif.intf_b = 0;drv_vif.intf_c = 0;drv_vif.intf_start = 0;
forever begin
@(posedge drv_vif.intf_clk);
seq_item_port.get_next_item(req);
drv_vif.intf_a = req.seq_item_a;
drv_vif.intf_b = req.seq_item_b;
drv_vif.intf_start = req.seq_item_start;
corrupt_data())
drv_ap.write(req);
//`uvm_info(get_type_name, $sformatf("Driver transaction %s", req.sprint()), UVM_LOW)
seq_item_port.item_done();
end
endtask : get_and_drive
virtual task corrupt_data;
endtask
endclass
endclass
class corrupted_alu_driver extends alu_driver;
`uvm_component_utils(corrupted_alu_driver)
virtual task corrupt_data();
// has access to everything in alu_driver
// Drive random data on interface output, something along the lines of
// intf_handle.intf_c = 'h1234_5678;
endtask : corrupt_data
endclass
Now, instead of your test registering the callback, you factory override alu_driver with corrupted_alu_driver.
Hi Dave,
What if we have to use callbacks and get the interface into the callback object? What could be the approach for that?
I tried creating the callback inside the agent and assigning the interface manually into the object but it’s giving an error that interface is uninitialized inside the callback object.
//sorry that I'm unable to add the indentation here
class callback extends uvm_callback;
virtual interface vif;
//constructor
virtual task drive_data();
endtask
endclass
class child_callback extends callback;
virtual task drive_data();
@(vif.cb); //error at this line: unintialized virtual interface object
vif.cb.data <= 1'b1;
endtask
endclass
//inside agent's build phase
//get the config_h object using config db
callback_h = callback::type_id::create("callback_h");
callback_h.vif = config_h.vif;
//inside test we override the callback with child_callback
//call uvm_do_callback inside driver's run phase
OK, I made a very simple example and found some strange behavior.
See here
It works fine, but adding any time dependence like #… or @(posedge vif.clk) the call back does not get executed.
In the reference manual I did not see any limitstion like this.
Thanks for your response. But I think the way you used callbacks is not entirely correct. We need to add the callback inside test and also we need to call them inside driver through `uvm_do_callback. Correct me if I am wrong.
I had a closer look the callback approach. My understanding is this approach is focussing on modification of seq_items/data packets instead of modifying pinlevel signals. I consider this as useful. In your case you had to implement the pinlevel protocol twice which is not good.
Thanks for effort to provide a response. Now that seems the only way when we are not able to get the interface into the callback object, but I have few doubts following that approach.
I don’t want to modify my driver, I don’t want to create a new sequence for doing this, I want to reuse already existing sequences basically one sequence inside other sequence through callback.
If I start a new sequence inside callback onto the driver it will not take it untill it comes out of the current task but I want the driver to drive some signals when it is inside certain task. Can we start two sequences onto driver once? I don’t think so
Any thoughts on this?
I`m not sure if your conclusion is correct. You do not have to use a seperate sequencer. You can simply modify data packets recveived in the driver using the callback.
Do you know this link:
Hi,
Actually, it is very much possible to get the interface into callback and modify the pin level signals. I was only not able to get the interface through manual assignment inside agent, so I was trying to get the interface by setting inside agent and getting into the callback object through uvm_config_db. I have a problem with this approach as shown below.
//inside agent
uvm_config_db #(virtual vif)::set(this, “callback_h”, “Interface”, uvc_if);
//inside callback
uvc_config_db #(virtual vif):get(null, “uvm_test_top.env_h.agent_h.callback_h”, “Interface”, uvc_if);
Now the above approach is working fine but is not reusable since we’ve given the entire path which changes from project to project. I’ve also tried various other arguments by keeping the identifier same(“Interface”) as shown below but I am only able to get a null interface which is useless.
uvm_config_db #(virtual vif)::set(null, “*”, “Interface”, uvc_if);
//inside callback
uvc_config_db #(virtual vif):get(null, “”, “Interface”, uvc_if);
Sounds good t me.
I believe you do have the right understand when using the arguments of the config_db command.
If the 1st argument is null this indicates you are using an absolute path which requires the whole hierarchy path in the 2nd argument whan using the get.
Using as 1st argument ‘this’ it is indicating a relative path.