Jump to content

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

 

Share this post


Link to post
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

Share this post


Link to post
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

Share this post


Link to post
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

Share this post


Link to post
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

Share this post


Link to post
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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×