RE: [sv-ec] Concurrency semantics in SystemVerilog

Yes, but there are certainly some operations that have to be atomic or close to it in order to work.

An example would be parallel execution of a non-reentrant function.

In order to avoid overwriting internal variables, it is necessary to avoid interleaving of the two function calls.

Even something as simple as

function f(i);
f= i ;
endfunction

initial a = f(0);
initial b = f(1);

a must be assigned 0, and b must be assigned 1.
Yet unrestricted interleaving would allow f(0) to start execution, suspend, start f(1), overwrite i, end f(1), and then resume f(0) and give the wrong result.

See also Mantis 1290.

Regards,
Shalom

> -----Original Message-----
> From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of
> Gordon Vreugdenhil
> Sent: Sunday, February 20, 2011 5:48 AM
> To: David Jones
> Cc: sv-ec@eda.org
> Subject: Re: [sv-ec] Concurrency semantics in SystemVerilog
>
> 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.

---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

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