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

From: John Michael Williams <john@svtii.com>
Date: Wed Apr 07 2010 - 16:36:17 PDT

Hi Brad.

Right, however, verilog (and thus SV) permits something like,

assign Outport1 = MyFunction(variable2);

No side effect, assuming the usual verilog input-only declaration.

I think this would imply the legality of,

assign Outport1 = MyFunction(variable2++);

On 04/07/2010 03:12 PM, Brad Pierce wrote:
> If it's a problem, it predates the introduction of ++ and kin by SystemVerilog, because a function in Verilog could side-effect a global variable.
>
> In SystemVerilog, in a continuous assignment, such side-effecting cannot be done indirectly via a function port, because
>
> "It shall be illegal to call a function with output, inout, or ref arguments ... in an expression that is not within a procedural statement."
>
> -- Brad
>
>
> -----Original Message-----
> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of John Michael Williams
> Sent: Wednesday, April 07, 2010 2:53 PM
> To: sv-bc@eda.org
> Subject: Re: [sv-bc] expressions not allowed in RHS or continous assign or on port connection list
>
> Hi.
>
> This may be a problem, because function calls are permitted in
> continuous assignment statements in verilog.
>
> On 04/07/2010 07:51 AM, Brad Pierce wrote:
>> "It shall be illegal to include an assignment operator ... in an
>> expression that is not within a procedural statement."
>>
>> On Wed, Apr 7, 2010 at 7:43 AM, Daniel Mlynek
>> <daniel.mlynek@aldec.com.pl> wrote:
>>> I cannot find in LRM resrtictions on expression on RHS of continuous assign
>>> (same for port connection list items).
>>> IMO some expressions should not be allowed ie:
>>> assign w = i++;
>>> assign w = i=+10;
>>> assign w = foo(i); //where foo is function foo (ouput logic o); o=o-1;
>>> endfunction
>>>
>>> same for port connections:
>>> sub uut(i++);
>>> sub uut(i=+10);
>>> sub uut(foo(i)); //where foo is function foo (ouput logic o); o=o-1;
>>> endfunction
>>>
>>>
>>> Should it be allowed or forbidden?
>>> Is it described in LRM?
>>>
>>>
>>> DANiel
>>> --
>>> This message has been scanned for viruses and
>>> dangerous content by MailScanner, and is
>>> believed to be clean.
>>
>

-- 
      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.
Received on Wed Apr 7 16:33:49 2010

This archive was generated by hypermail 2.1.8 : Wed Apr 07 2010 - 16:34:00 PDT