Parallel Simulation

[plafratt]

I am interested in learning whether SystemC supports parallel simulation - that is, utilizing multicore processor or multiprocessor systems to speed up simulations.

 

I see in the SystemC 2.1 Features document the specification of a function sc_spawn. Does this function spawn an new Linux process?

 

Near the end of the Features document, there is mention of thread support based on Posix threads. Does building SystemC with pthreads enabled allow for multi-threaded simulations? If so, is a thread created for each SC_THREAD and SC_METHOD, or is some other approach used?

 

Any help is appreciated.

 

Patrick

[apfitch]

The short answer is "no". Though some University did work on a parallel implementation (sorry I can't remember which one).

 

There is interest in the Language Working Group.

 

Current implementations of SystemC run as a single thread. Pthreads or Quickthreads are used to emulate parallel threads, but running within a single OS thread.

 

regards

Alan

[sumit_tuwien]

I would like to add something interesting with Alan. 

 

You can write a real parallel thread library and use it as an alternative to pthread or qt. You might wish to use c++11 features or OpenMP library (however I do not personally like the syntax provided by c++11 OR OpenMP; they poses more problems when you want solution). You have a good amount of challenge waiting in front of you and I wish you good luck with them.

 

Happy learning.

 

Regards, Sumit

[thomas.haber]

Hi Sumit,

 

just some tought on this.

I had similar ideas when i was covered with the spin simulator.

If you want to keep a "systemC sync" on all processes you probably have to give more effort than you can take from it.

A solution could be to allow async for a given amout (like tlm). 

 

In spin you have the possibility to do parallel calculation for a given "simulator time".

In these proclets you calculate but can not change any signals, and change signals when your are out and back in sync. 

The same you can do in systemC. Doing parallell calculations in a seperate "real" thread, but keep systemC running in its own process means.

 

regards,

thomas

[plafratt]

Thank you for the responses, everyone. This is quite helpful.  I will keep an eye out for ongoing efforts to parallelize SystemC.

 

Regards,

Patrick

[jb22]

I'd like to catch up on this with another question. This is also SystemC-AMS related, but I think it might fit in this thread.

 

I want to simulate larger modular electrical networks making use of a compute cluster I have available. As I have learned from the previous posts it is not possible to run on multiple cores as SC_THREAD only creates virtual parallelism, but everything will run within one OS thread/process.

 

Using openMP for parallelizing execution, could I call sc_main from a parallel for loop? In other words I'd wrap SystemC code within a regular C++ application and spawn processes on C++ level. Will there be any conflicts between the parallel invocations of the systemc header files and the shared library (e.g. global variables)?

 

Thank you very much

Cheers,

Jens

[sumit_tuwien]

Jens,

 

You possibly cannot. Once you start a simulation you will have to exit the simulation completely. Re-elaboration is not possible. sc_main is actually is a missing function in systemc library which you need to provide.

 

sysc/kernel/sc_main.cpp is actually main which calls : int sc_elab_and_sim( int argc, char* argv[] ) which calls your sc_main .... (see sc_main_main.cpp) file.

 

 

You cannot parallelize (if then huge effort is needed) this function as once elaboration is done you cannot clean and re-elaborate. sc_start() needs a complete re-write ....

 

Regards, Sumit 

[jb22]

Hi Sumit,

 

thanks for the clarification.

 

Cheers,

Jens

[plafratt]

Jens, Sumit-

 

I haven't tried what Jens has proposed with OpenMP, so I can't speak from experience. However, my understanding is that Jens is perhaps not trying to parallelize a single call to sc_main, but rather trying something akin to creating multiple processes, each from its own sc_main.  If each sc_main is isolated from the others, perhaps each could have its own elaboration. This seems to me like something that might be feasible.

 

However, I would not think that SystemC's internal processes (i.e. sc_methods, sc_threads, etc.) could be synchronized across processes in such an environment.

 

Regards,

Patrick

[jb22]

Patrick,

thanks for putting my thoughts in a bit more understandle sentences

This is exactly what I wanted to ask.

 

For a different project I am using a shared library of a SPICE implementation. In order to run individual simulations in parallel I have to create separate copies of the shared library and load each thread/process with its own library to avoid conflicts. I assume creating multiple copies of the SystemC library might do the trick as well. But I have to figure out the details and test it first to be sure.

 

Cheers,
Jens