I made some syntax mistakes on my first mail regarding this action item. Resending now with corrections. Thanks Shalom for catching these. Actually, I was hoping someone else eyes would parse this too. I think we are safe now passing this along to designers for feedback. Remember, we are requesting from them feedback on our distinction between .name and .* for default port values. If I use .name without brackets but I do not have a matching identifier in the parent, an error is issued. This is not the case for .*, where the default port value will be used if no identifier exists in the parent. Corrected mail: So as per my action item from yesterday's sv-bc meeting I am sending out some example usage scenarios WRT to default ports. Specifically dealing with distinctions between connections using .* and .name methods. (I hope I got all the syntax right below:') Please poll your designers and give the sv-bc feedback on whether this usage makes the most sense. Currently here are the clause updates that are being proposed: 22.3.2.3 Connecting module instance using implicit named port connections (.name) SystemVerilog can implicitly instantiate ports using a .name syntax if the instance port name matches the connecting port name and their data types are equivalent. This eliminates the requirement to list an identifier name twice when the port name and expression name are the same, while still listing all of the ports of the instantiated module for documentation purposes. 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. The purpose of using default values is to hook up otherwise unconnected input ports. If .name is used it is assumed that the coder's intent is to connect this port value and not use the default value. 22.3.2.4 Connecting module instances using wildcard named port connections ( .*) ... Current wording in Draft4: An implicit .* port connection is semantically equivalent to a default an implicit .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. A named port connection can be mixed with a .* connection to override a port connection to a different expression or to leave a port unconnected. A named or implicit .name connection can be mixed with a .* connection to create a sufficient reference for a wildcard import of a name from a package. Proposed Change: An implicit .* port connection is semantically equivalent to an implicit .name port connection for every port declared in the instantiated module with two exceptions. First, if an instantiation uses a .name port connection, it is assumed that the intent is to connect the port, and therefore any default value assigned to that port is not used. In this case, if no connection is made and a default value exists, an error will still occur. However, if .* is used and no port connection is found but the declaration has a default value, the default value will be used,.the intent being that if default values are specified, they should be used if no connection exists. In this case if an unconnected port is truly needed for a specific instantiation, then .name() can be used in addition to .*. The second exception is that .* does not create a sufficient reference for a wildcard import of a name from a package. A named port connection can be mixed with a .* connection to override a port connection to a different expression or to leave a port unconnected. A named or implicit .name connection can be mixed with a .* connection to create a sufficient reference for a wildcard import of a name from a package. Here are the examples to run by your designer: In the following example I am using the .name connection method. datain, din, and rst_n have default values assigned in the declaration. module accum ( output reg [7:0] dataout0, input [7:0] datain = 8'hFF, input clk, rst_n = 1'b1); // RTL code for the accumulator module endmodule module xtend ( output reg [7:0] dout0, input [7:0] din = 4'hF, input clk, rst_n = 1'b1); // RTL code for the sign-extension module endmodule module alu_accum1 ( output [15:0] dataout0, output [7:0] dout0, input [7:0] datain, input clk, rst_n); accum accum0 (.dataout0, .datain, .clk, .rst_n); // All child and parent port names match thus the connection is made accum accum1 (.dataout0, .clk); // Missing arguments for datain and rst_n result in default values xtend xtend0 (.dout0, .clk, .rst_n); // din is a missing argument therefore the default is used. This is true regardless // of whether the parent has din or not. xtend xtend1 (.dout0, .din, .clk, .rst_n); // din is not in the parent/instantiation module but it explicitly used as // an intended connection. An error will result. endmodule In the previous example for xtend0 we see that the coder has a default value set up for din and they left the argument in the instantiation empty. The intention is that the default is to be used. In the xtend1 example, the coder explicitly lists the argument and therefore intends for the connection to happen. In this case, since din does not exist at the instantiation level, an error is produced. The following example now show the same scenarios for use of the implicit .* port connection method. module accum ( output reg [7:0] dataout0, input [7:0] datain = 8'hFF, input clk, rst_n = 1'b1); // RTL code for the accumulator module endmodule module xtend ( output reg [7:0] dout0, input [7:0] din = 4'hF, input clk, rst_n = 1'b1); // RTL code for the sign-extension module endmodule module alu_accum1 ( output [15:0] dataout0, output [7:0] dout0, input [7:0] datain, input clk, rst_n); accum accum0 (.*); // All child and parent port names match thus the connections are made xtend xtend0 (.*); // din is not in the parent/instantiation module therefore gets the default port connection endmodule For the accum0 instantiation, because all the ports names match in both the parent and child the port connections are made. In the xtend0 example, the parent is missing the din port therefore the default value is used. The distinction that must be clear between the .name and .* connection methods above is .* no longer assumes an expanded list of all the .name's for default connections. If this were the case the last xtend0 .* example would issue an error because din was not in the parent. From a designers perspective we want to use .* and assume that any default port connections will be implied. When we use .name explicitly the implication should be that we are explicitly connecting that port. Therefore in that case, if the parent does not have the connecting port, and error is issued. Designers should be aware of the dangers when using .* with default port connections. If they have a default port value _and_ intended to have a connecting port in the parent and mistakenly left it out, they will not find out about this mistake until they debug their code. -Tom -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Tue Oct 23 12:29:38 2007
This archive was generated by hypermail 2.1.8 : Tue Oct 23 2007 - 12:30:24 PDT