Regarding thread switch in systemverilog

SystemVerilog
1

Hi,

I’m curious how systemverilog defines when to “switch between” thread execution.
I remember I read from somewhere that systemverilog is actually single thread , simulator schedules all the tasks/functions so that it provides the illusion of thread-level parallelism.


task thread_1();
  int a;
  repeat(100) a = 1 + 1;
  @my_event;
  repeat(100) a = 1 + 1;
endtask
fork 
   thread_1();
   thread_1();
join

So my question is , for 2 tasks running in parallel, when does simulator decide to suspend current thread_1(), and go execute thread_1()? when some wait statement occurs like

@my_event;

? or it could be at any random point like inside execution of

 repeat(100) a = 1 + 1;

?

Thanks,
Jeff

2

In reply to Jeff_Li_90:

So my question is , for 2 tasks running in parallel, when does simulator decide to suspend current thread_1(), and go execute thread_1()? when some wait statement occurs like

Yes

3

In reply to ben@SystemVerilog.us:

That is the most realistic explanation, but not how SystemVerilog is defined (See section 4.7 Nondeterminism in the IEEE 1800-2017 SystemVerilog LRM). By definition, only the relative order of statements with a single thread are guaranteed. Relative ordering between threads executing within the same active region cannot be relied upon.

Two places where the “single executing thread” model breaks down is when the simulation is spread across multiple cores, and optimizations that tie together what looks like independent threads into a single monolithic thread.

4

it occurred to me that since the multi thread parallel execution is an illusion, then what’s the point having mailbox for inter-process communication rather than simple queues?
I mean essentially queue push/pop method is executed single-thread internally without interruption, isn’t it?

I was under the impression that mailbox provides built-in semaphore-like operation to prevent race condition when multiple thread accessing same mailbox, but since multi-thread is an illusion, why would anyone need to use mailbox instead of just queues?

5

In reply to Jeff_Li_90:

The point of my previous comment is to say that you can’t depend on implementations behaving like a single thread.

But in addition to the thread-safe access to the mailbox object which you may or many not believe is necessary, a mailbox provides FIFO thread access to the mailbox items which you cannot get with just a plain queue. That means if one thread is waiting for a get(), and another thread does a get() and there is a well defined ordering between the two, the mailbox makes sure the first thread receives the mailbox item. So a mailbox class is a actually a collection of queues and semaphores.