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

From: Greg Jaxon <Greg.Jaxon@synopsys.com>
Date: Tue Oct 25 2011 - 09:02:20 PDT

Since "output" captures indirection too early, "output ref" would be a better way to complete the data flow declaration,
and avoid the cost of static analysis.

On 10/25/2011 10:58 AM, Greg Jaxon wrote:

I can't offer either support or opposition to the rule being debated, but I must note that Steven's description of the limits
of analysis applies primarily (solely?) to simulators.  For synthesis (especially separate compilation synthesis), the situation
is just the reverse: task/function calls are statically analyzed (usually inlined), and hierarchical boundaries are a dynamic
feature of the ongoing linkage, revision, and re-linkage of designs as they are edited, optimized, or swapped during design
explorations before physical synthesis.

I guess my point is that defining rules that require inter-procedural or cross-hierarchy static analysis presumes more than
the products now in the market can all support. Removal of ref ports from modules is already a subgoal during
simulation->synthesis migration. It is a shame to hear that their removal from task/function headers is necessary for
accurate simulation. This makes ref direction a nexus for simulation/synthesis mismatch, for reasons that seem structural
and cut to the heart of how designs simulate and how they reach production. "Ref" is a programming abstraction with too
little dataflow information attached to be useful. "Const ref" adds one bit of the needed info. But to resolve "May-write" vs
"Must-write", another modifier is needed. "Output" exists to specify the latter. That leaves "may-write" as the data flow
semantics for a ref port (module,task,or function). Assuming any more constraints ignores the language context of
plain vanilla "ref".

Greg

On 10/24/2011 7:46 PM, Steven Sharp wrote:

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] On Behalf Of Daniel Mlynek
Sent: Thursday, October 20, 2011 11:09 AM
To: 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, 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, and is
believed to be clean.

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

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. Received on Tue Oct 25 09:03:03 2011