Module instantiations are copies of the logic that define component interconnections in a module.
module_name instance_name (terminal1, terminal2),...; A module instantiation consists of the name of the module (module_name), followed by one or more instantiations. An instantiation consists of an instantiation name (instance_name) and a connection list. A connection list is a list of expressions called terminals, separated by commas. These terminals are connected to the ports of the instantiated module.
Terminals connected to input ports can be any arbitrary expression. Terminals connected to output and inout ports can be identifiers, single-bit or multiple-bit slices of an array, or a concatenation of these. The bit widths for a terminal and its module port must be the same.
If you use an undeclared variable as a terminal, the terminal is implicitly declared as a scalar (1-bit) wire. After the variable is implicitly declared as a wire, it can appear wherever a wire is allowed.
The following example shows the declaration for the module SEQ with two instances (SEQ_1 and SEQ_2).
module SEQ(BUS0,BUS1,OUT);//description of module SEQ
input BUS0, BUS1;
output OUT;
...
endmodule
module top(D0,D1,D2,D3,OUT0,OUT1);
input D0, D1, D2, D3;
output OUT0, OUT1;
SEQ SEQ_1(D0,D1,OUT0),//instantiations of module
SEQ
SEQ_2(.OUT(OUT1),.BUS1(D3),.BUS0(D2));
endmodule Module instantiations can use either named or positional notation to specify the terminal connections.
In name-based module instantiation, you explicitly designate which port is connected to each terminal in the list. Undesignated ports in the module are unconnected.
In position-based module instantiation, you list the terminals and specify connections to the module according to the terminal's position in the list. The first terminal in the connection list is connected to the first module port, the second terminal to the second module port, and so on. Omitted terminals indicate that the corresponding port on the module is unconnected.
In the example of module instantiations, SEQ_2 is instantiated with named notation, as follows.
SEQ_1 is instantiated by using positional notation, as follows.
With Verilog language, you can create parameterized designs by overriding parameter values in a module during instantiation.You can do this with the defparam statement or with the following syntax.
module module_name #(parameter_value,parameter_value,...)instance_name (terminal_list) Foundation Express does not support the defparam statement but does support the syntax above.
In the following example, the default value of the parameter width is 8, unless you override the value when the module is instantiated. When you change the value, you build a different version of your design. This type of design is called a parameterized design.
module foo (a,b,c);
parameter width = 8;
input [width-1:0] a,b;
output [width-1:0] c;
assign c = a & b;
endmodule Foundation Express reads parameterized designs as templates. These designs are stored in an intermediate format so that they can be built with different (nondefault) parameter values when they are instantiated.
One way to build a template into your design is by instantiating it in your Verilog code. The example below shows how to do this.
module param (a,b,c);
input [3:0] a,b;
output [3:0] c;
foo #(4) U1(a,b,c); // instantiate foo
endmodule The above example instantiates the parameterized design, foo, which has one parameter that is assigned the value 4.
Because module foo is defined outside the scope of module param, errors such as port mismatches and invalid parameter assignments are not detected until an implementation is created. When Foundation Express links module param, it searches for template foo in memory. If foo is found, it is automatically built with the specified parameters. Foundation Express checks that foo has at least one parameter and three ports, and that the bit widths of the ports in foo match the bit-widths of ports a, b, and c. If template foo is not found, the link fails, and the instance U1 is treated as a black box.
Verilog supplies a number of basic logic gates that enable modeling at the gate level. Gate-level modeling is a special case of positional notation for module instantiation that uses a set of predefined module names. Foundation Express supports the following gate types.
Connection lists for instantiations of a gate-level model use positional notation. In the connection lists for and, nand, or, nor, xor, and xnor gates, the first terminal connects to the output of the gate, and the remaining terminals connect to the inputs of the gate. You can build arbitrarily wide logic gates with as many inputs as you want.
Connection lists for buf, not, and tran gates also use positional notation. You can have as many outputs as you want, followed by only one input. Each terminal in a gate-level instantiation can be a 1-bit expression or signal.
In gate-level modeling, instance names are optional. Drive strengths and delays are allowed, but they are ignored by Foundation Express.
The following example shows gate-level instantiations.
buf (buf_out,e);
and and4(and_out,a,b,c,d); Delay options for gate primitives are parsed but ignored by Foundation Express. Because Foundation Express ignores the delay information, it can create logic whose behavior does not agree with the simulated behavior of the circuit. See the “Register and Three-State Inference” chapter for more information.
Foundation Express supports the following gate types for instantiation of three-state gates.
Connection lists for bufif and notif gates use positional notation. Specify the order of the terminals as follows.
The following example shows a three-state gate instantiation with an active high enable and no inverted output.
module three_state (in1,out1,cntrl1);
input in1,cntrl1;
output out1;
bufif1 (out1,in1,cntrl1);
endmodule 