Re: [sv-bc] expressions not allowed in RHS or continous assign or on port connection list

Hi Gord.

The LRM says nothing about the order in which
which concurrent statements should be executed
BECAUSE that is the meaning of concurrency.

The stratified event queue is STRATIFIED just to
handle concurrency:

Events scheduled in the current time will be
executed in random order. It is up
to the designer to write the verilog so that this
random ordering, which is meant to represent real
hardware, does not affect results.

If the LRM (or a conforming simulator) gave
an UNambiguous value for "w" in your example,
it would not be useful to describe the ACTUALLY
random effect of a race condition in the
hardware.

You wrote poor verilog, to illustrate your
point, so the LRM can't say it might not be
ambiguous. If you put a dependence
on clock or a control signal in your assignment
to "w", this might prevent ambiguity: e. g.,

    w = (ena==1'b1)? a + b + c++: a + b + c;

Of course, this SHOULD be evolving in nonzero
simulation time; your example is set entirely before
time = 0 is established, which compounds the ambiguity.

Similarly, one might use nonblocking assignments
in other blocks. One can not expect hardware to
be well-represented the way single-threaded software
would.

The same with Steve Sharp's example. Nothing
in an LRM or a simulator can compensate for badly
written verilog!

When assign Out = Vector[3]; is placed in the active
queue, it will be placed there in RANDOM order,
relative to other newly active events. It's up to
the designer to write the verilog so that active events
are preceded and followed correctly, in simulation time,
as queued, by other ones.

There's nothing special about continuous assignments,
more than there is with other net updates, or
blocking assignments. Or, in the example below,
with $display().

Whether the LRM is ambiguous on the indexing question
doesn't bear on the way the hardware has to be simulated.
Perhaps the LRM should be modified, but this doesn't
mean that indexing into a vector of itself might create
a side-effect: What it might do, is create a race condition
(at least from the way I read Steve's explanation).

On 04/09/2010 02:55 PM, Gordon Vreugdenhil wrote:
> Thanks, Steve, you beat me to the general explanation.
>
> Let me add a specific example to this (one that most users
> don't realize is problematic).
>
> Assume you have:
>
> wire [3:0] w;
> assign w = a + b + c++;
> bit a = 0;
> bit b = 0;
> int c = 0;
>
> and have:
>
> intial begin
> a = 1;
> b = 1;
> $display("%d", w);
> end
>
> The output of "w" is in fact ambiguous. The LRM says
> nothing about *when* the continuous assignment is
> evaluated relative to the two sequential assignments
> to "a" and "b".
>
> So it would be valid to get a displays of numerous
> values for w. The simulator initialization comes
> into play as well as whether the continuous assign happens
> after each of the a/b updates, after both, or not until the
> initial process finished. There are no rules in the LRM
> stating what *must* happen other than the basic fact that the
> assignment will update the RHS expression value (before the
> active region is empty). But exactly when/how the simulator
> does that is undefined.
>
>
> Gord.
>
> Steven Sharp wrote:
>>> Date: Fri, 09 Apr 2010 11:37:41 -0700
>>> From: John Michael Williams <john@svtii.com>
>>
>>> I think what you mean is that there is no guarantee of the
>>> sequence of execution of a continuous assignment relative
>>> to other concurrent blocks (such as always or initial).
>>
>> This is not just an issue of ordering relative to other
>> concurrent blocks in time slices when a continuous assignment
>> evaluates. Whether a continuous assignment will evaluate at
>> all in a given time slice is not well-defined. If there is
>> a change in one of its operands that would change the value
>> of the expression, then it must evaluate. But it might or
>> might not evaluate in some other situations. If it evaluates
>> extra times but keeps getting the same result, this doesn't
>> matter as long as there are no side effects of the evaluation.
>>
>> For example, consider the assignment
>>
>> assign out = vector[3];
>>
>> Should this be evaluated only when bit 3 of vector changes?
>> Or can it evaluate whenever vector changes, with the selection
>> of bit 3 being part of the evaluation? The LRM doesn't really
>> specify this, nor should it. Implementations need to be free to
>> do this however they choose. In practice, this may depend on
>> whether vector is a variable or a net, and whether the net is
>> vectored or scalared. And as long as there are no side effects,
>> the difference is invisible.
>>
>> Any side effect that exposes exactly when or how often a
>> continuous assignment expression is evaluated is not going to
>> behave in a predictable or portable way.
>>
>>
>> Steven Sharp
>> sharp@cadence.com
>>
>>
>

-- 
      John Michael Williams
      Senior Adjunct Faculty
Silicon Valley Technical Institute
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.