BTF - B01 Wording - 19980714

From: Cliff Cummings (cliffc@sunburst)
Date: Tue Jul 14 1998 - 09:04:48 PDT

Next message: Clifford E. Cummings: "Configuration Proposal Comments"
Previous message: Kurt Baty: "B23_constant_function.html take 3"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

BAD MSG:
<HTML>
HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="GENERATOR" CONTENT="Mozilla/4.04 [en] (X11; I; SunOS 5.5.1 sun4m) [Netscape]">
</HEAD>
<BODY>
 - B01 - DRAFT -
 
 <IEEE 1364 Proposed Wording - 07/14/1998 - Cliff Cummings>
 
 Section 12.1.3 Generated instantiation
 
 Note from Karen: I attempted to write the paragraphs
I mentioned in the conference call. In writing them, I've become
very worried about how generate statements will propagate values and instantiations
in the context of defparams. Can we say something about that?
 
 After a Verilog design has been parsed, but at time 0
before simulation begins, the design must have the modules being instantiated
linked to the modules being defined, the parameters propagated among the
various modules and hierarchical references resolved. This phase
in understanding a Verilog description is termed elaboration.
 
 Generate blocks are resolved during elaboration because
that is when the parameters associated with a module become defined, hence,
allowing the definition of the generated statements and declarations.
Genvars are only defined during the evaluation of the generate blocks (see
section 12.1.3), and do not exist during simulation of a Verilog design.
 
 Note from Karen: Does this fit at all with what you
are doing? It seems that the elaboration language may also be useful
in your description of configurations because that is the point where a
particular module definition is chosen to repr
 esent a given instantiation.
 
 Generate statements facilitate the creation of parameterized
models. When used with constant functions (see section #), parameters can
be used to constrain other parameters in a generated design. Constant functions
can be used to calculate values of local parameters, which shall not be
modified using # or defparam statements. This permits the creation of parameterized
modules where only a minimum number of parameters are required to be passed
to a module and where the local parameters, assigned by constant functions
of other module parameters, will not cause conflicting parameters to be
accidentally passed.
 
 All generate statements are coded within a module scope
and require the keywords generate-endgenerate.
 
 Generated instantiation allows one or more modules, user
defined primitives, Verilog gate primitives, continuous assignments, initial
blocks and always blocks to be conditionally and/or multiply instantiated
into a design. Generated instances have unique identifier names and can
be referenced hierarchically as described in section #.#.
 
 To support the interconnection between structural elements
and/or procedural blocks, generate statements permit the following Verilog
data types to be declared within the generate scope: net, reg, integer,
real, time, realtime and event. Ge
 nerated data types have unique identifier names and can
be referenced hierarchically as described in section #.#.
 
 Parameter redefinition using # statements or defparam
statements can also be declared within the generate scope.
 
 Tasks and functions shall also be permitted within the
generate scope. Generated tasks and functions shall have unique identifier
names and may be referenced hierarchically as described in section #.#;
however, automatic (recursively genera
 ted) tasks and functions shall not be hierarchically
referenced.
 
 Module declarations and module items that shall not be
permitted in a generate statement include: parameters, local parameters,
input declarations, output declarations, inout declarations and specify
blocks.
 
 Connections to generated module instances are handled
the same way as they are handled with normal module instances as described
in section 12.1.2.
 
 Generated structures are created using one of the following
three methods: generate-loop, generate-conditional or generate-case.
 
 Section 12.1.3.1 Genvar - Generate statement index
variable
Content-Length: 14904
X-Lines: 260
X-Status: $$$$
X-UID: 0000000547
Status: RO

An index variable that shall only be declared for use
in generate statements shall be declared as a genvar and is referred to
as a genvar in the rest of this section.
 
 A genvar shall be declared within the module where the
genvar is used. A genvar can be declared either inside or outside of a
generate scope. A genvar is a positive integer that is local to and shall
only be used within a generate scope.
 
 Genvars are only defined during the evaluation of the
generate blocks (see section 12.1.3), and do not exist during simulation
of a Verilog design.
 
 It is illegal for any generate statement to modify the
genvar of another generate statement, including nested and outer generate
statements. A genvar that is referenced within a generate loop shall only
be tested using if statements and cas
 e statements.
 
 Section 12.1.3.2 Generate-loop
 
 A generate-loop permits one or more defined modules,
user defined primitives and/or Verilog gate primitives to be instantiated
multiple times using an indexed for-loop. The index loop-variable used
in a generate for-loop shall be declared as a genvar.

A parameterized gray-code to binary-code converter module
using a loop to generate continuous assignments is shown in example ##.
 
 <TT> module gray2bin1 (bin, gray);</TT>
 <TT> parameter SIZE = 8;
// this module is parameterizable</TT>
 <TT> output [SIZE-1:0] bin;</TT>
 <TT> input [SIZE-1:0] gray;</TT>
 <TT> </TT>
 <TT> genvar i;</TT>
 <TT> </TT>
 <TT> generate for (i=0; i<SIZE;
i=i+1)</TT>
 <TT> assign bin[i] = ^gray[SIZE-1:i];</TT>
 <TT> endgenerate</TT>
 <TT> endmodule</TT>
 
 The same gray-code to binary-code converter module in
example ##<above> is built using a loop to generate always blocks as
shown in example ##.
 
 <TT> module gray2bin2 (bin, gray);</TT>
 <TT> parameter SIZE = 8;
// this module is parameterizable</TT>
 <TT> output [SIZE-1:0] bin;</TT>
 <TT> input [SIZE-1:0] gray;</TT>
 <TT> reg [SIZE-1:0]
bin;</TT>
 <TT> </TT>
 <TT> genvar i;</TT>
 <TT> </TT>
 <TT> generate for (i=0; i<SIZE;
i=i+1)</TT>
 <TT> always @(gray[SIZE-1:i])
// fixed part select</TT>
 <TT> bin[i]
= ^gray[SIZE-1:i];</TT>
 <TT> endgenerate</TT>
 <TT> endmodule</TT>
 
 The models in examples ## and ## are parameterized modules
of ripple adders using a loop to generate Verilog gate primitives. Example
## uses a two dimensional net declaration outside of the module to make
the connections between the gate primitives while example ## makes the
net declaration inside of the generate loop to generate the wires needed
connect the gate primitives for each iteration of the loop.

Example ## - Generated ripple adder with two-dimensional
net declaration outside of the generate loop.
 
 <TT>module addergen1 (co, sum, a, b, ci);</TT>
 <TT> parameter SIZE = 4;</TT>
 <TT> output [SIZE-1:0] sum;</TT>
 <TT> output
co;</TT>
 <TT> input [SIZE-1:0] a, b;</TT>
 <TT> input
ci;</TT>
 <TT> wire [SIZE :0] c;</TT>
 <TT> wire [SIZE-1:0] t [1:3];</TT>
 <TT> genvar
i, j;</TT>
 <TT> </TT>
 <TT> assign c[0] = ci;</TT>
 <TT> </TT>
 <TT> // Generated instance names are:</TT>
 <TT> // xor gates: g1[0]-g1[3], g2[0]-g2[3]</TT>
 <TT> // and gates: g3[0]-g3[3], g4[0]-g4[3]</TT>
 <TT> // or gates: g5[0]-g5[3]</TT>
 <TT> // Generated instances are connected with</TT>
 <TT> // multi-dimensional nets t[0][1]-t[3][3]</TT>
 <TT> // (12 multi-dimensional nets total)</TT>
 <TT> generate</TT>
 <TT> for(i=0; i<SIZE; i=i+1) begin</TT>
 <TT> xor g1 ( t[1][i],
a[i], b[i]);</TT>
 <TT> xor g2 ( sum[i],
t[1][i], c[i]);</TT>
 <TT> and g3 ( t[2][i],
a[i], b[i]);</TT>
 <TT> and g4 ( t[3][i],
t[1][i], c[i]);</TT>
 <TT> or g5 (
c[i+1], t[2][i], t[3][i]);</TT>
 <TT> end</TT>
 <TT> endgenerate</TT>
 <TT> </TT>
 <TT> assign co = c[4];</TT>
 <TT>endmodule</TT>
 
 Example ## - Generated ripple adder with net declaration
inside of the generate loop.
 
 <TT>module addergen1 (co, sum, a, b, ci);</TT>
 <TT> parameter SIZE = 4;</TT>
 <TT> output [SIZE-1:0] sum;</TT>
 <TT> output
co;</TT>
 <TT> input [SIZE-1:0] a, b;</TT>
 <TT> input
ci;</TT>
 <TT> wire [SIZE :0] c;</TT>
 <TT> </TT>
 <TT> genvar
i, j;</TT>
 <TT> </TT>
 <TT> assign c[0] = ci;</TT>
 <TT> </TT>
 <TT> // Generated instance names are:</TT>
 <TT> // xor gates: g1[0]-g1[3], g2[0]-g2[3]</TT>
 <TT> // and gates: g3[0]-g3[3], g4[0]-g4[3]</TT>
 <TT> // or gates: g5[0]-g5[3]</TT>
 <TT> // Generated instances are connected</TT>
 <TT> // with generated nets: t1[0]-t1[3],</TT>
 <TT> // t2[0]-t2[3], t3[0]-t3[3]</TT>
 <TT> generate</TT>
 <TT> for(i=0; i<SIZE; i=i+1) begin</TT>
 <TT> wire t1,
t2, t3; // generated net declaration</TT>
 <TT> </TT>
 <TT> xor g1 (
t1, a[i], b[i]);</TT>
 <TT> xor g2 ( sum[i],
t1, c[i]);</TT>
 <TT> and g3 (
t2, a[i], b[i]);</TT>
 <TT> and g4 (
t3, t1, c[i]);</TT>
 <TT> or g5 ( c[i+1],
t2, t3);</TT>
 <TT> end</TT>
 <TT> endgenerate</TT>
 <TT> </TT>
 <TT> assign co = c[4];</TT>
 <TT>endmodule</TT>
 
 
 Section 12.1.3.3 Generate-conditional
 
 A generate-conditional is an if-else-if generate construct
that permits one or more defined modules, user defined primitives and/or
Verilog gate primitives to be conditionally instantiated into another module
based on an expression that is
 deterministic at the time the design is compiled.
 
 Example ## shows the implementation of a parameterized
module. If the multiplier WIDTH parameter is less than or equal to 16 (bits),
a <type> multiplier is instantiated. If the multiplier WIDTH parameter
is greater than 16 (bits), a Wallace
 tree multiplier is instantiated.
 
 <multiplier code>
 
 Section 12.1.3.4 Generate-case
 
 A generate case construct permits one or more defined
modules, user defined primitives and/or Verilog gate primitives to be conditionally
instantiated into another module based on a select one-of-many case construct.
The selecting case expr
 ession must be a run-time constant.
 
 Example:
 
 <TT>generate</TT>
 <TT> case (WIDTH)</TT>
 <TT> 1: adder_1bit (co, sum,
a, b, ci); // 1-bit adder implementation</TT>
 <TT> 2: adder_2bit (co, sum,
a, b, ci); // 2-bit adder implementation</TT>
 <TT> default: adder_cla (co, sum, a,
b, ci); // others - carry look-ahead adder</TT>
 <TT> endcase</TT>
 <TT>endgenerate</TT>
 
 
 B01 Notes:
 
 nested "generate" for-loops
 
 Proposal: generate
- endgenerate can only exist at the module scope - pass 5-2-1 (opposing
- no new keywords should be introduced)
 
 Proposal: genvar
- for the generate for-loop: a generate-loop index variable should be declared
- pass 6-0-2
 
 Proposal: new keyword
genvar required - pass 6-1-1 (opposing - no new keywords should be introduced)
 
 Proposal: genvar
is local to (may only be used within) the generate-scope- pass 7-0-0
 
 Proposal: genvar
shall be declared within the module, either inside or outside of the generate-loop,
and its scope is the scope of the module. Proposed by Kurt Baty - 2nd by
Mike McNamara - pass 7-0-0
 
 Proposal: case may
test against an expression made up of constants and/or genvars - Proposed
by Mike McNamara - 2nd Kurt Baty - pass 7-0-0
 
 Proposal: if-then-else
may test against an expression made up of constants and/or genvars - Proposed
by Mike McNamara - 2nd Kurt Baty - pass 7-0-0
 
 Proposal: Multiple
square brackets are allowed in the instance hierarchical reference, the
bracketed values are constant expressions and can optionally be followed
with a period and another hierarchical reference. Proposed by Kurt Baty
- 2nd by Anders Nordstrom - pass 7-0-0
 
 
 Note : must avoid name collision
 Note : would require ACC routines (PLI)
 Note : genvar index would be part of the instance reference
 Note : will not use variables in the genvar
 Note : PLI - would like to see more about parameter overiding
in the proposal - down-bound parameter
 Note : Give full intent of the enhancement in the beginning
(ie - include intent to include constant_functions)
 Note : Where are negative values allowed???
 Note : module_item_declaration should not include I/O
 Note : nested for-loops should not mess with each other's
index variable

Note : genvars can only be tested in if's and case's
when nested in the for-loop
 Note : reg (good), parameter (bad?)
 
</BODY>
</HTML>

Next message: Clifford E. Cummings: "Configuration Proposal Comments"
Previous message: Kurt Baty: "B23_constant_function.html take 3"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

This archive was generated by hypermail 2.1.4 : Mon Jul 08 2002 - 12:52:57 PDT and
sponsored by Boyd Technology, Inc.