|
|
|
|
|
Module instantiations are copies of the logic in a module that define component interconnections.
module_name instance_name1 (terminal, terminal, ...),
instance_name2 (terminal, terminal, ...);
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. Module instantiations have the following syntax.
(terminal1, terminal2, ...),
(terminal1, terminal2, ...);
Terminals connected to input ports can be any arbitrary expression. Terminals connected to output and inout ports can be identifiers, single- 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 each 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.
The module in the following example contains a parameter declaration. 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 automatically manages templates and parameters. Some errors due to parameter or port size mismatch are detected when an implementation is created, not when the Verilog is read.
Verilog provides several 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 Foundation Express ignores them.
The following example shows two gate-level instantiations.
buf (buf_out,e);
and and4(and_out,a,b,c,d);
Note: Foundation Express parses but ignores delay options for gate primitives. 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 “Inferring D Flip-Flops” section of 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