From: Steve Meyer (sjmeyer@crl.com)
Date: Sun Jan 04 1998 - 21:36:40 PST
Below is suggestion for extending array of instances and array of
gates to work with generate. It can also be used by itself (say produced
by some net list trasnslator).
Here is an example from one of the P1364 meetings:
-----
generate
genvar i, j;
for (i=0; i<depth; i=i+1) genblock: fifo_row
for (j=0; j<width; j=j+1) genblock : bit_in_row
fifo[i].bit_in_row[j].fifo_bit_reg fbr (clk, reset, decoded_push[i],
din[i + j], fbit[i*width+j]);
end
end
endgenerate
----I think it would now be written as (is this right?):
---- generate genvar i, j;
for (i=0; i<depth; i=i+1) begin for (j=0; j<width; j=j+1) begin fifo_bit_in_row_bit_reg[i][j] #(i,j) fbr (clk, reset, decoded_push[i], din[i + j], fbit[i*width+j]); end end endgenerate -----
I think arrays of instances should be extended to be able to define an array by giving all literal instances. The Verilog simulator then finds the minimum and maximum so the array can be declared as a current (already in P1364) instance array. Missing instances would just have all unconnected port connections lists.
The above example would generate the following Veriog code assuming that the genvar values need to be passed to each instance:
---- fifo_bit_in_row_bit_reg[0][0] #(.i(0), .j(0)) ifbr (clk, reset, decoded_push[0], din[0], fbit[0]), fifo_bit_in_row_bit_reg[0][1] #(.i(0), .j(1)) ifbr (clk, reset, decoded_push[0], din[1], fbit[1]), fifo_bit_in_row_bit_reg[0][2] #(.i(0), .j(2)) ifbr (clk, reset, decoded_push[0], din[2], fbit[2]), ... fifo_bit_in_row_bit_reg[1][0] #(.i(1), .j(0)) ifbr (clk, reset, decoded_push[1], din[1], fbit[width]), fifo_bit_in_row_bit_reg[1][1] #(.i(1), .j(1)) ifbr (clk, reset, decoded_push[1], din[2], fbit[width + 1]), fifo_bit_in_row_bit_reg[1][2] #(.i(1), .j(2)) ifbr (clk, reset, decoded_push[1], din[3], fbit[width + 2]), ... fifo_bit_in_row_bit_reg[2][0] #(.i(2), .j(0)) ifbr (clk, reset, decoded_push[2], din[2], fbit[2*width]), fifo_bit_in_row_bit_reg[2][1] #(.i(2), .j(1)) ifbr (clk, reset, decoded_push[3], din[3], fbit[2*width + 1]), fifo_bit_in_row_bit_reg[1][1] #(.i(1), .j(1)) ifbr (clk, reset, decoded_push[4], din[4], fbit[2*width + 3]), fifo_bit_in_row_bit_reg[1][2] #(.i(1), .j(2)) ifbr (clk, reset, decoded_push[1], din[3], fbit[width + 2]), ... ...
----
Here some obvious errors can be check for: 1) repeated constant instance with exactly all same indices. 2) XMR (cross module reference) index outside of high and lowest constant value used among all constant indices in module.
Alternatively, instance array individual instances could be given in the instance array declaration (something like C initializers). There is probably better syntax for this alterntaive:
------ fifo_bit_in_row_bit_reg[0:depth][0:width] // notice here a list of pound parameters assignments is given for each // instance. If left out or only some parameters appear the initial // values are used as now #(.i(0),.j(0)), #(.i(0),.j(1)), #(.i(0),.i(2)) ... #(.i(1), .j(0)), #(.i(1),.j(1)), ... ifbr // the normal one instance list becomes a list of instance connection lists // again missing list elments (,, required) would produce an // instance with all port unconnected (clk, reset, decoded_push[0], din[0], fbit[0]), (clk, reset, decoded_push[0], din[1], fbit[1]), ... (clk, reset, decoded_push[1], din[1], fbit[width]), (clk, reset, decoded_push[1], din[2], fbit[width + 1]), (clk, reset, decoded_push[1], din[3], fbit[width + 2]), ... (clk, reset, decoded_push[2], din[2], fbit[2*width]), (clk, reset, decoded_push[2], din[3], fbit[2*width] + 1), (clk, reset, decoded_push[2], din[4], fbit[2*width] + 2), ... ...;
This extension has the advantage that hierarchical references can have constant expressions (maybe variable in right hand sides) to select instance. Otherwise if the instances are converted to names with number, it is much harder to select instances. ALso I think it is confusing for users to sometimes have [<number>] be part of a name and sometimes a select expression.
This new extension solves the problem with current instance arrays that in many cases neither exactly width match or replicated connections do not provide enough generality. /Steve -- Steve Meyer Phone: (415) 296-7017 Pragmatic C Software Corp. Fax: (415) 296-0946 220 Montgomery St., Suite 925 email: sjmeyer@crl.com San Francisco, CA 94104
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:52:45 PDT
and
sponsored by Boyd Technology, Inc.