Jump to content
yorkwar

Weird SystemC Context

Recommended Posts

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?

Share this post


Link to post
Share on other sites

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!

Share this post


Link to post
Share on other sites

The error message implies that you are calling wait() in your SC_METHOD - that's not allowed, wait() can only be called in SC_THREADS,

 

regards

Alan

 

Hi Alan,

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

Share this post


Link to post
Share on other sites

Ok, as Roman says above, it's hard to help without the source code.

 

This might be obvious, but if you can't post the code, I would try the following

1. Try the same code on a different compiler and/or OS

2. Try to narrow down exactly what line of code is causing the problem by commenting out code until the problem disappears

3. Try setting breakpoints progressively further in the simulation until you can set a breakpoint just before the failure

 

regards

Alan

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×