[sv-bc] Need Designer Feedback on Default Module Port Usage

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 and equivalent type match the connecting
declaration port name and type. 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 ( .*)

...

An implicit .* port connection is semantically equivalent to a default
.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, dataout1,

   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, dout1,

   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, dataout1,

   output [7:0] dout0, dout1,

   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 (.dataout1,, .clk, );               // Missing arguments
for datain and rst_n result in default values

   xtend xtend0 (.dout0,, .clk, .rst_n);            // din is not in the
parent/instantiation module _and_ is a missing argument

                                                    // therefore the
default is used.

   xtend xtend1 (.dout1, .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.