Jump to content

Philipp A Hartmann

  • Posts

  • Joined

  • Last visited

  • Days Won


Posts posted by Philipp A Hartmann

  1. Hi Roman,

    I can give some background here, as I'm guilty of the current implementation.

    The kernel also needs to handle exceptions that are escaping SystemC thread processes.  These are originally thrown in a different stack and still need to be propagated to sc_main, i.e. the main thread in order to be able to still catch the exceptions there in user code.  The propagation across stacks has to be done by catching in one stack and rethrowing in another.

    That said, exception handling not only covers sc_report, but also arbitrary exception types escaping sc_main or a SystemC thread.  We don't want to cause std::terminate to be called in case of uncaught exceptions, but want to properly propagate, catch and wind down the simulation.  Therefore, all exceptions are translated to standard sc_report objects before cross-stack propagation and are finally handled outside of sc_main.

    For consistency, the translation to sc_report is done for both, thread and method processes: It's an error, if an exception escapes a SystemC process and errors are reported as sc_report (and routed through the report handler) in SystemC.  Users can catch the original exceptions themselves by adding catch blocks to sc_main and their SystemC processes.

    Hope that helps,

  2. Hi Ameya,

    thanks for testing.  As said before, unfortunately I cannot reproduce this on my end.  I would need more details on the current behavior:

    • The backtrace looks like there is something broken during model teardown. Have you seen other cases?
    • Are all simulations with processes hanging in a similar way? (e.g. can you provide a full regression result?)

    Greetings from Duisburg,

  3. Hi Ameya,

    I currently don't have access to such new Linux platforms, but I may have a suspicion about a potential root cause.
    Can you please check, if it helps to change the sc_process_b::delete_process function in src/sysc/kernel/sc_process.cpp  as follows:

     // if ( this != sc_get_current_process_b() )
     if ( NULL == sc_get_current_process_b() )

    Thanks and Greetings from Duisburg,

  4. This example still uses the positional binding feature of SystemC, which is deprecated as per IEEE Std. 1666 (see Annex C (h), emphasis mine):


    This annex contains a list of deprecated features. A deprecated feature is a feature that was present in version 2.0.1 of the OSCI open source proof-of-concept SystemC implementation but is not part of this standard. Deprecated features may or may not remain in the Accellera Systems Initiative implementation in
    the future. The user is strongly discouraged from using deprecated features because an implementation is not obliged to support such features. An implementation may issue a warning on the first occurrence of each deprecated feature but is not obliged to do so.


    h) operator, and operator<< of class sc_module for positional port binding (use operator() instead)


  5. The full data length is independent of the word length. The rules for DATAWORD are defined by the standard as follows (see 14.20.3):


    e) The template argument to a hostendian function should be a type representing the internal initiator data word for the endianness conversion. The expression sizeof(DATAWORD) is used to determine the width of the data word in bytes, and the assignment operator of type DATAWORD is used during copying. sizeof(DATAWORD) shall be a power of 2.

    From your example below, you seem to be using four byte word, so "unsigned" (or uint32_t) could be a used as a DATAWORD parameter.

  6. Hi Khushi,

    the best is to look up the definition in the IEEE 1666-2011 standard, section 14.20(.3).

    The different conversion functions have different constraints associated with them, allowing for more performant implementations for the _word, _aligned, and _single specializations.  The _generic one covers arbitrary cases.  The DATAWORD template parameter allows for optimizations as well (and endianness is always specific to the notion of a word).

    Hope that helps,

  7. Hi Ivan,

    instead of referring to the very old 2.01. LRM, I suggest to check the IEEE Std. 1666-2011 for SystemC, which could can download at no cost (sponsored by Accellera) via https://standards.ieee.org/findstds/standard/1666-2011.html.  This document includes the normative answers to all of your questions.


    10 hours ago, Ivan said:

    Question 1: if I swapped two statements evt1.notify(0, SC_NS) and evt1.notify() here, will the delta notification will be removed? In my opinion only evt1.nofity() will be remembered:

    Yes, see section 5.10.8 of the aforementioned standard.


    10 hours ago, Ivan said:

     Question 2: Since I we have wait(10, SC_NS), does that mean that the process p3 will be put in separate list/queue of sleep processes? Let's call it list S, so we would have S = {p1} effectively? 

    Kind of, yes.  This is called "time out", see section 4.2(.1) of the standard.


    10 hours ago, Ivan said:

    Question 3: How come that order of thread registration actually affects the order of the process being scheduled?

    The order to execution of processes in the runnable queue is entirely implementation-defined. See section

    Hope that helps,

    Disclaimer: I haven't checked all of your post for correctness and focused on the questions instead.



  8. Hi Sumit,

    I re-checked the LLVM issue and it now refers to C++ CWG issue #7 (http://www.open-std.org/Jtc1/sc22/wg21/docs/cwg_closed.html#7), which clearly describes our situation here and shows that the current implementation of tlm_req_rsp_channel<...> is invalid C++ in SystemC (even though only Clang rejects it so far).

    Without changing the inheritance pattern, the only fix would be to add "friend" declarations to all (indirect) virtual base classes of tlm_put_get_impl<...>, including sc_interface.  This is not an option, so I think the internal implementation of the tlm_req_rsp_channel<...> needs to be refactored to avoid the private virtual inheritance.  I have opened an issue in the SystemC Language WG bug tracker for this.

    Greetings from Duisburg,

  9. 1 hour ago, katang said:

    And, not testing if at least the "Hello World" can be built with, as given by the example setup test?

    SystemC 2.3.2 has been tested successfully with C++03, C++11, C++14 (and even C++17) with various compilers.

    As mentioned in this thread, the selected C++ standard needs to match between the library build and the application build.  This is enforced by the linker error you see. If you continue to run into these errors, make sure to build the SystemC library with the matching C++ standard selection compared to your application (see INSTALL or cmake/INSTALL_USING_CMAKE how to do that).

  10. 20 hours ago, katang said:

    BTW: If that version works with standard 11 only, why is it not preconfigured?

    SystemC 2.3.2 works fine with C++03, you just need to configure the C++ standard consistently between your application and the library build.

    In the (experimental) SystemC Cmake build setup, the selection always defaults to C++03, regardless of the default of the compiler.  In your application build, you might not explicitly set the C++ standard on the command-line, giving you a different default version from your compiler.  The behavior of the SystemC CMake setup could be improved here.

    Greetings from Duisburg,

  11. For your particular use case, you can just pass in the clock signal directly:

      SC_CTHREAD(test_cthread, clkgen); // posedge by default for CTHREADs

    If you need a negedge triggered process, you can also write the equivalent SC_THREAD instead:

        sensitive << clkgen.negedge_event();

    Allowing plain events for CTHREAD sensitivity was probably just never needed. 

  12. Hi all,

    16 hours ago, Eyck said:
    x sc_core::sc_get_current_process_b()->get_parent()->name()

    Both sc_get_current_process_b() and get_parent() are non-standard functions that may or may not be supported by (future) versions of your SystemC implementation.
    I recommend to only use standard IEEE 1666-2011 APIs instead:

    x sc_core::sc_get_current_process_handle().get_parent_object()->name()
    x sc_core::sc_get_current_process_handle().name()

    Greetings from Duisburg,

  13. Hi Sumit,

    can you please share some details on your remark that "it does not compile with -std=c++17"?  For me, the SystemC 2.3.2 library and examples compile and run fine with GCC 6.3 and -std=c++17 (no 6.2 installation at hand here).

    Your linker errors look like you're missing the (matching) C++ runtime libraries in your linker call.  Do you configure clang to use libc++ instead of libstdc++?  Can you link any other C++ library built with GCC 6.2 to an application built with Clang 7?  I would expect that this issue is not specific to SystemC and I would recommend to stick to a single compiler for all artifacts in your application, including SystemC.

    Hope that helps,

  • Create New...