Scribd
Upload
268 views6 pages

UVM Driver and Sequencer Handshaking

The document describes the mechanism for transferring sequence items between a sequencer and driver in UVM. There are four main steps: 1) the sequence item is created, 2) the start_item() method passes it to the driver, 3) the item is randomized/prepared, and 4) finish_item() passes it back and the driver completes the transaction. Late randomization allows items to be randomized just before finish_item(). The driver uses get_next_item() to retrieve items and item_done() to return them.

Uploaded by

Dan Kumar Yadav
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
268 views6 pages

UVM Driver and Sequencer Handshaking

The document describes the mechanism for transferring sequence items between a sequencer and driver in UVM. There are four main steps: 1) the sequence item is created, 2) the start_item() method passes it to the driver, 3) the item is randomized/prepared, and 4) finish_item() passes it back and the driver completes the transaction. Late randomization allows items to be randomized just before finish_item(). The driver uses get_next_item() to retrieve items and item_done() to return them.

Uploaded by

Dan Kumar Yadav
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 6

UVM Driver and Sequencer Handshaking

In UVM, there is a mechanism to be followed when we want to send the transactions


from the sequencer to the Driver in order to provide stimulus to the DUT.
The transfer of request and response sequence items between sequences and their
target driver is facilitated by a TLM communication mechanism implemented in the
sequencer.

Sending a sequence_item to a driver:


To send a sequence_item to a driver there are four steps that need to occur:

Step 1 - Creation
The sequence_item is derived from uvm_object and should be created via the
factory:
Using the factory creation method allows the sequence_item to be overridden with a
sequence_item of a derived type if required.

Step 2 - Ready - start_item()


The start_item() call is made, passing the sequence_item handle as an argument.
This call blocks until the sequencer grants the sequence and the sequence_item
access to the driver.

Step 3 - Set
The sequence_item is prepared for use, usually through randomization, but it may
also be initialised by setting properties directly.

Step 4 - Go - finish_item()
The finish_item() call is made, which blocks until the driver has completed its side of
the transfer protocol for the item. No simulation time should be consumed between
start_item() and finish_item().

Step 5 - Response - get_response()


This step is optional, and is only used if the driver sends a response to indicate to
indicate that it has completed transaction associated with the sequence_item. The
get_response() call blocks until a response item is available from the sequencers
response FIFO.

my_sequence extends uvm_sequence #(my_sequence_item);


my_sequence_item item;
.....
task body();
// Step 1 - Creation
item = my_sequence_item::type_id::create("item");
// Step 2 - Ready - start_item()
start_item(item);
// Step 3 - Set
if(!item.randomize() with {address inside
{[0:32'h4FFF_FFFF]};})
begin
`uvm_error("body", "randomization failure for item")
end
// Step 4 - Go - finish_item()
finish_item(item);
endtask: body
endclass: my_sequence
view rawuvm_sqr_drv_comm_1.sv hosted with ❤ by GitHub

Late Randomization
In the sequence_item flow above, steps 2 and 3 could be done in any order.
However, leaving the randomization of the sequence_item until just before the
finish_item() method call has the potential to allow the sequence_item to be
randomized according to conditions true at the time of generation. This is sometimes
referred to as late randomization.
The alternative approach is to generate the sequence_item before the start_item()
call, in this case the item is generated before it is necessarily clearhow it is going to
be used.
 
In previous generation verification methodologies, such as Specman and the AVM,
generation was done at the beginning of the simulation and a stream of pre-prepared
sequence_items was sent across to the driver. With late randomization,
sequence_items are generated just in time and on demand.

Driver side Operation:


Multiple APIs used by driver code to interact with the sequencer. First go through
these APIs,

get_next_item()
This method blocks until a REQ sequence_item is available in the sequencers
request FIFO and then returns with a pointer to the REQ object.
The get_next_item() call implements half of the driver-sequencer protocol
handshake, and it must be followed by an item_done() call which completes the
handshake. Making another get_next_item() call before issuing an item_done() call
will result in a protocol error and driver-sequencer deadlock.

try_next_item()
This is a non-blocking variant of the get_next_item() method. It will return a null
pointer if there is no REQ sequence_item available in the sequencers request FIFO.
However, if there is a REQ sequence_item available it will complete the first half of
the driver-sequencer handshake and must be followed by an item_done() call to
complete the handshake.

item_done()
The non-blocking item_done() method completes the driver-sequencer handshake
and it should be called after a get_next_item() or a successful try_next_item() call.
If it is passed no argument or a null pointer it will complete the handshake without
placing anything in the sequencer's response FIFO. If it is passed a pointer to a RSP
sequence_item as an argument, then that pointer will be placed in the sequencer's
response FIFO.
The get_next_item() method initiate the sequencer arbitration process, which results
in a sequence_item being returned from the active sequence which has selected.
This means that the driver is effectively pulling sequence_items from the active
sequences as it needs them.

When the handle to a sequence_item is passed as an argument to


the finish_item() method the drivers get_next_item() method call completes with a pointer to the same
sequence_item. When the driver makes any changes to the sequence_item it is really updating the
object inside the sequence. The drivers call to item_done() unblocks the finish_item() call in the
sequence and then the sequence can access the fields in the
sequence_item, including those which the driver may have updated as part of the response side of
the pin level transaction.

// Driver parameterised with the same sequence_item for request & response
// response defaults to request
class my_driver extends uvm_driver #(my_sequence_item);
my_interface vif;
.....
task run_phase(uvm_phase phase);
my_sequence_item req_item;
forever
begin
seq_item_port.get_next_item(req_item); // Blocking call returning the next
transaction
@(posedge vif.clk);
vif.addr = req_item.address; // vif is the drivers Virtual Interface
//
// etc
//
// End of bus cycle
if(req_item.read_or_write == READ)
begin // Assign response data to the req_item fields
req_item.rdata = vif.rdata;
end
req_item.resp = vif.error; // Assign response to the req_item response field
seq_item_port.item_done(); // Signal to the sequence that the driver has finished
with the item
end
endtask: run
endclass: my_driver

// Sequencer parameterised with the same sequence item for request & response
class my_sequencer extends uvm_sequencer #(my_sequence_item);
.....
endclass: my_sequencer

// Agent containing a driver and a sequencer


class my_agent extends uvm_agent;
my_driver m_driver;
my_sequencer m_sequencer;
my_interface vif;
my_agent_cfg m_cfg;
.....
// Sequencer-Driver connection:
function void connect_phase(uvm_phase phase);
if(m_cfg.active == UVM_ACTIVE) // The agent is actively driving stimulus
begin
m_driver.seq_item_port.connect(m_sequencer.seq_item_export); // TLM connection
m_driver.vif = vif; // Virtual interface assignment
end
endfunction: connect_phase
endclass: my_agent
view rawuvm_sqr_drv_comm_2.sv hosted with ❤ by GitHub

The connection between a driver and a sequencer is typically made in the


connect_phase() method of an agent. With the standard UVM driver and sequencer
base classes, the TLM connection between a driver and sequencer is a one to one
connection - multiple drivers are not connected to a sequencer, nor are multiple
sequencers connected to a driver.

uvm_sequence and uvm_driver have predefined sequence_item for both request


and response.
So, you can directly use predefined variables for sequence_item,

virtual class uvm_sequence #(type REQ = uvm_sequence_item,


type RSP = REQ) extends uvm_sequence_base;
.....
REQ req;
RSP rsp;
.....
endclass: uvm_sequence

class uvm_driver #(type REQ=uvm_sequence_item,


type RSP=REQ) extends uvm_component;
.....
REQ req;
RSP rsp;
.....
endclass: uvm_driver

//Sequence, Sequencer and Driver parameterised with the different sequence_item for
request & response
my_sequence extends uvm_sequence #(my_sequence_item1, (my_sequence_item2); // type of req
= my_sequence_item1, type of rsp = my_sequence_item2
.....
task body();
// Step 1 - Creation
req = my_sequence_item1::type_id::create("req"); // type of req = my_sequence_item1
// Step 2 - Ready - start_item()
start_item(req);
// Step 3 - Set
if(!req.randomize() with {address inside {[0:32'h4FFF_FFFF]};})
begin
`uvm_error("body", "randomization failure for req")
end
// Step 4 - Go - finish_item()
finish_item(req);
// Step 5 - Response - get_response()
get_response(rsp); // type of rsp = my_sequence_item2
endtask: body
endclass: my_sequence

class my_driver extends uvm_driver #(my_sequence_item);


my_interface vif;
.....
task run_phase(uvm_phase phase);
forever
begin
seq_item_port.get_next_item(req); // Blocking call returning the next transaction
@(posedge vif.clk);
vif.addr = req.address; // vif is the drivers Virtual Interface
//
// etc
//
// End of bus cycle
if(req.read_or_write == READ)
begin // Assign response data to the req fields
req.rdata = vif.rdata;
end
rsp = my_sequence_item2::type_id::create("rsp"); // type of rsp = my_sequence_item2
req.resp = vif.error; // Assign response to the req_item response field
seq_item_port.item_done(rsp); // Signal to the sequence that the driver has
finished with the item
end
endtask: run
endclass: my_driver

class my_sequencer extends uvm_sequencer #(my_sequence_item1, my_sequence_item2);


.....
endclass: my_sequencer

// Agent containing a driver and a sequencer


class my_agent extends uvm_agent;
my_driver m_driver;
my_sequencer m_sequencer;
my_interface vif;
my_agent_cfg m_cfg;
.....
// Sequencer-Driver connection:
function void connect_phase(uvm_phase phase);
if(m_cfg.active == UVM_ACTIVE) // The agent is actively driving stimulus
begin
m_driver.seq_item_port.connect(m_sequencer.seq_item_export); // TLM connection
m_driver.vif = vif; // Virtual interface assignment
end
endfunction: connect_phase
endclass: my_agent

You might also like