RE: [sv-bc] assignment to input

We as a committee are trying to promote convergence, not divergence.
Sometimes it really doesn't mater what we decide as a committee,
especially when we try to change things that have already been
implemented for a while.  The marketplace will do that for us, and they
don't need a majority vote, just enough $$$.

Same thing with requiring ' in '{} assignment patterns and mixing ansi
and non-ansi styles in the same port list. They just have been
implemented too long and used too much to change them.

> -----Original Message-----
> From: Steven Sharp [mailto:sharp@cadence.com]
> Sent: Friday, September 22, 2006 5:59 PM
> To: sharp@cadence.com; shalom.bresticker@intel.com;
sv-bc@eda-stds.org;
> Rich, Dave
> Subject: 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