Jump to content

Philipp A Hartmann

Members
  • Content Count

    537
  • Joined

  • Last visited

  • Days Won

    130

Everything posted by Philipp A Hartmann

  1. These classes are templates themselves. You need to pass the type of the values as parameter, for example tlm_fifo< std::array<int,4> > // a FIFO sending 4-element arrays of integers /Philipp
  2. Use an std::vector or std::array as value type in your FIFO instead of a C-style array.
  3. 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 co
  4. 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
  5. 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
  6. 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
  7. 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
  8. 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
  9. 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
  10. 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).
  11. 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
  12. 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.
  13. 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
  14. 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
  15. 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 compar
  16. 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
  17. 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
  18. 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
  19. 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
  20. 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 // ... { publ
  21. 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, p
  22. 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;
  23. Hi Jan, please check this thread for a previous discussion (and fix) of this issue: Hope that helps, Philipp
  24. 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).
×
×
  • Create New...