RE: [sv-bc] assignment to input

>From: "Rich, Dave" <Dave_Rich@mentor.com>

>In SystemVerilog, we tried to overcome this loophole by defining an
>input port of a variable as a continuous assignment, and since variables
>can only have one CA, an input port could not be coerced to an output or
>inout.

This is pretty much backward from my understanding of the causality.
Input ports were already defined as continuous assignments in IEEE 1364.
The inability to get correct behavior with multiple CAs on variables
resulted in the restriction to one CA.  Some users may have started
regarding that limitation as a beneficial one, because it enforced
in-house design rules against multiple-driver nets.  But that is a
result of the restriction, not the cause for it.


>However, a change late in the IEEE 1800-2005 LRM made inputs implicitly
>default to a wire kind, so that 'input reg a' is now treated as 'input
>wire reg a'

This particular example seems to have been chosen to look strange, and
blame the strangeness on that change.  However, if you think it looks
strange, it is because you are used to regarding 'reg' as meaning a
variable.  So the cause of the strangeness is that 'reg' was defined
to be a datatype equivalent to 'logic', instead of as an object kind
equivalent to 'var'.  It is the very possibility of 'reg' in the same
declaration as 'wire' that seems wrong, not the default kind for inputs.

Had 'reg' been defined to mean what 'var' means now, we could have had
a set of rules for ports that was backward compatible with Verilog-1995
and far simpler than what we have now.  All ports would have defaulted
to nets, unless explicitly declared as variables by using 'reg'.  That
would have been the only rule needed.  This would have required changing
the meaning of an output integer port allowed by Verilog-2001, but that
would have been minor.


>I doubt that anyone has implanted this change and would really like to
>revert it back to the way it was in 3.1a for this very reason. Wires
>should only be used where multiple drivers are required.

We have implemented it.

And I believe one of the major arguments for making these ports default
to nets was that the port collapsing rules for nets would automatically
fix the port direction if it was wrong.  Regardless of any of our personal
preferences, the fact is that users have been relying on this for a long
time.  

If somebody really wants to avoid multiple drivers in these situations,
they can define the default nettype to be uwire.  That will allow port
collapsing and still enforce the single driver rule.  It will actually do
a better job of enforcing it than a variable would.  A variable can only
guarantee a single driver local to the part of the network that is
variables.  If you connect the network to a net at a port, then you lose
the checking because there could be additional drivers on the net.  With
uwire, the checking is enforced across the entire network (or you get a
warning if one of the ports was not collapsed so that it was not enforced).

Steven Sharp
sharp@cadence.com