Jump to content


  • Content Count

  • Joined

  • Last visited

  1. yorkwar

    Weird SystemC Context

    It turns out that some 3rd party library has some memory using problem. Thanks all.
  2. yorkwar

    Weird SystemC Context

    Hi Alan, That's not the case. I checked the back trace. It's called in a SC_THREAD, not SC_METHOD.
  3. yorkwar

    Weird SystemC Context

    Thank you for your response. There are some SC_METHODs in my simulation, cause it is a light wight SystemC process. But at that time when the error occurs, as cpi->kind indicates, that should be a SC_THREAD. There must be some memory pollution problem that is hard to find. Any hint is greatly appreciated!
  4. yorkwar

    Weird SystemC Context

    Hi, I have some models built against SystemC-2.3.1. During simulation, I get an error telling me "in SC_METHODS use next_trigger() instead". I set a breakpoint there, and check cpi->kind. It's "sc_core::SC_THREAD_PROC_". I'm puzzled why the switch case pattern goes to the default case (in wait(const sc_time&t, const sc_event& e, sc_simcontext* simc) of the file sc_wait.cpp), which causes the error. At the same time, there's another odd thing. Through backtrace of GDB, I see #0 sc_core::wait (t=..., e=..., simc=0x399f010) #1 sc_core::sc_module::wait (this=0x3fee1d0, t=..., e=...) #2 my_module:my_thread (this=0x3fee1d0) #3 sc_core::sc_process_b::semantics (this=0x4046170) #4 sc_core::sc_thread_cor_fn (arg=0x4046170) #5 sc_core::sc_cor_qt_wrapper (arg=0x4046170, cor=0x46765e0, fn=...) #6 qt_blocki () So, it should be in the SystemC thread of my_module::my_thread. However, I checked sc_core::sc_curr_simcontext->get_curr_proc_info()->process_handle->m_name in GDB, it shows that it is the name of another thread. I checked the program with Valgrind. It only shows some invalid read, no error with write. Anything wrong?
  5. Hi, The code below in this function may be not appropriate. //get the interfaces bound to the top of the hierachical bind chain // NOTE: this could be the same socket if there is no hierachical bind m_used_sockets=get_hierarch_bind()->get_sockets(); IEEE-1666-2011 stated: In my case, I do some port binding in my sc_module's API of before_end_of_elaboration. Then, if tlm_utils::multi_passthrough_initiator_socket::before_end_of_elaboration() is called before the one in my sc_module, m_used_sockets may have the out-of-data of value. It still indicates that there's no binding for this socket. In fact, m_sockets really indicates that there's a binding now. Then subsequent usage of m_used_sockets may cause an error.