CODEWITHSUNDEEP
multithreadingsystem-verilog
user17282831
user17282831

Reputation:

What mechanism prevents System Verilog threads from obtaining a semaphore at the same time?

There is definitely a good chance I am misunderstanding something. Since System Verilog is an event driven parallel language (with respect to verification), I have trouble understanding the underlying architecture. Mainly I wonder what stops two threads from acquiring the same semaphore at the same instant such that each doesn't "realize" the other has already acquired it. For a language like C, I can understand that (in an RTOS for example) each thread takes turns with the CPU to emulate parallel functionality despite being sequential in nature. Is the same true for System Verilog?

The IEEE standard is a great resource for using the language, but leaves a lot to be desired when it comes to understanding the bridge between hardware and software (when using the language as software for verification I mean).

Thanks for your time and knowledge.

Upvotes: 0

Views: 479

Answers (1)

dave_59
dave_59

Reputation: 42698

RTOS as well as many other OSs can run multiple threads on multiple cores, so all threads are not necessarily sequential. But similar an RTOS, the concept of SystemVerilog "time" is a globally synchronized resource and is shared among all threads.

Because SystemVerilog is a Hardware Description Language , there is a massive amount of thread parallelism, making multi-core execution a very difficult problem. And there are also multiple divisions of synchronization even within a single time unit (event regions). Although it's possible to disconnect this synchronization between threads for a certain period of time, (like a clock cycle or transaction level boundary) some master thread kernel has to coordinate when that synchronization happens.

The IEEE 1800-2017 SystemVerilog LRM does not define whether threads execute sequentially or concurrently; only what ordering is guaranteed or not. (Sections 4.6 Determinism and 4.7 Nondeterminism). It's just that there are far more SystemVerilog threads than could every run all concurrently, and the scheduling semantics are written most optimally for the SystemVerilog simulation kernel to manage the threads as if they were all sequential.

Regardless of whether SystemVerilog threads are executing sequentially or concurrently, the handling of semaphore is request is the same. The thread requesting the a semaphore key asks the kernel for the key, and the thread asking for it first—gets it first. Since the kernel is operating as a single thread itself, it gets to decide who should get the key in a deterministic way.

Upvotes: 2

Related Questions