RE: Mantis 2593 about non-ANSI port declarations (Was: [sv-bc] Mantis 1111, omitting range on port declaration)

Another option would be to say that if there is both a port declaration and a net/variable declaration for the same name, then all type/kind information in the port declaration shall be ignored.  Type/kind information has no business in a port declaration, if the signals it's making available to the outside world are declared elsewhere in the module.

module test(in, out);

      input in;
      output out;

      wire T in;
      var T out;

      ...
endmodule

-- Brad


-----Original Message-----
From: Bresticker, Shalom [mailto:shalom.bresticker@intel.com]
Sent: Tuesday, April 28, 2009 11:15 AM
To: Gordon Vreugdenhil; Brad Pierce
Cc: sv-bc@eda.org
Subject: RE: Mantis 2593 about non-ANSI port declarations (Was: [sv-bc] Mantis 1111, omitting range on port declaration)

This mail repeats some of Steven's last mail.
I started writing it before receiving Steven's mail, and his mail arrived in the middle of my composing it.
But I send it anyway.

I question Gord's reasoning.
I don't think the "input in1" declaration necessarily implies a kind (net or variable).

For example, "output out1" could be followed by either "wire out1" or "reg out1".

This contrasts with ANSI-style declarations, which cannot be followed by an additional declaration.

In fact, the preceding sentence in the LRM says,
"If a port declaration does not include a net or variable type, then the port can be again declared in a net or variable declaration."

I think the proposed wording,
"Aside from the signed attribute mentioned below, the data type between the two declarations of a port shall be identical."
is more ambiguous than the current wording because it is not clear what is meant by "data type" here.
That is a term used ambiguously throughout the LRM.
That is why in 23.2.2.3, I had to specify what is meant by "data type" there:
"Within this subclause, the term data type means both explicit and implicit data type declarations and does not include unpacked dimensions."

Also, the reason that 1111 never passed was to allow "input in1" to be followed by "wire [5:0] in1" for back-compatibility.
The proposed wording might disallow that.


> "in1" is illegal since the resulting type of "bit" is not legal for a net;
> "in1" is implicitly a net type since "var" is not specified and it is an input.

>>     input [5:0] in1;
>>     bit [5:0] in1;

Shalom
---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.