tlm_socket_base_if

[Guillaume Audeon]

Hello,

 

While moving from SystemC 2.3.1 to 2.3.2, we found out that the addition of base interface 'tlm_socket_base_if' introduces new pure virtual functions, which are not all implemented at tlm_base_*_socket level, i.e. get_protocol_types().

This seems to introduce a "non-backward compatible change" wrt SystemC 2.3.1, as well as departing from IEEE-1666 "compliance".

Should not get_protocol_types() be implemented at tlm_socket_base_if level? e.g.:

 sc_core::sc_type_index get_protocol_types() const  {
    return (std::type_index(typeid(tlm_base_protocol_types)));
}

Not ideal as this would not enforce overriding it, but would at least preserve "compliance" with IEEE-1666.

We would appreciate your inputs/thoughts on this.

Kind regards,
Guillaume

 

[maehne]

Dear Guillaume,

thanks for reporting this issue! I have forwarded your report to the Language Working Group for further analysis. From a first look, this is indeed a change in behaviour of the SystemC proof-of-concept implementation from version 2.3.1 to 2.3.2. However, it does not seem to touch the standard IEEE Std 1666-2011, as the latter does not mention member function `get_protocol_types()`.

Regards, Torsten

[Philipp A Hartmann]

Hi Guillaume,

I agree, that the new pure-virtual functions in tlm_base_(initiator/target)_socket are not compliant to IEEE 1666-2011.  However, I'm curious what use case you have to use these classes directly instead of inheriting from tlm_(initiator/target)_socket, where the functions are implemented?

Regarding the implementation on the base socket level, I suggest to add a typedef to the fw/bw interface classes, and use these typedefs in the socket base class then.  Something like:

template <typename TYPES = tlm_base_protocol_types>
class tlm_fw_transport_if
// ...
{
public:
  typedef TYPES protocol_types;
};

// tlm_base_target_socket

  virtual sc_core::sc_type_index get_protocol_types() const
    { return typeid(typename FW_IF::protocol_types); }

Theoretically, these types could mismatch between FW_IF and BW_IF in manual socket implementations.  Therefore, I'd suggest to refer to the FW_IF in the target and BW_IF in the initiator socket.

Greetings from Duisburg,
  Philipp

[Guillaume Audeon]

Hello Torsten,

 

Thank you for your reply.

This change between 2.3.1 and 2.3.2 actually does not comply IEEE Std 1666-2011, as the later does not mention any implementation defined base class for the tlm_base_*_socket_b. Moreover, tlm_base_socket_if introduce pure virtual functions thus breaking the interface of the tlm_base_*_socket(_b) classes.

Kind regards
Guillaume

[Guillaume Audeon]

Hello Philipp,

Thank you for your reply.

I like your suggested implementation of the get_protocol_types() function. That would make it possible to have this implementation in the tlm_base_*_socket_b classes.

My use case is about extending the TLM interfaces, especially the BW_IF with a blocking backward transport call. For all that I need to derive my thus extended sockets from the tlm_base_*_socket classes so as to be able to specify my extended transport interfaces (which is not possible with tlm_*_socket).

Kind regards,
Guillaume

[maehne]

Thanks for the clarification and feedback on the fix suggested by Philipp!

[Philipp A Hartmann]

Hi Guillaume,

17 hours ago, Guillaume Audeon said:

My use case is about extending the TLM interfaces, especially the BW_IF with a blocking backward transport call. For all that I need to derive my thus extended sockets from the tlm_base_*_socket classes so as to be able to specify my extended transport interfaces (which is not possible with tlm_*_socket).

thanks for the background!

For the time being, I guess you need to work around this issue in your custom sockets then by providing your own implementation of this function in SystemC >= 2.3.2.

Greetings from Duisburg,
  Philipp

[Guillaume Audeon]

Indeed.