Jump to content

Philipp A Hartmann

Members
  • Content Count

    485
  • Joined

  • Last visited

  • Days Won

    117

Philipp A Hartmann last won the day on March 11

Philipp A Hartmann had the most liked content!

About Philipp A Hartmann

  • Rank
    Advanced Member

Profile Information

  • Gender
    Not Telling
  • Location
    Duisburg, DE

Recent Profile Visitors

2,066 profile views
  1. Philipp A Hartmann

    Build error SystemC 2.3.3 with C++17

    The INSTALL notes currently say the following about the SC_CPLUSPLUS preprocessor switch (emphasis mine): This means, that you can explicitly opt-out of some SystemC features, that would generally be supported by your compiler's C++ language support. Selecting a newer C++ standard version than supported by your compiler (setup) will typically not work - as you have experienced. That said, adding a preprocessor flag on the compiler command-line does not affect the language mode of the compiler. How to switch your compiler to C++17 mode is outside of the scope of SystemC. Your compiler (version) seems to require the -std=c++17 switch to enable this mode. The SC_CPLUSPLUS flag is then not needed as it will be set automatically to the selected version. Hope that helps, Philipp
  2. Philipp A Hartmann

    runtime error :- Fatal: (F4) assertion failed: iface != 0

    The issue is likely caused because you access a port (via -> or for example calling functions like .read()) already inside the module constructor. You should only access ports after binding has completed, this means from within a SystemC process or in end_of_elaboration() / start_of_simulation() callbacks. Hope that helps, Philipp
  3. From my understanding, the "before_end_of_elaboration" limitation got fixed in SystemC 2.3.1 (and a regression introduced by this was fixed in 2.3.2/2.3.3). /Philipp
  4. Yes, TLM sockets are dependent on SystemC and can only be used inside of a SystemC module. This is because they are implemented via SystemC ports/exports, which can itself only be instantiated in SystemC modules as per the SystemC standard. If you want to bridge into a pure C++ model, you can pass the corresponding interface pointers into your C++ model via your own code (via get_interface() after elaboration). This way, you only depend on sc_interface from SystemC (which is a base class of all SystemC/TLM interface classes) inside your C++ model. I'm not sure, what you are trying to achieve, though. Why can't you use SystemC (which is just C++ at the end anyway)? Greetings from Duisburg, Philipp
  5. Philipp A Hartmann

    how can i know which event triggered a process?

    SystemC 2.3.2 (and later) does support a query whether an event was triggered in the previous delta cycle (or immediately in the current evaluation cycle). This is similar to the sc_signal<>::event() function. With this, you can ask every element in your array, whether it was triggered and may have caused a wakeup of the process. Of course, multiple events can have triggered simultaneously and will only cause a single wakeup of the process. for( const auto ev& : e ) { if ( ev.triggered() ) { // ... } } Hope that helps, Philipp
  6. Philipp A Hartmann

    Killing a process with an included sc_event_[and|or]_list

    Thanks! I can reproduce the behavior and verified that removing the dynamic sensitivity in sc_thread_process::kill_process fixes the issue: void sc_thread_process::kill_process(sc_descendant_inclusion_info descendants ) { // ... if ( sc_is_running() && m_has_stack ) { m_throw_status = THROW_KILL; m_wait_cycle_n = 0; remove_dynamic_events(); // <-- add this line to avoid the exception simcontext()->preempt_with(this); } // ... } I'm not sure, if it is necessary to do the same for the static sensitivity. At least I haven't come up with a similar scenario, where the error is actually "incorrect".
  7. Philipp A Hartmann

    Killing a process with an included sc_event_[and|or]_list

    I did write the above comment and the case where a (e.g. temporary) list lives inside a thread is certainly one of the reasons why we need a check for premature destruction. Due to the nature how event lists are internally handled, we will run into a memory corruption if list is destroyed while a process is still waiting for it. What was not considered is the explicit kill() of a process that is current waiting on such a list. The easiest fix would be to cancel (dynamic) sensitivity before doing the stack unwinding when killing the process. @Stephan Gerth: Can you submit a pull-request with your example above as testcase against the SystemC regressions repository?
  8. Philipp A Hartmann

    wait() is not allowed inside run_phase

    If you use SC_JOIN or your SC_JOIN_ANY, you want to keep the run_phase active until all (or at least one) of the threads terminate(s). Why can't you raise an objection here? You will drop the objection after the join, so the phase can successfully complete. (Without joining, it's fine not to raise an objection).
  9. Philipp A Hartmann

    wait() is not allowed inside run_phase

    The error looks strange to me, as terminated_events is not destroyed before exiting run_phase, i.e. after the wait() has returned. However, I don't know how the objections are implemented in UVM SystemC and whether or how wait() is supported without raising an objection. Can you check with a debugger, if an exception is thrown while your run_phase function is inside the wait()? Hope that helps, Philipp
  10. Philipp A Hartmann

    wait() is not allowed inside run_phase

    Can you show the output of your simulation? And maybe add sc_get_current_process_handle().name() to the log statements to include the process name in the output. I would expect to at last see the output after the wait() in fun2. Secondly, you should check for (*it).terminated() and only kill() running processes in the termination loop.
  11. Philipp A Hartmann

    simple socket

    For this, you can use a custom creator, e.g. a lambda function in C++11. For a tagged socket, you anyway need to specify the tag in the for the callbacks, so doing the registration in the creator saves you another loop in your code: sc_core::sc_vector< tlm_utils::simple_initiator_socket_tagged<Router > > initiator_socket; ... /// Router::Router():initiator_socket("initiator_socket",4, [this](const char* /*unused*/, size_t idx) { std::stringstream ss; ss << "initiator_" << idx << "_socket"; auto * socket = new tlm_utils::simple_initiator_socket_tagged<Router >( ss.str().c_str() ); //socket->register_invalidate_direct_mem_ptr( ..., idx ); return socket; }) {} Hope that helps, Philipp
  12. Philipp A Hartmann

    SystemC 2.3.3 fail "make check" in MacOS

    Hi Mike, SystemC 2.3.3 does not use sem_init when C++11 is available. So this error should only happen if you use both a recent Mac OS X without using C++11 support. And you should actually see a failing assert in this case (unless you happen to build with NDEBUG defined, which is generally a bad idea). Greetings from Duisburg, Philipp
  13. Philipp A Hartmann

    Process sensitivity with sc_vector

    Why do you want to do this?
  14. Philipp A Hartmann

    Why sc_signal<T>::trace() is deprecated ?

    Hi Roman, This would be something to discuss in the Accellera SystemC LWG (or the IEEE P1666 WG). In practice, most/all commercial simulators provide much more advanced tracing mechanisms already, beyond what the current sc_trace() API allows to support. My guess would be, that this part of the standard is something where it is difficult to reach consensus, as it touches the core distinguishing features of commercial SystemC offerings. Moreover, the sc_trace()-based API is a costly "pull" interface, which effectively loops over all variables at each time step and does a value comparison. This is also pretty inefficient for e.g. signals, which already "know" if they changed. So I think, a plain sc_interface::trace() addition is not sufficient to bring real additional value here. Last, but not least, this function would have to have a default (empty) implementation to not break existing models and would require some extension mechanism to add support for custom types. Greetings from Duisburg, Philipp
  15. Philipp A Hartmann

    What is SystemC library special in?

    SystemC supports pkg-config as well and generates a corresponding systemc.pc file. Of course, you still need to have the systemc.pc file somewhere in your PKG_CONFIG_PATH. For manual Makefiles, you can check the templates in examples/build-unix as a starting point. Greetings from Duisburg, Philipp
×