Jump to content
samng

Using TLM2 but not generic payload

Recommended Posts

This is possible, right?

 

I add a target socket as a member to a SC module but not passing generic payload:

 

tlm_target_socket<my_item> inp_sock;

 

But I get the following error:

 

"model.h", line 34: error: type name is not allowed
    tlm_target_socket<my_item> inp_sock;

 

 

Do I need to derive 'my_item' from some base class?

 

Thanks,

Sam
 

Share this post


Link to post
Share on other sites

Yes, it is possible to use your own payload types.  But you don't pass it at the first template parameter to the socket.  The first parameter is the BUSWIDTH, which is an integer.  Therefore, you get the error about not being allowed to pass a type there.  Instead, you need to define your own "protocol traits" and use this instead of tlm::tlm_base_protocol_types:

struct my_protocol_types
{
  typedef my_item        tlm_payload_type;
  typedef tlm::tlm_phase tlm_phase_type;
};
// ...
tlm::tlm_target_socket<32,my_protocol_types> inp_sock;

Greetings from Oldenburg,
  Philipp

Share this post


Link to post
Share on other sites

Can simple_initiator/target_socket work with non-GP payload?

 

Technically speaking, yes (if you implement some subset, actually used by the convenience sockets).

 

On the other hand, the convenience sockets assume that you actually use the TLM-2.0 base protocol (i.e. the tlm::tlm_base_protocol class) as TYPES parameter.  This implies the generic payload.

 

What do you want to achieve?  Why can't you stick with the generic payload and use extensions (see 14.2 in the standard)?

Share this post


Link to post
Share on other sites

Hi Samng,

 

If you create such interfaces they are actually very useful to create lightweight connection when you are more interested in modularise your design. We have created some interfaces (b_send, b_receive, nb_receive, nb_send etc.) in the same way you want and we use them in to connect simple TLM modules (we call it on-the-go) and we got more modularize design without speed penalty. 

 

Ideally, it will not take more than an hour to write these interfaces.

 

Regards, Sumit

Share this post


Link to post
Share on other sites

Phillip,

 

I am coming from a SV UVM background, using SC models in our environments.  I use, exclusively, custom transactions.  I am thinking about transitioning to using the TLM2.0 generic payload, and simple sockets (as you may remember from another post I wrote).  To a person without a strong background in C, the use of the generic payload seems like a major headache. 

Upon receiving the transaction, I've got to extract data pointers, streaming widths, data length, byte enable, dmi_enabled, etc.  Every method associated with each member of the payload has about 15 rules.

 

With the custom transaction, I simply use the custom data members.  Even if I want to use the generic payload, it's only commands are write/read.  It doesn't indicate register/memory.  Now I've got to add an extension, override a couple copy functions.. Extract them in the target.  All the examples I've found (except for Doulus) are unbearable to read.

 

A simple blocking transport with a custom transaction class seems x10 easier.  I'm sure there is some value there, but I'm having trouble seeing it.  The language of TLM2.0 seems very bloated.

 

This is the 2nd time I've made a college try at implementing and using sockets/generic payload, only to scoff and remove it all.

 

What's your opinion?

 

Brian

Share this post


Link to post
Share on other sites

You can use b_transport and the convenience sockets with your custom payload class.

 

First, you'll need the "my_protocol_types" traits class earlier in this thread.

Secondly, due to the blocking/non-blocking conversions, the simple sockets depend on some features of the generic payloads internally (e.g. the memory management and extensions).  If you don't want to use this functionality, you can provide dummy implementations for these GP parts.  If you want the B/NB conversion to work, you should implement them properly, e.g. by reuising the relevant parts of the tlm_generic_payload class. 

 

Instead, I would suggest to use the passthrough sockets, that don't perform any protocol conversions, see Section 16.1 in IEEE 1666-2011:

SC_MODULE(my_module)
{
  tlm_utils::passthrough_target_socket<my_module,32,my_protocol_types> socket;
  // ...

  SC_CTOR(my_module)
  {
    socket.register_b_transport(this,&my_module::my_b_transport);
  }

  void my_b_transport(my_item& trans, sc_time& delay)
  {
    // ...
  }
};

In general, TLM-2.0 is about interoperability.  It is meant to cover a wide range of modeling requirements across tool and model providers.  If you don't care about interoperability with third-party models, you're free to ignore many of the rules (and simply return an error for unsupported features, like byte enables, DMI, etc.).

 

But I agree, the API and all details of the TLM-2.0 rules are quite complex and not made for beginners.  Model writers often rely on in-house or vendor-specific convenience layers on top.

 

hth,
  Philipp

Share this post


Link to post
Share on other sites

Your recommendation appears to work thus far.  ;)  Even more surprising was that I was able to implement an SV uvm_tlm_b_initiator_socket in my UVM environment, and talk to the model via UVMconnect.

 

It looks to me like one of the great attributes of having sockets is the initial reason I brought them up; you can register the b_transport to a different function name. 

 

No, I haven't found myself in a position where I need a third party model, and had to interface to it.

 

Thanks

Brian

Share this post


Link to post
Share on other sites

Hi,

 

I tried to implement the code similar to above, but I'm getting following error:

qualified name is not allowed

tlm_utils::passthrough_target_socket<Router, 32, my_protocol_types> t0;

 

I tried using following:

using tlm_utils::passthrough_target_socket<Router,32,my_protocol_types> t0;

 

It says passthrough_target_socket is not a member.

 

Is there any error in my coding style?

 

Thanks

--Zubin

Share this post


Link to post
Share on other sites

Thanks Brian. I forgot to include the header file.

 

Also, could you please tell me how to use my_b_transport method. As I have 4 sockets and I want to have four different b_transport for each.

 

I tried to implement code which Philipp mentioned above.

 

But, that doesn't work.

 

Thanks

Zubin

Share this post


Link to post
Share on other sites

I'm guessing you are building something like the following.  You need to explain what doesn't work; error message, etc?

 

tlm_utils::passthrough_target_socket<my_module,32,my_protocol_types> socket1;

tlm_utils::passthrough_target_socket<my_module,32,my_protocol_types> socket2;

tlm_utils::passthrough_target_socket<my_module,32,my_protocol_types> socket3;

tlm_utils::passthrough_target_socket<my_module,32,my_protocol_types> socket4;

  SC_CTOR(my_module)
  {
    socket1.register_b_transport(this,&my_module::my_b_transport1);

    socket2.register_b_transport(this,&my_module::my_b_transport2);

    socket3.register_b_transport(this,&my_module::my_b_transport3);

    socket4.register_b_transport(this,&my_module::my_b_transport4);
  }

  void my_b_transport1(my_item& trans, sc_time& delay)
  {
    // ...
  }

 

  void my_b_transport2(my_item& trans, sc_time& delay)
  {
    // ...
  }

 

  void my_b_transport3(my_item& trans, sc_time& delay)
  {
    // ...
  }

 

  void my_b_transport4(my_item& trans, sc_time& delay)
  {
    // ...
  }

Share this post


Link to post
Share on other sites

Yes that's exactly what I'm trying to build.

 

Like if I call :

 

p1->b_transport1(trans, delay);

 

this doesn't work.

 

But instead following works:

p1->b_transport(trans, delay);

 

Is this normal operation with b_transport method call.

 

--Zubin

Share this post


Link to post
Share on other sites

the initiator should always call b_transport.  At the target, where you would generally would have the b_transport function, you are registering it with a different name ( a function name you will never actually call ).

 

hierarchically, you connect simply appropriate initiator and target sockets together; the target will then call whatever b_transport is registered to the target socket.

Share this post


Link to post
Share on other sites

Hi,
 
In the above code with passthrough_socket described by Philipp, if I use multi_passthrough_target_socket do I need to take care of any thing in particular?
 
I suppose multi_passthrough_target_socket doesn't support multiple b_trransport method.
 
Thanks,
Zubin

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...