Port Declaration Issues ======================= Mantis 2273: A number of constructs have ports or arguments: modules, interfaces, programs (ANSI header is list_of_port_declarations) tasks, functions (tf_port_list) covergroup (tf_port_list) randsequence production (tf_port_list) UDP (ANSI header has udp_declaration_port_list) properties (property_port_list) sequences (sequence_port_list) let (let_port_list) checkers (checker_port_list) Each port has some or all of the following characteristics or attributes, explicitly or implicitly declared: "kind" - net, variable, interface, or something else (e.g., sequence) (if a net, net kind) data type (or untyped) unpacked array dimensions (optional) direction (input, output, inout, ref) (or none) default value I deliberately listed unpacked array dimensions separately from the rest of the data type. There are places where it is treated differently. It appears to be more or less clear what types of ports are legal for each construct, but some things are unspecified. For example, some characteristics can be omitted in some cases. For example, whether a port is a net, variable, or something else. In such cases, there are defaults. The defaults differ between constructs. (Example: module port direction default is inout. For tasks/functions, it is input) For examples, module ports default to nets in some cases. However task ports cannot be nets or interfaces and are variables. These defaults are not explicitly specified in all cases. Within a certain construct, the defaults can also change depending on the case. For example, in a module, sometimes a port defaults to a net and sometimes to a variable. Some characteristics are in some cases inherited from preceding port declarations, if not explicitly specified. So the LRM needs to clarify for each of these constructs 1. what combinations of characteristics are legal for ports of that construct. For the most part, that already exists. But I don't think it actually says anywhere that interfaces and programs have the same rules as modules, for example. 2. what are the defaults for each characteristic if not explicitly specified, when a characteristic can be omitted. In some cases, defaults can vary depending on the case. 3. when and which characteristics are inherited from the previous declaration, and when you have to declare the port fully because you inherit nothing. For example, does "var" in a port declaration cancel all inheritance? Or inheritance rules for signedness. The default and inheritance rules need to be unambiguous. For example, the statement "if the data type is not explicitly declared" - what precisely is considered explicit declaration of data type? Again, need to verify whether there are any differences betweeen constructs or exceptions. Inheritance rules for default values. If default values are not inherited, this needs to be stated explicitly. 0002889: .named_port(expression) in ANSI-style port declaration list should reset properties 0002395: Incorrect note attached to net_port_type production == Non-ANSI style port declarations: what is allowed, what is not, what are inheritance rules between ports in a list - subset of ANSI port rules - Inheritance rules are relevant to internal net and variable declarations as well and should be clarified. (unpacked array dimensions are inherited, unpacked dimensions are not) The packed dimensions are part of the data type being declared. So is signing, parameter values, delays Are there other inheritance rules? Parameter declartions have special rules. Untyped parameters get type of assignment RHS. 7.4.5 (in SV-2005?) said, "A comma-separated list of array declarations can be specified. All arrays in the list shall have the same data type and the same packed array dimensions. bit [7:0] [31:0] foo7 [1:5] [1:10], foo8 [0:255]; // two arrays declared " Note again the ambiguous use of "data type". - Non-ANSI port declarations are ambiguous about splitting them into 2 or 3 parts: Is the following a legal port declaration? input [5:0] in; bit [5:0] in; or must they be combined? input var bit [5:0] in; Also, is the following a legal port declaration? typedef logic [1:5] T; input [1:10] in; T [1:10] in; // 1 to 5 varies most rapidly or must they be combined? input T [1:10] in; There were great arguments about this. This will be very hard to resolve in a mutually agreed way. Probably we can only hope to agree on a few basic principles, but not the full detail spec. See Mantis 2593. - Non-ANSI: Mantis 1104: may net/reg declaration precede port declaration? 0002929: ref_declaration should use list_of_variable_port_identifiers - Defaults probably need to be clarified also. Example: "input p;" means "input wire logic p;" == Modport declaration port list rules == Rules for untyped ports == Interface ports: allowed for modules/programs/interfaces types: - - . - "interface" (generic interface) Need to add these to rules for module ports etc. Note: generic interface ports are not allowed for non-ANSI style declarations. Interface ports are not allowed for any other constructs? 0002512: search rules for type vs interface Mantis 905: Unlike class specializations, interface specializations cannot be used in a module port declaration. For example, the following is disallowed: module m #(parameter N=16) (IFC#(N) ifc, input [N-1:0] in); Mantis 2502: Cannot use parameterized interface in port declaration 0002573: allow parameter selected from an interface port to be a constant expression. Thus is not really a port issue. == The question has arisen several times what happens if a default causes an illegal combination. An example is in a module port list: module m(input int x); The default port kind for inputs is a net. But nets are not allowed to have 2-state data types like int. Some people think that in such a case, it becomes a var instead of a net, but the LRM does not say or even imply that. It is really illegal. Since there have been questions and misinterpretations, the LRM should be explicit. Dave Rich: I think it was a mistake to have x default to a wire. I would like to change it back to default to a var. The only visible difference is with forces. Is the problem of defaults causing an illegal combination limited to module/program/interface inputs, or elsewhere also? == Steven Sharp pointed out in http://www.eda-stds.org/sv-bc/hm/9410.html that the 1800-2009 version still does not adequately deal with ports with data types that are typedefs. These can have unpacked dimensions, for example. == - The current rules do not adequately cover explicitly named ports .p(q) - Mantis 1073: Is module m(.p(p)) legal? - Mantis 1163: Clarify "Once a port has been defined, there shall not be another port definition with this same name" - Mantis 1572: 23.2.2.2 says near the end, "The port expression shall resolve to a legal expression for type of module port (see 23.3.3)." - unclear 0002889: .named_port(expression) in ANSI-style port declaration list should reset properties == - Mantis 1169 poses a whole list of questions about various t/f argument declaration forms (mostly from Daniel Mlynek). Some of these are probably applicable to modules also. There are differences between tools on some of these cases. == - Mantis 1170 wants to clarify redeclaration of ANSI ports in the module body. This looks minor and very simple. However, it might be relevant to Mantis 1169. == Extern module headers - Manits 1469 proposes to disallow non-ANSI extern module headers - Mantis 1506: BNF allows extern interface/program/UDP, but this is not mentioned in text 0002392: Extern module parameter and port lists, especially in context of recent enhancements - use of .* issue -matching of defaults and initializers == - Mantis 1501: clarify definition of implicit declaration in port expressions This appears to be more of making the text clearer than any technical question == 1573, 1744: port coercion issues. Probably better not to touch these. Maybe just the legality of writing to an input or using an output as an input.