Jump to content


  • Posts

  • Joined

  • Last visited

Recent Profile Visitors

532 profile views

Hadrian2002's Achievements


Member (1/2)



  1. Hi, I just tried to use clang under windows to compile some SystemC projects and I experienced a pointer corruption of the instance pointer for the execution of a sc_thread. After some debugging I discovered, that the "hack" for older VS++ compilers referring to the macro "SC_USE_MEMBER_FUNC_PTR" (see https://github.com/accellera-official/systemc/blob/604182509559ae42c34e878f508bae7c18abbbd6/src/sysc/kernel/sc_process.h#L120) will create working simulation binaries with clang (i.e. actually not defining the macro is doing the trick). I actually also realized, that clang under Windows is not officially supported, which explains that it have not arisen yet. Nonetheless, adding here an additional compiler detection macro would be easy and would add (although quite untested) clang support for windows. I tried my fix for clang 10 and clang 12. I got the impression, that clang sometime in the past adapted to the "bad" msvc behavior and did not change it, although msvc got standard compliant. The fix for this problem would be quite easy: #if defined(_MSC_VER) && !defined(__clang__) #if ( _MSC_VER > 1200 ) # define SC_USE_MEMBER_FUNC_PTR #endif #elif defined(_WIN32) && defined(__clang__) //do not define SC_USE_MEMBER_FUNC_PTR #else # define SC_USE_MEMBER_FUNC_PTR #endif Additionally, I would propose to throw a warning in the CMakeLists, if using an unsupported compiler. Do you like to get PullRequest on github?
  2. mhh okay I think the problem is not pedantic, but -Wextra ... actually I use this compile options " -Wall -Wextra -pedantic", which creates warnings in clang
  3. Hi, I have 2 suggestions for the current SystemC reference implementation. I started to use pandantic compiling option for my project and this throws many warnings in SystemC headers. Altough it's annoying but there many simple fixes for unused variables. For base classes where you don't use the proposed parameter like here (one random example) ../systemc-lib/src/tlm_core/tlm_2/tlm_generic_payload/tlm_gp.h:349:57: warning: unused parameter 'ext' [-Wunused-parameter] template <typename T> void clear_extension(const T* ext) you can simply switch to this one template <typename T> void clear_extension(const T* /*ext*/) If you want I can do a pushRequest for this on github. But maybe you are not interested in this, than you could at least make it easy for users of CMake to not print them, if they compile their code. The simplest approach for this is to change the CMakelists.txt in src from ... target_include_directories(systemc PUBLIC $<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}> $<INSTALL_INTERFACE:${CMAKE_INSTALL_INCLUDEDIR}>) .... to target_include_directories(systemc PRIVATE $<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}> $<INSTALL_INTERFACE:${CMAKE_INSTALL_INCLUDEDIR}> PUBLIC INTERFACE $<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}> $<INSTALL_INTERFACE:${CMAKE_INSTALL_INCLUDEDIR}>) kind regards
  4. For everybody interested in my actual solution: I used the "translation filter file" feature of gtkwave. Therefore I created a class traceString, which is created with a standard string, and assigns an ID to every new created instance. I also create while construction a translation with all IDs and the corresponding strings is created and after the simulation you open the VCD in gtkwave and apply the filter file. The you can simply trace the integer ID.
  5. As I said, after elaboration (or before_end_of_elaboration) the actual number of different strings and the number of bytes of the longest string is determinable, so I could try to wrap it around sc_bv. Since I know my target will be gtkwave I could use the string extension for vcd of gtkwave. I firstly will patch the current implementation for vcd_trace_enum, but my original questions were about the class hierarchy of the reference implementation.
  6. Hi, I try to implement sc_trace for an std::string. In the end, I would like to view this string with e.g. gtkwave in the data format ASCII. From digging through the standard SystemC implementation, I found the vcd_T_trace class would already serve my needs, or at least I could use it as template since std::string do not have a to_string() member. But from here I'm a bit confused, which else function I need to implement to have a standard conform sc_trace Implementation. Of course I need the sc_trace(sc_trace_file *tf, std::string &obj, std::string &name), but I think I cannot call traceT from a free sc_trace, so I also need to inherit my own vcd_trace_file type. Am I right and exist there better ways to save strings in a VCD ? The number of different strings is constant after elaboration, so the string literal trace would be enough, but the current implementation does not save the string literal to the VCD, so it's useless here. Thanks it advance!
  7. I tried exactly this, but as the IEEE Standard §5.14.3 says, it should not be derived from sc_object. For the convenience sockets simple_*_socket, this is also the case. I think I need to modify the binding operation to save the name of the binded Object.
  8. As far as my researches shows, only the Interfaces to the sockets are bound and they not include references to the bounded object. Of course this is the intended behavior. Regarding an interface (derived from sc_interface) should not derive from sc_object, so also no chance to do bad casting stuff. I tried this with simple_target_socket.get_base_port()->get_interface(0) and so on. Seems to be that I need an additional TLM-Extension carrying the name of Initiator. I think I could also implement a target-socket, which saves the name, when the socket is bound, but then I forbid to bound against exports and so on ... Really annoying is, that with a Debugger I could extract the, but there is no API for that. Any other suggestions ?
  9. Hello, I have a question regarding the reflection possibilities of SystemC in combination with TLM-Sockets. For logging I want to know the name of a simple-initiator-socket, which is bound to a given simple-target-socket. The Idea is, to log something like " 'CPU_1_initiator_socket' starts request to 'Bus_Port_4_target_socket' ", but this message needs to be created at the submodule, which only knows the target-socket. I know, since the sockets are sc_objects, they will get a unique name, but is also saved the binding relation to the socket?
  10. It is possible to pass a sc_event_list to the sc_spawn method, so this dynamic process ( dynamic in sense of creation while simulation and not in elaboration like normal processes) have the same static sensitivity
  11. Hi, my goal is somehow to create a scheduler for SC_METHODS, which needs only a few changes to a functional model. I'm spawning for every SC_METHOD a process, which waits on the same inputs, and mark this process as ready for execution. If the scheduler decides to schedule a specific SC_METHOD, the METHOD is resumed and after that suspended. My first attempt will use small modifications to the functional model, but I tried to remove that. kind regards
  12. Hi, i'm trying to analyse automatically a sc_module and generate for every registered process a dynamic process, which have the same static sensibility as the corresponding static process. I have managed to extract all process handles of a module, but I find no proper solution to copy the sensitive variable, or extract the triggering events of a process. My goal is, that the sc_module will not to be changed for this, if it is possible. I need it especially for SC_METHODs and SC_THREADs thanks in advance
  • Create New...