Date: Mon Oct 30 2006 - 05:56:52 PST
This is an initial proposal to allow specification of default input values for module/interface/program ports ("module ports" for short). It is intended as a basis for discussion. The exact wording of the text and the exact way to put it in the BNF could be refined later. By the way, this is unconnected to Dmitry's work. This was requested by a senior member of a team writing a major project design in SV. But I can also personally testify how useful this would be. The primary motivation for this is that very often you have input ports which are only sometimes used. When not used, you do not want to leave them unconnected, because then they float to x or z. Instead you typically connect them to a fixed value, 0 or 1. A data input can be connected to either 0 or 1, whereas a control input will be connected to its inactive state value. It also happens too often that by mistake, an unused port is connected to the wrong value, such as a port which has the opposite polarity from what you think. Defaults would help there also. However, it is sometimes annoying to have to add these connections to the unused inputs. They make the module instantiation code longer and less readable. It is sometimes convenient to have built-in defaults for unused connections. They could be thought of as similar to internal pull-ups or pull-downs, which determine the input value only if the input is not driven by another source. Note that some tools, at least in some modes, automatically connect unused inputs to 0. The simplest would be to allow these defaults only for inputs, with the default value being a constant expression. However, this could be extended to non-constant expressions and/or to inout and ref ports as well, as in tasks and functions. Tasks and functions currently do not have .name or .* implicit connections. The following question then arises for module ports: what to do if a port has a default defined, .name or .* is used, and a corresponding net/variable with the same name does not exist. If .name is used, then on the one hand, one can say, since the user explicitly wrote the port name, which is a shortcut for .name(name), then the default should not be used, and an error should be generated. On the other hand, one can say that he writes .name to document the existence of the port. I feel that an error should be generated in this case. However, the argument for this is not as strong in the case of .*. One can argue that one should not have to list all the other ports explicitly just in order to be able to use defaults. If a port is explicitly unconnected, as in .name(), then the default should not be used. The same feature for module ports should be defined for interface and program ports as well. See footnote 25 to the BNF: "The list_of_port_declarations syntax is explained in 19.8, which also imposes various semantic restrictions, e.g., a ref port must be of a variable type and an inout port must not be. It shall be illegal to initialize a port that is not a variable output port." That last sentence may need to change. In this proposal, a similar syntax to variable declaration assignments would be used, which could be confusing. For a variable output port, it would be an initialization. For an input, it would be a default value. Could we define default port values for unpacked aggregates? Task/function default values are allowed only for singlular values. Mantis 1344 deals with defaults for unpacked arguments for task/functions. The text for task/function argument default values reads as follows: 12.4.3 Default argument values To handle common cases or allow for unused arguments, SystemVerilog allows a subroutine declaration to specify a default value for each singular argument. The syntax to declare a default argument in a subroutine is as follows: subroutine( [ direction ] [ type ] argument = default_value ); The optional direction can be input, inout, or ref (output ports cannot specify defaults). The default_value is an expression. The expression is evaluated in the scope containing the subroutine declaration each time a call using the default is made. If the default_value is not used, the expression is not evaluated. The use of default values shall only be allowed with the ANSI style declarations. When the subroutine is called, arguments with default values can be omitted from the call, and the compiler shall insert their corresponding values. Unspecified (or empty) arguments can be used as placeholders for default arguments, allowing the use of nonconsecutive default arguments. If an unspecified argument is used for an argument that does not have a default value, a compiler error shall be issued. Based on that wording, a similar wording for module ports could go something like: 19.8.1 Default port values To handle common cases or allow for unused ports, SystemVerilog allows an input declaration to specify a default value for each singular port. The syntax to declare a default port value in a module is as follows: module( [ input ] [ type ] port_identifier = constant_expression ); Defaults can be specified only for input ports. The use of default values shall only be allowed with the ANSI style declarations. When the module is instantiated, ports with default values can be omitted from the instantiation, and the compiler shall insert their corresponding values. Unspecified (or empty) port connections can be used as placeholders for default arguments, allowing the use of nonconsecutive default values. If a value is not specified is used for a port that does not have a default value, the port shall be left unconnected. 19.11.1 Instantiation using positional port connections Add: When using positional port connections, if a port connection is omitted (such as at the end of a port connection list or between two consecutive commas) to an input port with a specified default value, the default value shall be used. 19.11.2 Instantiation using named port connections Add: If an input port with a specified default value has an explicit empty named port connection(i.e., .port_identifier()), then the port shall be left unconnected and the default value shall not be used. 19.11.3 Instantiation using implicit .name port connections Replace: The port connection shall not create an implicit wire declaration. With: If a signal of the same name does not exist in the instantiating module, the port connection shall not create an implicit wire declaration and an error shall be issued, even if the port has a specified default value. 19.11.4 Instantiation using implicit .* port connections After: An implicit .* port connection is semantically equivalent to a default .name port connection for every port declared in the instantiated module with the exception that .* does not create a sufficient reference for a wildcard import of a name from a package. Add: Another exception is that for an input port with a specified default value, if a signal of the same name does not exist in the instantiating module, the default value shall be used, and an error shall not be issued. Syntax 19-4 and A.2.1.2: input_declaration ::= input net_port_type list_of_input_port_identifiers | input variable_port_type list_of_input_variable_identifiers list_of_input_port_identifiers ::= port_identifier { unpacked_dimension } [ = constant_expression ] { , port_identifier { unpacked_dimension } [ = constant_expression ]} list_of_input_variable_identifiers ::= variable_identifier { variable_dimension } [ = constant_expression ] { , variable_identifier { variable_dimension } [ = constant_expression ]} Shalom Bresticker Intel Jerusalem LAD DA +972 2 589-6852 +972 54 721-1033 I don't represent Intel
