RE: [sv-bc] variable driven by continous assignment and ref port

I agree that whether a construct is an assignment-like context is not directly relevant to whether it is considered an assignment for purposes of this rule. That is not what the concept of assignment-like contexts was defined for.

I believe that a ref port should not be considered to drive a variable attached to it. It just makes the variable available to the module, as if by a hierarchical reference. What matters is what the module does with it. If the module contains a continuous assignment to the ref port, or a procedural assignment to it, then that would violate the rule.

This analysis is possible because module port connections are part of the static hierarchy. On the other hand, ref arguments to tasks/functions are done procedurally at runtime. Therefore I think passing a variable as a non-const ref argument to a task/function should be considered a procedural write. If the subroutine isn't intended to write to the ref argument, then it should be declared a const ref.

From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of Daniel Mlynek
Sent: Monday, October 24, 2011 2:09 AM
To: Bresticker, Shalom
Cc: sv-bc@eda.org
Subject: Re: [sv-bc] variable driven by continous assignment and ref port

I know this statement about assignment like context but LRM do not use term assignment like context when defining waht is legal and what is not for variable:
The precise rule is that it shall be an error to have multiple continuous assignments or a mixture of procedural
and continuous assignments writing to any term in the expansion of a written longest static prefix of a
variable
It is more general it says about "mixture of procedural and continuous assignment" this make me think that behaviour of mixing ref port and continous assignment to single var is not defined

DANiel

On 10/23/2011 6:07 PM, Bresticker, Shalom wrote:
10.8 says,

In particular, none of the following shall be considered assignment-like contexts:
...
- The passing of a value to a subroutine ref port
- A port connection to an inout or ref port of a module, interface, or program

Shalom

From: owner-sv-bc@eda.org<mailto:owner-sv-bc@eda.org> [mailto:owner-sv-bc@eda.org] On Behalf Of Daniel Mlynek
Sent: Thursday, October 20, 2011 11:09 AM
To: sv-bc@eda.org<mailto:sv-bc@eda.org>
Subject: [sv-bc] variable driven by continous assignment and ref port

IMHO LRM is not explicit for below case. Should it be error if variable is driven by both continous assignment and ref port of function (ref port of module)?
I assume that const ref should be ok.
module bench ;
    reg packetbanch = 0;
    bit valid ;
    initial #5 packetbanch=1;
    initial #6 packetbanch=0;
    test chk1( packetbanch, valid) ;
endmodule

function automatic bit crc(ref reg packetcrc ) ;
 //packetcrc = 1;
 return 1'b0;
endfunction

module test ( input reg packet, output bit valid ) ;

initial begin
  $monitor("%d> %d %d", $time, packet, bench.packetbanch);
  #1;
  if (crc( packet ) == 1'b1) // error packet is driven by both continous and procedural assign???
  valid = 1'b1 ;
  #10;
  $finish;
 end
endmodule

--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.
---------------------------------------------------------------------
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<http://www.mailscanner.info/>, and is
believed to be clean.
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.