Re: [sv-bc] fork-join_any with formal arguments

Surya

> Within a fork?join_any or fork?join_none block, it shall be illegal 
> to refer to formal arguments passed by reference other than in the 
> initialization value expressions of variables declared in a 
> block_item_declaration of the fork.
> 
> I need to understand how a 'ref' variable is referred inside for-
> join_any. I can think of only via the hierarchical reference it is 
> possible, but hierarchical reference is anyway not possible on 'ref'
> variable. Can anyone give one example for that on that restriction?

Suppose you were trying to create the same kind of behaviour as 
the $monitor system task.  You might try this:

  // Create a monitor on single-bit signal S
  function monitor_a_signal(ref logic S);
    // Launch a process that will continue to
    // monitor the specified signal
    fork
      forever @S $display("Signal S has changed to %b", S);
    join_none
    // Return immediately from the monitor_a_signal function
  endfunction

You might imagine that, because S was passed as a ref argument,
this could be expected to work.  In fact it _has_ worked in the
past in some SV simulators.  But it is obviously dangerous that
the fork...join_none is trying to access by reference a variable 
that might later cease to exist.  So the LRM has outlawed it.

The particular use case I've sketched, above, has been
requested by a number of users as a way of dynamically 
adding a probe to a signal.  It seems to me inherently
reasonable, provided that the actual argument in any call
to the function must be a static object that is guaranteed
to outlive the fork...join_none.  It has been suggested that
the language could enforce this by adding an optional "static"
qualifier to ref formals, requiring them to have actual
argument variables that are static.  Something like

  function monitor_a_signal(ref static logic S);

and then loosening the restriction you mentioned, so that
it would be OK to access such "ref static" objects from
within a fork...join_*.

But that will of course have to wait for a possible future
revision of SV.
-- 
Jonathan Bromley
Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, 
UK
Tel: +44 (0)1425 471223                   Email: 
jonathan.bromley@doulos.com
Fax: +44 (0)1425 471573                           Web: 
http://www.doulos.com

This message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.


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