Debugging Multi threaded program in SystemC

[ANKUR SAINI]

I have been working on maintaining IP's that are written quite old (Legacy :-)). Most of the code use SC_THREAD extensively.
I know that it's not a good practice to use sc_thread and we should minimize it's use wherever possible to avoid context-switching.

But I would like to know what are the debugging techniques that can help in debug these multi threaded programs efficiently. As sometimes it's a nightmare to identify issues in a program surrounded by tons of threads running parallely.

Regards,
Ankur Saini

[Roman Popov]

SystemC does not execute your threads in parallel, they are executed sequentially. But this is true that inter-thread communtication is hard to debug. Best known debugging method is waveform analysis. Usually it is much faster to identify source of problem on waveform, rather than with text logs. With opensource kernel you can use sc_trace to trace variables. Commerical SystemC debuggers offer GUI with drag-and-drop support.

[AmeyaVS]

Hello @ANKUR SAINI,

If you are on Linux/UNIX with the Accellera release of SystemC library with the GNU toolchain, you can use the following tutorials for reference:

• https://sourceware.org/gdb/onlinedocs/gdb/Threads.html
• https://stackoverflow.com/questions/1695268/multi-threaded-debugging-tutorial-for-gdb-and-c

Due to the co-operative multi-tasking implementation of the SystemC library available from Accellera as @Roman Popov has mentioned, much of the debugging tasks are easier since all threads synchronize with the main library thread.

Let me know if it helps.

Regards,

Ameya Vikram Singh

 

[David Black]

Ankur,

I'm not sure where you got the advice that SC_THREADs are bad or cause context switching, because that is mostly just an old wives-tale. I did a study years ago that showed the difference between SC_METHODs and SC_THREADs is only 3%. Furthermore, it is a simulator implementation issue as the PoC implementation is only one of several. I know at least one implementation of the SystemC kernel actually had the advantage reversed (and it was faster than the PoC implementation).

The real problem is context switching, which cannot be totally avoided in any case. Context switches occur everytime your SC_METHODs return or your SC_THREADs call sc_core::wait() even if indirectly (e.g. sc_fifo::read()). If you are having performance issues, you need to be profiling your code to identify the real problems.

You can get rid of a lot of context switching if you simply elminate sc_clock's entirely from your design. Most engineers (esp. hardware focused) have a difficult time with this concept, but sc_clock causes two context switches per cycle and in many designs is entirely not needed. I did a presentation "Look Ma! No clocks!" (available somewhere under www.nascug.org) and demonstrated how a timer could be modeled accurately without clocks.

A couple of other areas often missed are I/O and compiler switches. I/O is much bigger than context switching in terms of slowing down simulations, and yet still I often see engineers putting SC_REPORT_INFO (or worse: std::cout and printf) in their code to dump all the activity to aid debug. Except for phases before SC_SIMULATION, you should really use SC_REPORT_INFO_VERB with SC_DEBUG or equivalent. As to compile-time switches, -O3 is really quite decent once you have most bugs out, and you can leave debug -g on without worry.

[ANKUR SAINI]

@AmeyaVS: Thanks for pointing out the document pointers. I will try to go through them.

@David Black: Thanks for your detailed comment. I got your point on context switching with both sc_method and sc_thread and in either case it is unavoidable.
But still, I think the best practice is to use sc_method wherever possible because that will definitely gonna aid us in debugging. As it gets executes in one shot, no suspend in between.

[David Black]

The problem with using SC_METHOD is that it forces a style of coding that is harder to design/debug and slows down the design process. Schedule-wise SystemC is supposed to be written quickly. If you take too much time writing/debugging it, then it can become a counterproductive effort and you might as well write RTL alone. I usually characterize it as follows: Loosely-Timed models should be written in a matter of days (not weeks or months). Approximately-Timed models should be written in terms of a few weeks (not months). Anything longer means that either you are adding too much detail (which also slows down model execution) or you are not properly reusing other people's work (purchasing/acquiring pre-written models).

So yes, I would use SC_METHOD when it's use is obvious/intuitive, but I would rather express ideas in the most natural manner to speed up development time, which often means using SC_THREAD.

 

[sheridp@umich.edu]

David, thank you for running those experiments showing a <3% difference.   As I model a lot of software state machines, I greatly prefer to use sc_threads, but have always wondered if the context-saving nature of threads makes my programs slower.  In profiling, I see that memcpy is called often and seems to be a factor in runtime.  With that in mind, is an sc_thread context switch with lots of local variables more expensive than if I instead put those variables as class members so that they are not local to the thread?