Simple change to add support for (concurrent) posted reads in Register Layer

[rangervaloy]

A Register Layer read (using the built-in frontdoor) proceeds as follows:

 

  uvm_reg::read -> uvm_reg::XreadX -> uvm_reg::do_read -> uvm_reg_map::do_read -> uvm_reg_map::do_bus_read

 

If a read request (bus_req) is expected to be completed by a completely separate read reponse (bus_rsp), the following code is executed within uvm_reg_map::do_bus_read:

 

      if (adapter.provides_responses) begin

        uvm_sequence_item bus_rsp;

        …

        rw.parent.get_base_response(bus_rsp);

        adapter.bus2reg(bus_rsp,rw_access);

      end

 

The problem is that since transaction_id is not being provided to uvm_sequence_base ::get_base_response:

 

  virtual task get_base_response(output uvm_sequence_item response, input int transaction_id = -1);

   …

    if (response_queue.size() == 0)

      wait (response_queue.size() != 0);

 

    if (transaction_id == -1) begin

      response = response_queue.pop_front();

      return;

    end

 

    forever begin

      queue_size = response_queue.size();

      for (i = 0; i < queue_size; i++) begin

        if (response_queue.get_transaction_id() == transaction_id)

          begin

            $cast(response,response_queue);

            response_queue.delete(i);

            return;

          end

      end

      wait (response_queue.size() != queue_size);

    end

  endtask

 

the next response provided to the sequencer will unblock get_base_response and be provided to ALL reads that have posted their requests and are waiting for a response.  When that happens the first read to unblock will get the transaction (possibly not the correct one), and then the others will get null responses, and incur in Null-access runtime errors.

 

By simply adding the transaction_id as follows:

 

          rw.parent.get_base_response(bus_rsp, bus_req.get_transaction_id());
 

we force get_base_response to return only after the correct response matching the request is received by the sequencer.

 

The change will enable support for bus protocols where reads are posted and their responses may be returned out-of-order; and it should not affect simpler protocols  where the read requests/responses are not interleaved.

 

Without the (simple) change the only solutions are to:

 

  1.  Create a user-defined frontdoor; which adds significant complexity, since not all automated register model generators have to hooks register them automatically

 

  2.  Extend uvm_reg_map, override do_bus_read, and factory replace

 

 

We are using solution #2.

 

Before reporting this to the UVM Mantis I wanted to open the topic for discussion.

 

Regards,

 

Devaloy Muniz