Guillaume Audeon Posted October 26, 2018 Report Share Posted October 26, 2018 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 Quote Link to comment Share on other sites More sharing options...
maehne Posted October 28, 2018 Report Share Posted October 28, 2018 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 Quote Link to comment Share on other sites More sharing options...
Philipp A Hartmann Posted October 28, 2018 Report Share Posted October 28, 2018 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 maehne 1 Quote Link to comment Share on other sites More sharing options...
Guillaume Audeon Posted October 29, 2018 Author Report Share Posted October 29, 2018 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 Quote Link to comment Share on other sites More sharing options...
Guillaume Audeon Posted October 29, 2018 Author Report Share Posted October 29, 2018 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 Quote Link to comment Share on other sites More sharing options...
maehne Posted October 29, 2018 Report Share Posted October 29, 2018 Thanks for the clarification and feedback on the fix suggested by Philipp! Quote Link to comment Share on other sites More sharing options...
Philipp A Hartmann Posted October 30, 2018 Report Share Posted October 30, 2018 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 Quote Link to comment Share on other sites More sharing options...
Guillaume Audeon Posted November 1, 2018 Author Report Share Posted November 1, 2018 Indeed. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.