RE: [sv-bc] assignment to input

For some good background on port coercion, see

     http://www.boydtechinc.com/btf/report/full_pr/54.html

especially 

     http://boydtechinc.com/btf/archive/btf_2001/1595.html

-- Brad

-----Original Message-----
From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of
Bresticker, Shalom
Sent: Tuesday, September 26, 2006 4:34 AM
To: Steven Sharp; sv-bc@eda-stds.org
Subject: RE: [sv-bc] assignment to input

I agree that disallowing assignments to input ports will cause a
back-compatibility problem with legacy code. A warning would be nice.

However, I don't think that port collapsing exists for that purpose or
that legacy code relies on that deliberately. I think that assignments
to input ports are mistakes that occur typically because people did not
notice that the port is defined as input (if the simulator coerces the
port to inout silently, then the user does not notice it), or because of
a thought like, "Well, we do have an internal pullup or precharge or
buskeeper on this net, but all significant values are driven from
outside", and they do not understand that the net really is an inout.

Shalom

> > 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.