Hi ,
[X] Depending on whether there is a response for the Request driven on interface we have Unidirectional and Bidirectional protocols .
[Y] During specialization of REQ and RSP type parameters of sequence , sequencer and driver , the user has 2 options ::
(a) REQ and RSP are same . In this case response fields are part of Request item i.e REQ type for bidirectional protocols .
// After assigning the response fields of the Request item fetched by driver .
seq_item_port.item_done( req ); // Used with seq_item_port.get_next_item( req ) ;
[ OR ]
seq_item_port.put( req ); // Used with seq_item_port.get( req ) ;
So when driver sends response back it would simply assign the response fields on observing a response on the bus for the request previously driven on interface .
(b) REQ and RSP are different . In this case , driver creates response item ' rsp ' , assigns it's fields and then calls ::
seq_item_port.item_done( rsp ); // Used with seq_item_port.get_next_item( req ) ;
[ OR ]
seq_item_port.put( rsp ); // Used with seq_item_port.get( req ) ;
Within UVM class uvm_reg_map tasks ’ do_bus_write ’ and ’ do_bus_read ’ we have the following code ::
......................................
adapter.m_set_item(rw);
bus_req = adapter.reg2bus(rw_access);
adapter.m_set_item(null);
if (bus_req == null)
`uvm_fatal("RegMem",{"adapter [",adapter.get_name(),"] didnt return a bus transaction"});
bus_req.set_sequencer(sequencer);
rw.parent.start_item(bus_req,rw.prior);
if (rw.parent != null && i == 0)
rw.parent.mid_do(rw);
rw.parent.finish_item(bus_req);
bus_req.end_event.wait_on(); // Raised a separate Forum thread to discuss working of this line of code .
if (adapter.provides_responses) begin
uvm_sequence_item bus_rsp;
uvm_access_e op;
// TODO: need to test for right trans type, if not put back in q
rw.parent.get_base_response(bus_rsp); // [ST1]
adapter.bus2reg(bus_rsp,rw_access); // [ST2]
end
else begin
adapter.bus2reg(bus_req,rw_access); // [ST3]
end
..................................................
[1] If bit property ’ provide_responses ’ of the adapter is set ( 1 ) , driver sends responses back ( Refer Y above )
So via [ST1] the response would be fetched above and then calls adapter function ' bus2reg ' **with the response fetched passed as 1st argument .**
**[Q1] Does this place any restriction on the REQ and RSP type parameters i.e should it be same or different type ?**
[2] If bit property ’ provide_responses ’ of the adapter is at default ’ 0 ’ , it means the driver doesn’t send responses back .
However if driver uses seq_item_port.get_next_item( req ) and seq_item_port.item_done( req ) , driver could still update response fields within request item .
( provided REQ and RSP types are same ).
So when **finish_item( req ) unblocks it would contain the updated response fields**
[Q2] Depending on the bus protocol it could be either unidirectional or bidirectional protocol .
[ST1] executes for birectional protocol whereas [ST3] would execute for either case .
( For bidirectional protocol the response fields could be part of REQ item and assigned before calling seq_item_port.item_done( req ) )
**Please correct me if wrong .**
[3] Within function ’ bus2reg ’ variable ’ status ’ of struct ’ uvm_reg_bus_op ’ of ref argument ’ rw ’ is assigned
virtual function void bus2reg(uvm_sequence_item bus_item, ref uvm_reg_bus_op rw);
.....................
rw.status = // Assign UVM_IS_OK / UVM_HAS_OK / UVM_NOT_OK
endfunction: bus2reg
[Q3] Doesn’t this restrict that the bus protocol must always be bidirectional ( i.e response is present ) since there is a result of the transaction ?
What if variable ’ status ’ isn’t assigned ? ( default is UVM_IS_OK for the typedef ) . Would there be any side-effects if not assigned explicitly ?