I have seen someone implement a system of threads controlled by fork-join where the threads share and update variables. The system seemed to be relying on two properties to guarantee mutual exclusion when performing shared-variable updates: (1) the non-pre-emption of thread execution, i.e. that a thread will be uninterrupted until it suspends itself at a timing control and (2) that the threads run on a single processor.
The first of these properties, non-pre-emption, is, as I understand it, a requirement imposed by the SystemVerilog LRM. However, I have not seen anything that makes me believe that the LRM imposes the second property, that of a single processor. Therefore, I have considered the system mentioned above to be inherently non-portable. This seems unfortunate because the system is deployed across an organization but will not be robust against improvements in simulator technology in the direction of using multiple procesors.
Can anyone comment or enlighten?
This is not correct. The SystemVerilog LRM does not guarantee non-pre-emption. See section 4.7 Nondeterminism. The LRM does guarantee execution order within a single thread (process).
The reason Verilog allows preemption of a thread has more to do with optimization than anything to do with multiprocessor design. An real Verilog design has thousands even millions of "threads". It is not practical to model these as actual OS threads, so the compiler's optimizations combine as many threads as it can together. For example, all the the threads that are activated on @(posedge clk) might be combined into one real thread. This does not happen so much on the "testbench" side of the environment, but the option is there.
Until the number of processors in a multiprocessor platform approaches the number of threads in a simulated design, how the threads are partitioned on to each processor remains a bottleneck.
Dave Rich
Mentor Graphics
http://go.mentor.com/drich
Okay. Interesting. Sounds like it is necessary to develop cooperating parallel threads under the assumption that any interleaving of statments may be possibile and hence full attention to mutual exclusion of critical sections must be given at the thread-implementation level.
Do you agree?
I must admit that I didn't scour the LRM but thought that non-premption must be assured in it based on this statement by Janick Bergeron in "Writing Testbenches in SystemVerilog", pg. 163:
"In an operating system, every thread has a limit on the amount of processor time it can have during each execution slice. Once that limit is exhausted,the thread is kicked out of the processor to be replaced by another. There is no such limit in a simulator. Any execution thread keeps executing until it explicitly requests to be kicked out...
"In SystemVerilog, an execution thread simulates and and keeps simulating, until and active timing-control statement--@, # or wait--is executed."
Yes I agree.
With all due respect to my colleague, that book is not the standard, nor has Janick been involved with the development of the Verilog/SystemVerilog standard. I can see that one could make that statement from simple observations. In practice, no simulator is going to randomly interleave statements without some predictable cause.
There are a few places in the LRM where order is undefined, but people have come to depend a specific implementation to give them a specific ordering of what should be a race condition.
Dave Rich
Mentor Graphics
http://go.mentor.com/drich