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

This is intended to be a declarations of principles on non-ANSI style port declarations. Not an actual proposal, but the basis for a proposal. It is intended to make explicit the assumptions that have been used in this discussion and present them in an orderly way. 

Some of the prinicples are based on a restrictive interpetation, which I favor, not on Brad's looser suggestion. But even people who favor looser interpretations should benefit from this presentation.

Non-ANSI port declarations:

- Have a port direction(see below), port kind(net/var), port data type(possibly including signedness, packed array ranges, unpacked array ranges, among other things), and of course a port name


- Direction: input, output, inout, ref, or interface type. Generic interface non-ANSI port declarations are not allowed. Some of the rest of this discussion does not apply to interface ports and may not apply to ref ports(?).


- Under certain conditions, such a port declaration may be followed by a data object declaration of the same name, that may add but not change explicitly defined attributes from the port declaration. Specifically, an input, output, or inout port declaration (but not interface. what about ref?) may be followed by a data object declaration if the port declaration does not explicitly specify the port kind or data type or at most specifies the signedness and/or packed array ranges (implicit_data_type BNF construct). If packed array ranges are specified in the port declaration, the data object declaration may not omit the packed array ranges or specify different ranges.

(Note: this allows separate/duplicate declarations only if the port declaration does not include an explicit data type. I based this partly on the following behavior: I checked the following case on 3 simulators:

module test(out1);

output integer out1;
integer out1;

endmodule

Of the 3 simulators, 2 issued a compilation error, and the 3rd issued a warning of duplicate declarations of the name and it is ignoring the 2nd.

The wording I wrote above implicitly allows the Mantis 1111 case without being explicit about it.)


- 23.2.2.1 says, "If a port declaration includes a net or variable type, then the port is considered completely declared, and it is an error for the port to be declared again in a variable or net data type declaration. Because of this, all other aspects of the port shall be declared in such a port declaration, including the signed and range definitions if needed."
  
This was pretty good for 1364, but in 1800, the phrase "net or variable type" is more ambiguous. Does it mean the port kind or data type or either or both? For example, "output integer out1;" in 1364 implicitly specifies out1 as a variable and most tools don't allow an additional, separate "integer out1" declaration for it. On the other hand, if this were defined to mean port kind only, then it would be more consistent with the fact that the port declaration can specify signedness and/or range and still have an additional declaration. So my interpretation of that sentence is that it refers to port kind, but it needs to be reworded to match 1800 terminology.


- If the port declaration does not explicitly specify the port kind:

  - input  port declarations implicitly specify the port kind as net (default net type) unless explicitly specified otherwise in a following data object declaration
  - output port declarations implicitly specify the port kind as specified in 23.2.2.3 (as in ANSI declarations) unless explicitly specified otherwise in a following data object declaration
  - inout  port declarations implicitly specify the port kind as net. Inout ports must be nets.
  - ref    port declarations implicitly specify the port kind as variable. Ref ports must be variables.
  - interface ports are interfaces (surprise!)

- If the port declaration (except interface) does not specify an explicit data type (i.e., either no data type or implicit_data_type BNF construct), then it implicitly specifies data type as logic. This cannot be overriden in a subsequent data object declaration.

- (The problem with an interface port declaration is that it is not explicit that it is an interface. One needs to conclude this by process of elimination.)

- (Personally, I would like to minimize the possibilities of differences between a port declaration and a data object declaration.)

- The following also needs to change: "Nets connected to ports without an explicit net declaration shall be considered unsigned, unless the port is declared as signed," because there can be nets that have a signed data type, such as integer.

- Does anyone know what this means? 
  "Using the non-ANSI header style with a port list followed by separate declarations for each port allows flexibility on the internal data to be passed through ports."

- Steven pointed out in Mantis 2395 that BNF footnote 15:
"15) When a net_port_type contains a data_type, it shall only be legal to omit the explicit net_type when declaring an inout port,"
is incorrect. I think it needs to be corrected as part of the response to this ballot comment, because it is a normative statement affecting the allowed syntax for non-ANSI port declarations (and ANSI-style declarations also, by the way). I think the note can simply be deleted. I think it is redundant. All the necessary semantic information is in the LRM text.

Hope this helps.

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