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

>From: Gordon Vreugdenhil <gordonv@model.com>

>Sect. 19.8 is (mostly) clear on what the rules are for determining
>net/var port kinds in the absence of an explicit designation.
>For inputs though, I am not sure that things are stated correctly.

This went through considerable discussion before being finalized.
See Mantis item 578 for some of the discussion.  The issues that
you are raising were not simply overlooked, and the wording that
is there is deliberate.


>The statement is:
>    For input and inout ports, if the port kind is omitted, then
>    the port shall default to a net of net type wire.
>
>Note that this doesn't mention anything about the data_type as
>is done for output.

One of the proposals I made toward the end did mention the data type
for inputs.  That proposal was rejected in favor of the final version
that got approved.


>This implies (I think) the following:
>    1)  module m (input bit a);
>        This would be illegal since we can't have 2-state nets

This issue was mentioned a lot during the discussion, but the
final version was approved this way anyway.

>    2)  module m (input logic a);
>        This is legal and "a" would be a net.
>
>For outputs the situation is that:
>    1) module m (output bit a);
>       means that "a" is a var port of type bit.
>    2) module m (output logic a);
>       means that "a" is a var port of type logic.
>
>Is that correct?
>
>The implication is that one must have "input var logic a"
>for an input var port and must have "output wire logic a"
>for an output net port.
>
>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