Re: [sv-bc] Task and Function inout port with default argument

I found myself qualifying the "crazy" verdict too, because
I was thinking of things like errno in libC, which should
probably have been a default output argument for the system
calls which can set it.

If you pass something with the "const" property to an output
actual, you might want an error or warning, and certainly would not
want the side-effect output to happen.
Making this an error is one way to suppress the copy-out action.
If the implementation recovers from that error, or if it only
gives a warning, it should still suppress the copy-out step for
that formal output (to uphold the lvalue's "const" property).

Walking farther down the garden path in which this is a mere
warning leads to the question "How can I omit an output argument
at some call sites without getting this warning, and without latching
the unneeded output into a register that I don't intend to read?"

If we make users supply writable storage as the default, there will
be times when we cannot statically decide that the storage is
never read - so we'll synthesize dead latches.  We could add new
syntax to stand for a sort of /dev/null output location.  Or we
could say that any "const" object fills that role.  Now,
if any message is emitted, it is just "informational".

Default arguments are a concession to "software engineering" where
one wants to change the API out from under a lot of call sites without
rewriting them all.  We should assume that someone using this
feature is sophisticated enough to handle nuances like the constness
of the default lvalue expression.

Greg Jaxon





Steven Sharp wrote:
>> From: Greg Jaxon <Greg.Jaxon@synopsys.com>
> 
>> I recall some extensive discussions of how to do
>> name resolution in default value expressions.  These may have
>> concluded that omitting actuals whose formals have "out" direction
>> should update some default storage locations.
>> That seems (just a bit) crazy to me, but if true it means my
>> whole "cancel the copy-out" premise is wrong.
> 
> During those discussions, I expressed the opinion that copying to
> some default storage location was weird.  However, since then I
> have noticed an analogous situation where we do exactly that in
> Verilog.
> 
> It occurs when the $random system function is called without a
> so-called "seed" argument (actually the full state of the random
> number generation stream, which is an inout).  The simulator uses
> a hidden default storage location for the "seed" (actually state)
> of the global random number generation stream.  It does both the
> input and output side of the argument passing.
> 
> This is not actually a precedent for what we are talking about,
> since this is a system function, not a Verilog function.  However,
> it does illustrate a situation where an inout argument with a
> default actual that copies in and out was useful.
> 
> Steven Sharp
> sharp@cadence.com
>