RE: [sv-bc] task/function inout arguments with default values

Comments inside:

> Sure.  I was simplifying it to be easier to follow.  To be more
> precise, they want a default value computed the same way as last time,
> from scratch, not something left over from the output of the previous
> call.  If someone wants to communicate a value from one call to the
> next, the clean way of doing this is to use a static variable in the
> task/function.

[SB] One "argument" for default inout arguments as real inouts is simply
to avoid the need to specify the arguments explicitly in the default
case, as is one of the reasons for any defaults.

One could further argue that this is just a less extreme case of using
global variables in tasks and functions. There the global variable does
not even appear in the task/func header nor is there any way to override
the "default".

The most extreme case is void functions and tasks with no argument lists
with all global variables.

The reason for using a global variable or a default argument instead of
an internal static variable in the task/function is to allow the
variable visibility in the outer scope. A hierarchical reference into
the task/function is both verbose and today unsynthesizable.


> The apparent difference from ref args is probably the strongest
argument
> against my suggested treatment.
> 
> Note that from the viewpoint of someone who understands the
> implementation
> of ref args (or any C programmer), this difference isn't real.  All
> default argument values would be only copied in, never out.  A ref arg
> doesn't have a copy-out part.  It is an input argument whose value is
an
> address.  Like any of the other argument types, the default provides
> an input value.  It is just that this value must be a reference to a
> variable.  However, since typical users won't understand this, it may
> still look different to them.

[SB] I would argue that the difference is very real. The implementation
mechanism may be similar, but the effect on behavior is very different,
and that is what is important.


> >> When you leave off an output, you want the output discarded.
> >
> >While you can leave off a module output, I don't think you can leave
> off
> >a task/function output.
> 
> I think you are correct.  However, we have had this request from our
> users.  I think we may have allowed it in our implementation as a
> nonstandard but natural extension.

[SB] I just filed this enhancement request as Mantis 1600.


> >On the other hand, if you say that an inout default is like an
explicit
> >inout argument and there is copy-out at the task end to the default
> >expression, then it might also be logical to allow defaults for
> outputs.
> 
> Agreed.  The fact that defaults are not allowed for outputs tends to
> indicate that the copy-out functionality was never intended to be
> applied for defaults.
> 
> It might just be that it wasn't considered.  But even that would say
> something significant about the usefulness of it.

[SB] Or not. While I think our record is overall not bad, there have
been more than a few times where users have disagreed strongly with our
view of what is useful.


> I think that users want to leave off output arguments, but not to have
> to supply a default place to copy the output to.  They just want the
> output discarded.  I think the behavior of inouts then follows from
the
> combination of inputs with defaults and outputs.

[SB] Allowing defaults for outputs would allow the user to specify the
usual case implicitly, override it for the non-usual case, or still
leave it unconnected by an explicit unconnection. If there were no
default, omitting it would leave it unconnected, as today. One could
argue that this is confusing, having different behaviors from omitting
the arguments depending on whether a default was internally defined. One
could counter-argue that the user needs in any case to know how each
argument is defined and a default is only one more attribute.

I will file one or more Mantis issues on this once I have time to figure
out what to write.

I am also working on a draft proposal for defaults for module ports, at
least for input ports, at least for constant values. The motivation for
this is to allow default disabling connections for unused logic.

Shalom