how can peq_cb have access to my socket's port_id

[ankitks]

I have array of target sockets.

sc_vector<target_socket_type>    m_target_socket;

which are bind to tagged nonblocking forward function and here is declaration of the function

sync_enum_type my_forward_function(int port_id,...) {

m_peq.notify(trans, phase, t);

return tlm::TLM_ACCEPTED;

}

registered callback for peq is peq_cb. Is there a way for my callback to to know port_id? I need to send END_REQ back on same port's backward path, but I need to know id.

Thanks

 

 

[ankitks]

Any help folks?

[Philipp A Hartmann]

You can have a look at the "nb2b_adapter" test in the SystemC regression test suite, located at tests/tlm/nb2b_adapter/nb2b_adapter.cpp.

In this example, you find the usage of an instance-specific extension for exactly that purpose:

  struct route_extension: tlm_utils::instance_specific_extension<route_extension>
  {
    int id;
  };
    
 // ...
    
   virtual tlm::tlm_sync_enum nb_transport_fw( int id, tlm::tlm_generic_payload& trans,
                                              tlm::tlm_phase& phase, sc_time& delay )
  {
    route_extension* ext = 0;
    if (phase == tlm::BEGIN_REQ)
    {
      ext = new route_extension;
      ext->id = id;                        // <-- store ID in the extension
      accessor(trans).set_extension(ext);
    }

// ...
    
    virtual tlm::tlm_sync_enum nb_transport_bw( int id, tlm::tlm_generic_payload& trans,
                                              tlm::tlm_phase& phase, sc_time& delay )
  {
    route_extension* ext = 0;
    accessor(trans).get_extension(ext);
    sc_assert(ext);

    tlm::tlm_sync_enum status;
    status = targ_socket[ ext->id ]->nb_transport_bw( trans, phase, delay ); // use ID from the extension

Hope that helps,
  Philipp

[ankitks]

Thanks Philipp. Got it to work!

[ankitks]

So for my understanding, there are two type of extension.

1. TLM extension: This will be only one type of extension, and extension will be static in the sense that it will be there till we delete the payload.

2. Instance specific extensions: There can be many time of extension, and we are allowed to attach and detach them as we like.

Correct?

[Philipp A Hartmann]

The instance specific extension is tied to a specific accessor object (usually a member in a module, e.g. an interconnect).  So each accessor can have its own extension object and is responsible for cleaning it up later.

For regular TLM extensions, yes, there can only be one extension object of each type in a transaction payload.