Jump to content
ankitks

how can peq_cb have access to my socket's port_id

Recommended Posts

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

 

 

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...