David,
There are very few guarantees formally in the LRM. The LRM
does make guarantees about relative statement order and
NBA (same process) update order and effect, but that is
about all.
1800-2009 Clause 4.7 has a stronger statement than the
one you quote:
At any time while evaluating a procedural statement, the
simulator may suspend execution and place the partially
completed event as a pending event in the event region.
Additionally, the LRM goes out of the way to be clear that
implementations have substantial leeway in various places;
you mentioned "++" and that is a good example. 11.4.2 states:
The ordering of assignment operations relative to any other
operation within an expression is undefined. An implementation
can warn whenever a variable is both written and read-or-written
within an integral expression or in other contexts where an
implementation cannot guarantee order of evaluation.
and gives an example with implementation defined results
(even in sequential simulation). The intent is clearly to allow
decoupling of assignment and expression parts to allow for
common compiler optimizations. Making any assumption
about the atomicity of such operations would not be valid.
There are many subtle assumptions about intent throughout
the LRM in these areas. I doubt that anyone would be happy
with an implementation that didn't have atomic operations
for mailbox operations and semaphores since those form
the basis of modern TB constructs. But I'd certainly talk very
carefully with any vendor doing very low level parallelism
about what they will or won't guarantee. There are clearly
more "coarse" granularities of parallelism that wouldn't
suffer from some of the interactions that you mention, but
from an LRM perspective there are very few guarantees.
One would need to be very, very careful in trying to establish
stronger models. There are many (long) established
optimization techniques that modern simulators use and
which rely on fairly aggressive application of the flexible
scheduling rules; one could easily cause substantial
performance impact in trying to provide strong guarantees.
Gord.
On 2/18/2011 4:27 PM, David Jones wrote:
> 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.
>
-- -------------------------------------------------------------------- Gordon Vreugdenhil 503-685-0808 Model Technology (Mentor Graphics) gordonv@model.com -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Sat Feb 19 19:48:19 2011
This archive was generated by hypermail 2.1.8 : Sat Feb 19 2011 - 19:48:38 PST