SC - SV socket connection using uvm_tlm_generic_payload with estensions

UVM
1

Hi Everyone,
I am creating UVM Testbench for a SC model. In this SC-Model one of the slave sockets is using a tlm_generic_payload with extensions.
So, i am trying in the UVM side to define my uvm_tlm_generic_payload & add to it similar extensions like that in SC. so that when i send it using the socket to SC-side, the information inside the extensions could be read & accessed.
I tried the following code in UVM & SC but i also failed to read the extensions correctly in SC:

// Create a simple extension
class my_extension extends uvm_tlm_extension#(my_extension);
int m_add_info;

uvm_object_utils_begin(my_extension) uvm_field_int(m_add_info, UVM_ALL_ON)
`uvm_object_utils_end

function new(string name = “my_extension”);
super.new(name);
endfunction
endclass

//prepare the generic payload to be sent to SC
uvm_tlm_generic_payload gp = new(“gp”);
uvm_tlm_time delay = new();
byte unsigned data;

//intialization
gp.set_data_length(1);
gp.set_write();
data = '{8'hFF};
   
m_my_extension = my_extension::type_id::create("m_my_extension");
m_my_extension.m_add_info = 4;
   
gp.set_extension(m_my_extension);
gp.set_data(data);

// Relay request to TLM receiver
delay.set_abstime(10,1e-9);
my_skt.b_transport(gp, delay);

------------------------SC------------------------
class my_extension : public tlm::tlm_extension<my_extension> {
public:
long m_add_info;

    //virtual functions of tlm::tlm_extension
    virtual tlm_extension_base* clone() const {
      my_extension* ext = new my_extension();
      ext->m_add_info = m_add_info;
      return ext;
    }
    
    virtual void copy_from(tlm_extension_base const & other) {
      const my_extension& ext = dynamic_cast<const my_extension&>(other);
      m_add_info = ext.m_add_info;
    }

};

class my_payload : public tlm::tlm_generic_payload {
public:
my_payload() {
set_extension(new my_extension());
}
~my_payload() {
}

public:
    inline void set_Add_Info(long m_add_info) {
      my_extension* ext = NULL;
      get_extension(ext);
      assert(ext);
      ext->m_add_info = m_add_info;
    }

public:
    inline long get_Add_Info() const {
      my_extension* ext = NULL;
      get_extension(ext);
      assert(ext);
      return ext->m_add_info;
    }

};
Thanks
Hana A.Aziz

2

The issue is that the builtin converter for uvmc on the sc side doesnt pack or unpack the extension objects. This was an oversight, and will be fixed in the next release (soon). A workaround would be to apply the customer converter technique for tlm_generic_payload. Derive a new converter from uvmc_converter <tlm_generic_payload>, implement do_pack/unpack to call into the base do_pack/unpack to take care of all but the extensions, then iterate over all the extensions, calling do_pack/unpack on each. Finanlly, specify your custom converter in the uvmc_tlm::connect call. This procedure is described in the kit documentation (and there are examples in the examples/converters directory).

This workaround is your best bet if you absolutely cannot avoid using TLM GP extensions, the use of which limits interoperability.

As stated in the SystemC LRM:

14.2 Extensions and interoperability

The goal of the generic payload is to enable interoperability between memory-mapped bus models, but all buses are not created equal. Given two transaction-level models that use different protocols and that model those protocols at a detailed level, then just as in a physical system, an adapter or bridge must be inserted between those models to perform protocol conversion and allow them to communicate. On the other hand, many transaction level models produced early in the design flow do not care about the specific details of any particular protocol. For such models it is sufficient to copy a block of data starting at a given address, and for those models the generic payload can be used directly to give excellent interoperability.

The generic payload extension mechanism permits any number of extensions of any type to be defined and added to a transaction object. Each extension represents a new set of attributes, transported along with the transaction object. Extensions can be created, added, written and read by initiators, interconnect components, and targets alike. The extension mechanism itself does not impose any restrictions. Of course, undisciplined use of this extension mechanism would compromise interoperability, so disciplined use is strongly encouraged. But the flexibility is there where you need it!

The use of the extension mechanism represents a trade-off between increased coding convenience when binding sockets, and decreased compile-time type checking. If the undisciplined use of generic payload extensions were allowed, each application would be obliged to detect any incompatibility between extensions by including explicit run-time checks in each interconnect component and target, and there would be no mechanism to enforce the existence of a given extension. The TLM-2.0 standard prescribes specific coding guidelines to avoid these pitfalls.

There are three, and only three, recommended alternatives for the transaction template argument TRANS of the blocking and non-blocking transport interfaces and the template argument TYPES of the combined interfaces:

a) Use the generic payload directly, with ignorable extensions, and obey the rules of the base protocol. Such a model is said to be TLM-2.0 base-protocol-compliant (see 9.1).

b) Define a new protocol traits class containing a typedef for tlm_generic_payload. Such a model is said to be TLM-2.0 custom-protocol-compliant (see 9.1).

c) Define a new protocol traits class and a new transaction type. Such a model may use isolated features of the TLM-2.0 class library but is neither TLM-2.0 base-protocol-compliant nor TLM-2.0 custom-protocol-compliant (see 9.1).

These three alternatives are defined below in order of decreasing interoperability.

It should be emphasized that although deriving a new class from the generic payload is possible, it is not the recommended approach for interoperability

It should also be emphasized that these three options may be mixed in a single system model. In particular, there is value in mixing the first two options, since the extension mechanism has been designed to permit efficient interoperability.
[/quote]

3

In reply to Adam:

Hi Adam

I’m currently hitting this issue. Do you know if it has been fixed for UVMC 2.2? (maybe I’m not using it right)

The examples in release 2.2 don’t have extensions

Thanks!