I observe the following in Source Code of class uvm_transaction ::
virtual task my_sequence::body();
...
start_item(item);
item.randomize();
finish_item(item);
// return from finish item does not always mean item is completed // [ A ] Doubt here
item.end_event.wait_on();
...
Now within user_drirver we have 2 ways to code ( clubbed into single code to avoid extra code ) ::
task main_phase(uvm_phase phase);
`ifndef GET // Using get_next_item and item_done
forever begin
seq_item_port.get_next_item(req);
m_bfm.drive(req);
seq_item_port.item_done();
end
`else // Using get
forever begin
seq_item_port.get(req);
m_bfm.drive(req);
end
endtask: run_phase
Using +define+GET , finish_item(req) unblocks as soon as user calls seq_item_port.get(req) i.e driver is yet to finish sending the request over the interface .
Have a few questions ::
[Q1] Is this what [A] within body() task meant ?
If that’s the case , how would the driver use ’ end_event ’ to indicate proper completion of Request item ?
Comments within Source Code of class uvm_transaction mention ::
A <uvm_event> that is triggered when this transaction's actual execution on the bus ends, typically as a result of a driver calling <uvm_component::end_tr>.
Processes that wait on this event will block until the transaction has ended.
[Q2] What extra logic is required at driver’s end ? Would it possible to share a code snippet i.e what would unblock item.end_event.wait_on() in body() task ?
[Q3] Also if the extra logic is absent at driver’s end would the item.end_event.wait_on() in body() task remain blocked forever ?