RE: [sv-bc] assignment to input

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

>There is no rule that says you can't change the LRM if it is warranted.
>That is why we have a committee. 

I completely agree.  But if we want to make progress, we cannot keep
revisiting decisions that have already been made, unless it is warranted.
One reason it might be warranted is if new issues are found that were
not considered when the decision was made.  That is not the case here.


>In this case, some change is warranted
>be cause the behavior of 'input bit clk' is not semantically defined.

It seems clearly enough defined to me.  Shalom was able to come to the
same conclusion that I did, based on the LRM text (as did you initially).
Your later interpretation is directly contradicted by the LRM text, so
it cannot be correct.  I have not seen any other interpretations that
are consistent with the LRM text.


> I also don't
>think we should be letting people declare wires on types that aren't
>currently defined and letting implementations diverge on their
>semantics.

Implementors are free to provide their users with whatever nonstandard
language extensions they wish.  Many language extensions in the current
standard started out that way, including everything donated from Superlog.
Of course, there is no guarantee that any nonstandard extension will go
into the standard, or that it will be unchanged in the process.  That is
the risk you take in providing or using them.  It is your choice as an
implementor whether you want to take that risk.


>Wires should only be used for multiply driven signals,

That is an opinion at one extreme of the spectrum.  I believe that
wires have some value beyond multiple driver resolution.  That is why
we proposed the uwire extension in Verilog.  Also, there may be
situations where you want to provide generic connectivity without
having to know whether there are multiple drivers.  Wires have the
advantage of acting more like real hardware wires than variables do.

An opinion at the opposite extreme would be that nets should be used
for all connectivity, and that all types you want to connect should be
allowed on nets.  You might think that is not workable, but Verilog
used to manage it, and I believe VHDL still does.


> and changing the
>default back to a var kind will also solve the issue of assigning to
>input ports that was recently raised.

That assumes that everyone agrees that the issue is a problem, and that
the solution is to disallow assigning to input ports.  Legacy Verilog
designs have relied on the alternate solution of port-collapsing for a
long time now.  And if you want to enforce single-driver semantics, the
uwire net type does it better than variables.


Steven Sharp
sharp@cadence.com