Using TLM2 but not generic payload

[samng]

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
 

[Philipp A Hartmann]

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

[samng]

Thank you, Philipp.

 

Can simple_initiator/target_socket work with non-GP payload?

[Philipp A Hartmann]

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)?

[sumit_tuwien]

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

[c4brian]

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

[Philipp A Hartmann]

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

[c4brian]

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

[zubin2911]

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

[c4brian]

Perhaps you forgot to include the class in your file

 

#include "tlm_utils/passthrough_target_socket.h"

[zubin2911]

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

[c4brian]

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)
  {
    // ...
  }

[zubin2911]

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

[c4brian]

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.

[zubin2911]

Ok thanks. that sounds good to me now.

[zubin2911]

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