RE: [sv-ec] Concurrency semantics in SystemVerilog

David,
  A general answer to your question; The best way to think about it is
to look at the end result not necessarily how that result was reached.

A simulation result can be considered LRM compliant if that result could
have been achieved following all LRM scheduling rules (not what a given
implementation does under the hood)

So as an example following the LRM text you cite

module test();
logic a,b,c,d;

initial begin
        a = 1;
        b = 1;
end

initial begin
        c = 1;
        d = 1;
end

endmodule

The LRM scheduling rules say that the initial blocks can be executed in
either order, and that they can be executed in their entirety or
suspended.

So the statements actually being executed in the a,b,c,d is legal as is
a,c,b,d (and a number of other permutations)
So a simulator implementation can have its optimizer scheduler or
multiprocessor scheduler choose any of those outcomes as long as the
result is one of the results that could have occurred.

Hope this makes sense,
~Alex

-----Original Message-----
From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of
David Jones
Sent: Friday, February 18, 2011 4:27 PM
To: sv-ec@eda.org
Subject: [sv-ec] Concurrency semantics in SystemVerilog

What assumptions can I make if I assume that a SystemVerilog simulator
may execute in a truly concurrent manner on a multiprocessor computer
system?

Section 4.6a) of the LRM states:

Execution of statements in a particular begin-end block can be
suspended in favor
of other processes in the model;

But there's a lot that one can read into that sentence. On the one
hand, it is clear that if a sequence of statements in a begin-end
block contains a blocking statement (e.g. #delay or a call to a task
that consumes time) then the execution will be suspended.

However, can execution be suspended (even on a uniprocessor) if a
sequence contains no blocking statement? The LRM doesn't say that it
won't. And on a multiprocessor, two different begin-end blocks can
execute in a truly concurrent manner. Nothing gets "suspended" in this
case.

If truly concurrent execution is possible, then what SystemVerilog
constructs, if any, can I assume will be thread-safe?

- mailboxes? (likely yes)
- x++ (I'd be surprised if this were concurrent-safe)
- queue operations such as q.push_back()
- other?

This isn't hypothetical either. Every SystemVerilog implementation
that I have access to is running on multiprocessor hardware, and I am
assuming that all EDA vendors are working on MP-aware implementations
of SV. (I am aware of such an effort from one of the "big 3".) As an
author of SystemVerilog IP I want to ensure that my code will work
properly on such systems.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.