Re: [sv-bc] Why no 'output' continuous assignments from a function call?

> In a year, the world will forget which came first, the internal
>side-effect or the output port side effect. It will probably never
>realize that one was "grandfathered"-in, and the other was "stillborn".
>Instead, some code transformation that moves a hidden side-effect
>up into the call site's argument list will be met with an error.

But a user with legacy code will certainly notice when it suddenly
stops working. And that only happens with changes to old behavior.

> Perhaps the LRM should prescribe that functions called within continuous
>assignment expressions must be pure. We would have to note this
>exception to backward compatibility and give a good rationale.

It would certainly be a good design rule. Were you suggesting that this
be a stated requirement of the user, or that the tools would have to check
for it?

The degree of backward compatibility problems may depend on your
definition of purity. I would hope that there is not a lot of code
out there that relies on blatant side effects. Any that does should
probably be fixed. Defining it as something like not referencing any
objects nonlocal to the function might be reasonable. If you wanted
to get really rigorous, however, you would run into trouble. Verilog
functions are static by default, with all variables, arguments and
return values being static variables. That provides ways of having
nonobvious side interactions between callers, and it is not generally
computable whether a given function could have such an interaction.
Automatic functions don't have this problem, but they are a recent
introduction, and most legacy code won't be using them.

Some forms of impurity are also useful. It is handy to be able to do
a $display from a function called from a continuous assignment. It
can help with debugging, and is fine as long as I don't expect that I
will get deterministic behavior between different implementations.

> Or perhaps continuous assignment expressions need their own scope
>so "automatic" variables can be used to form form input/output
>connections between multiple function calls.

This would only cover one of the possible uses for output arguments, and
it is one that is not guaranteed to work anyway. There is no defined
order of evaluation that would guarantee that the function outputs would
get computed before they were used by other calls as inputs. Unless I
am misunderstanding what you are suggesting?

> I take no position as to which would be better for the user community,
>but I am not totally sold on your "finger in the dike" policy.

I would characterize it as a "don't blow new holes in the dike" policy
myself. If we can find ways to fix the old holes, without too much cost
to existing users, I'm in favor of that also.

Steven Sharp
sharp@cadence.com
Received on Thu Nov 4 17:54:17 2004