In the UVM Cookbook, on page 157, there is the following diagram:
I’m having trouble understanding why some of the arrows are dashed while others are solid. One might assume that the difference indicates blocking (time-consuming) versus non-blocking (instantaneous) calls. However, the arrow from start_item is solid, while the arrow from get_next_item is dashed, even though both calls are blocking.
I believe the dashed lines point to the code flow.
(1) get_next_item() leads to Sequencer arbitration.
(2) Once a sequence is selected, start_item in the respective sequence would unblock and the code following start_item executes till it reaches finish_item.
(3) Call to finish_item(), unblocks get_next_item() in the driver and then the code in the driver executes ( indicated by dotted lines ) till it reaches item_done(). finish_item() unblocks once item_done() is called.
Also if I recollect correctly code flow post item_done() continues till it blocks in driver ( eg: call to next get_next_item() ). This is when finish_item() unblocks to be precise
Thank you for your reply, you have a good point! However, in that case, it seems there shouldn’t be a dashed arrow from finish_item(), since once it’s blocked waiting for item_done(), there’s no active code flow in sequence domain. Or am I missing something?
The dotted line from finish_item points to code within the sequence body() that is written after call to finish_item. An example would be get_response( rsp )
But shouldn’t that flow start only after item_done from the driver? Something like this:
I would agree if it were a get/put execution, where finish_item unblocks simultaneously.
It still looks like the authors were illustrating the blocking nature of these calls:
Blocking nature of start_item. There’s a solid arrow starting from start_item, since it simultaneously places the req into the sequencer’s request FIFO.
Blocking nature of get_next_item. Since the driver doesn’t actually do anything in this call except wait for the next request, there’s no other solid line there.
Blocking nature of finish_item. There’s a solid arrow starting from finish_item, because that call simultaneously sends the request to the driver through the sequencer.
As I mentioned earlier that item_done results in unblocking of finish_item().
