Jump to content

tlm_socket_base_if


Recommended Posts

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

 

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
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...