4

I am trying to port a SystemVerilog model of a memory controller to SystemC and am wondering what is the best way to translate run()-type functions (i.e. with forever loops that do continuous processing) spawned with fork and join to SystemC. These run() functions are typically spawned at the beginning of the simulation. My confusion is that SystemC does support spawning threads, fork and join, but I believe the language's intent is for SC_THREAD to provide this kind of functionality. Does anyone have enough experience with both languages to comment?

Note: I believe this question has more to do with convention than a solution that is technically right or wrong. Possibly it can be done more than one way.

Rich
  • 1,165
  • 1
  • 15
  • 29
  • 1
    Since SystemC is co-operatively multi-tasking, it is deterministic, whereas normal POSIX threads are preemptive multi-tasking and hence non-deterministic along with a host of other complications. I'd highly recommend not kludging in POSIX threads as this could make your simulations not be reproducible for generating dumps. Forgive me if this is obvious. Anyways, I do think you do want to use `SC_THREAD`. – Ross Rogers Dec 19 '12 at 17:59
  • Thanks Ross, it is not obvious to me. I'm now interested, is SystemVerilog's multi-tasking deterministic or not? i.e. would successive simulations have the same guaranteed results? – Rich Dec 21 '12 at 13:22
  • All commercial Verilog/VHDL simulators are deterministic from a rerun point of view _given the same random number generator (RNG) seed number_, which is an optional parameter on the command line. The simulators have to be deterministic in order to reproduce errors and generate signals dumps (VCD/FSDB/VCD/et c.). This is the entire point of running HDL simulations anyway. The paradigm is more of a [cooperatively mult-tasking](http://bit.ly/7epxWx) [RTOS](http://bit.ly/VUHRyb), rather than [preemptive multi-tasking](http://bit.ly/UdA2q5) which is the paradigm of Linux's POSIX threads. – Ross Rogers Dec 21 '12 at 18:00

1 Answers1

0

sc_thread is the analogue of SystemVerilog's fork/join. Both languages implement their threads using the same non-preemptive multi-threading semantics. That is, a thread runs until it waits for something. At that point the thread cedes control to any other threads that are scheduled to run at the same time. Both languages are deterministic with restrictions. Obviously the seed has to be the same, but also changing any code can cause randomization to change. I believe that this also includes the order that threads run in, but I may be wrong.

As pointed out above, you should not use posix fork/join in SystemC because the library is not thread safe and also because it breaks the assumptions of the library an introduces non-determinism.

So, porting should be straightforward as long as the SV code doesn't have features that SC lacks.

Allan Carter
  • 1
  • 1