Jump to content

Philipp A Hartmann

  • Content Count

  • Joined

  • Last visited

  • Days Won


Philipp A Hartmann last won the day on December 11 2018

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

1,962 profile views
  1. 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
  2. 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.
  3. 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
  4. 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
  5. Philipp A Hartmann

    Process sensitivity with sc_vector

    Why do you want to do this?
  6. 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
  7. 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
  8. Philipp A Hartmann

    sc_interface binding incorrectly

    Your consumer process is wrong: void do_reads() { char c; while (true) { if ( in->nb_read(c) ) { // only print valid characters cout << c << flush; } // wait for the next clock wait(); } } Hope that helps, Philipp
  9. Philipp A Hartmann


    Hi Guillaume, 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
  10. Hi Tibor, the stack_protect function is called upon creation and destruction of the thread. Upon creation, a special guard page after the end of the stack is allocated and protected against accesses to catch (some) stack overflows. Upon deletion of the thread, this protection is removed. Quoting https://danwalsh.livejournal.com/6117.html (highlighting mine): Therefore, I agree that we probably don't need to try adding PROT_EXEC to the page's permissions and can only keep the read/write settings: // Revert the red zone to normal memory usage. else { ret = mprotect( redzone, pagesize - 1, PROT_READ|PROT_WRITE); } Can you try with this change again? Thanks and Greetings from Duisburg, Philipp
  11. Philipp A Hartmann


    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
  12. I'm not aware of any executable heap usage in SystemC either. However, there is a known issue around executable stacks in the QuickThreads implementation on some SELinux-enabled machines. Quoting the RELEASENOTES file: - When building the SystemC library with QuickThreads support, the resulting shared library is marked as requiring an executable stack by certain compilers/assemblers (or rather not marked as not needing one). As a result, some system security systems (like SELinux) might refuse to load the library. As a workaround for GNU (compatible) assemblers, pass the assembler flags variable with the option CCASFLAGS="-Wa,--noexecstack" to the `configure' script call before building the SystemC library. In case you can reproduce the effect again, can you try the suggested flag on the configure script? Hope that helps, Philipp
  13. Philipp A Hartmann

    tlm_fifo nb_peek

    Alternatively, as you don't seem to require the debug interface, you can change the port to: sc_port<tlm::tlm_get_peek_if<int> > target_port;
  14. Hi Jan, please check this thread for a previous discussion (and fix) of this issue: Hope that helps, Philipp
  15. Philipp A Hartmann

    SystemC catching/rethrowing standard exceptions is harmful?

    You may be able to break on __cxa_throw explicitly and add a condition to the breakpoint to filter out unwanted exception types (e.g. sc_unwind_exception for thread resets).