RE: [sv-bc] Clarification on net/var port determination

The backward compatibility problem is that

module foo(input bit i);

becomes illegal because a bit is not a valid type for a net (yet).

Dave


> -----Original Message-----
> From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org]
On
> Behalf Of Steven Sharp
> Sent: Wednesday, August 16, 2006 3:13 PM
> To: sv-bc@server.verilog.org; Vreugdenhil, Gordon
> Subject: Re: [sv-bc] Clarification on net/var port determination
> 
> 
> >
> >Is there any compelling reason to have inputs default to net
> >types while outputs default to vars?  I understand that outputs
> >must default to vars for compatibility reasons, but there
> >doesn't seem to be a symmetric argument for input.  Since,
> >if we ever do have 2-state nets, "output wire bit a" would
> >require "wire" wouldn't it be more consistent to have
> >input default to var in the same manner as output?
> 
> As you say, there is no compatibility reason to require inputs to
> default to vars.  Since they are already driven by the port, they
> could not be written by either procedural assignments or continuous
> assignments within the module.
> 
> There are a number of reasons to prefer making them nets.  One of
> the major ones was port-collapsing.  Verilog users tend to rely on
> that to fix incorrectly declared port directions, and that only
> happens with nets.  In the Mantis item, I mention that legacy PLI
> is more likely to work if they are nets, which somebody apparently
> raised as an issue.  There may also have been a desire to make the
> rules simpler, rather than matching the overly complex output rules.
> 
> Steven Sharp
> sharp@cadence.com