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.