Jump to content

Guillaume Audeon

  • Posts

  • Joined

  • Last visited

Profile Information

  • Gender
    Not Telling
  • Location
    Cambridge, UK

Recent Profile Visitors

265 profile views

Guillaume Audeon's Achievements


Member (1/2)



  1. Hello @maehne, you are welcome. I observed the segmentation fault on CentOS with the official release of 2.3.2.
  2. Hello, I recently stumbled across the same issue, but in a different manner: I configure, build and install SystemC on RHEL7, then execute on CentOS7. Before applying the above fix, I encountered the same sc_assert() failure; after applying the fix, I got a Segmentation fault. I have found that I can fix this by using mmap()/munmap() to allocate/deallocate memory for the Quick Thread stack. See attached a possible patch for this. Kind regards, Guillaume sc_cor_qt.patch
  3. 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
  4. 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
  5. 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
  • Create New...