What is the main purpose of get_response(rsp) method in master sequences

UVM
1

What is the main purpose of get_response(rsp) method in master sequences ?

When we need to use it?

2

In reply to pkoti0583:

get_response() is a blocking call in the sequence which will be unblocked by the driver by using the put_response() method.

So in your sequence, if you want to get the response of a transaction before sending a second transaction to the driver then you use the get_response() method after sending the first transaction so that it will be blocked till the master get the response from the slave and sends it back to the sequence through the “put_response()” call.

Hope this helps.

3

In reply to Sundar Raman A:

Hi pkoti0583,

One of the scenario where we can use it the rsp.

Let’s say in the case of I2C Slave device, If we are driving stimulus from our Master Driver, We can wait for the ACK/NACK From slave Device.

After Driving address, One can wait and drive data if and only if we have rsp as ‘0’(Ack). If response has been received as ‘1’ from I2C Master Driver,stop bit can be driven in the next transfer.

Let me correct if I am having different understanding.

4

In reply to Geet:

Finally this does not really meet the intention of get_response.
get_response() has to be executed in a sequence when you are putting back from your driver a response using put(rsp) or item_done(rsp). Before you are doing this you have to copy the id_info of a sequence item from the req to the rsp. This is necessary when you want to evaluate your rsp in the sequence.

5

In reply to Geet:

Please look into the code examples from the Verification Academy, especially for bidirectional sequencer/driver protocol
https://verificationacademy.com/cookbook/cookbook-code-examples#UVM_Examples:#UVM_Examples:#UVM_Examples:

6

In reply to chr_sue:

Thanks for a update.

I had gone through the cookbook link in which APB error response and read data has been takes as rsp field send back to sequence as follow :
rsp.error = BUS.error;
rsp.read_data = BUS.read_data;

Driver/Sequence API | Verification Academy (Same one which you pointed)

Please point that what kind of action sequence will take based on rsp field by driver.

In current sequence code it’s calling get_response(rsp) and driving the next transaction, then what is the use of rsp.error and rsp.read_data ?

I am looking for a use case in which this rsp field may be useful and based on the received rsp, next transaction will be decided.

7

In reply to Geet:

I was pointing you to the code examples. See the examples with bidirectional interface between driver and sequencer.

8

In reply to chr_sue:

Thanks, I have gone through the code and also ran it. My query is about taking decesion based on received response.

Please find below lines of code from given example:

From Driver Code
…
if(rsp.read_not_write == 1) begin
rsp.read_data = BUS.read_data; // If read - copy returned read data
end
rsp.error = BUS.error; // Copy bus error status
BUS.valid <= 0; // End the pin level bus transaction
seq_item_port.put(rsp); // put returns the response

From Sequence code:
…
start_item(req);
// The address is constrained to be within the address of the GPIO function
// within the DUT, The result will be a request item for a read or a write
assert(req.randomize() with {addr inside {[32’h0100_0000:32’h0100_001C]};});
finish_item(req);
get_response(rsp);

Simulation Messages:

UVM_INFO top.sv(209) @ 2870: uvm_test_top.m_sequencer@@test_seq [seq_body]

addr: 1000014

write_data: 5fe70b99

read_not_write: 1

delay: 8

**error: 0

read_data: 0**

UVM_INFO top.sv(209) @ 2990: uvm_test_top.m_sequencer@@test_seq [seq_body]

addr: 1000018

write_data: a7ecbab6

read_not_write: 1

delay: 1

**error: 0

read_data: 38f93ae6**

Here we have received read_data & error as a response from Driver in to a sequence. My point of query is about taking decision based on received response for driving next transaction.

Can sequence can be coded to wait for few clock cycle if rsp in error field is ‘1’ ?

  start_item(req);
  assert(req.randomize() with {addr inside {[32'h0100_0000:32'h0100_001C]};});
  finish_item(req);
  get_response(rsp);
  if(rsp.error==1)
    wait for few clock cycle()
  ...
9

In reply to Geet:

Sequender and sequence do not know anything about clock cycles. But you can implement such behavior in the driver. The question is why do you want to wait?
But depending on your rsp data you can make decisions in generating the next seq_item.

10

In reply to chr_sue:

Thanks for update. It was just a hypothetical example (Waiting in Sequence ).

I am just seeking an application in which we can make decisions in generating the next seq_item.

I already understood the concept but looking for an one practice application.

11

In reply to Geet:
Hello ,
So here one of confusion is :
getting response means we are getting from the dut → driver-> sequence(output signals data etc) so then whats the difference between monitor and get_response,thanks

12

In reply to ramankaur09:

Hi Ramankaur,

One of the use case:

When you want a data back to sequence as read data, You can use get_responce method.
For an example:

From sequence:

`uvm_do( tx.type = READ_transection);
get_responce(tx);  // This will return entire transaction from driver

With this, your driver will do pin level activity for read transection. In case you want the read data back to sequence, you need to use item_done(transection_type) argument.

From driver:

forever begin
  seq_item_port.get_next_item(req);
  rsp - new();
  rsp.set_id_info(req);
   ... do the operation ...
  seq_item_port.item_done(rsp); 
end

With this your sequence can be self check wo send write and read back data comparison.

However, Monitor do not have significant role here. Rather, It’s stand alone/independent component who always checks the interface and sample and check the protocol layer stuff.

13

In reply to Geet:

it’s no difference for working as a driver. even if you use req instead rsp.

forever begin
  seq_item_port.get_next_item(req);
   ... do the operation ...
  seq_item_port.item_done(req); 
end