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

Hi Gord.

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).

Because verilog and SV are hardware descriptions and not
programming languages, this concurrency is necessary and
is not really misleading.

I agree that a construct such as

   assign some_net = MyFunction(MyVariable++);

should be illegal. However, in verilog, the result
would be completely predictable (except for implied
race conditions caused by concurrency). The problem is
that the result(s) are hard for a designer to predict and
code properly. There is a potential for the effects of
the coding to be simulator-dependent, unless the designer
was careful about possible race conditions over the
whole module, if not the whole design.

Yes, the variable increment would have side-effects;
but, the stratified event queue would describe them
(and, their uncertainty) correctly.

For example, if MyVariable were a net type,
the sequencing of the various possible updates would differ
from those if it were a reg or logic type also updated
elsewhere by blocking vs. nonblocking procedural assignments.

The problem is complexity, not ambiguity.

One reason for the slow adoption of SV also is the
difficulty that its huge feature list poses for designers
(not to mention compiler developers) -- especially
for design teams or would-be code reusers with a
diversity of perspectives on the feature subset to
be learned and employed.

Unfortunately, the WGs seem to fixate well on racy
constructs but not at all on the breadth of the complexity
in the current Std.

The race to enhancements continues . . ..

On 04/09/2010 07:59 AM, Gordon Vreugdenhil wrote:
>
> Another way of talking about this, as has been implied
> by an earlier comment, is that any impure expression
> is unsafe in a continuous (or procedural continuous)
> assignment. There is no guarantee about what a simulator
> might do with a continuous assignment and the LRM does
> not really give direct event semantics for continuous
> assignments (in fact even what it does say is somewhat
> misleading in practice). So it is immaterial whether
> the impurity is in a function body (a traditional
> side-effecting function) or in an expression assignment
> operator -- it is not safe. The SV LRM restricts the new
> SV assignment operators but doesn't attempt to address
> the pre-existing issues of impure functions inherited
> from base Verilog.
>
> Gord.
>
> Steven Sharp wrote:
>>> Date: Thu, 08 Apr 2010 13:31:31 -0700
>>> From: John Michael Williams <john@svtii.com>
>>
>>> Minor point of terminology:
>>>
>>> I agree that the ++ operation in the argument list
>>> of a nonprocedural function call should not be allowed.
>>> However, I would not call it a "side effect".
>>>
>>> The increment is unrelated to the function; it is applied
>>> directly to the variable being used as a real parameter
>>> in the call. This is what makes it illegal. If it were
>>> in the function body, or perhaps applied to a formal
>>> parameter of the function, an increment of a variable declared
>>> outside the function would be causing what I would
>>> call a side effect.
>>
>> I think you are fixating on the use of the term "side effect"
>> as a property of a function. It has a more general meaning.
>>
>> I am not calling this a side effect of the function. I am calling
>> it a side effect of evaluating the expression. The main effect of
>> evaluating the expression is to get its value. Changing the values
>> of any variables in the process is a side effect of the evaluation.
>> This is a correct use of the term.
>>
>> 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.