From: mac@silicon-sorcery.com
Date: Fri Oct 31 1997 - 09:07:47 PST
I was contacted by Dan FitzPatrick, a member of the
Verilog-AMS group; it seems they have a gnerate as well, and he wanted
some info on what we were up to.
I forwarded him some information, and he has come back with
some questions; I forward them to the group. Also I invited him to
our next 1364 meeting.
Kurt, perhaps you could take the lead in answering his
questions.
Dan FitzPatrick writes:
> hi mac,
>
> thanks for the information regarding the next 1364 meeting. unless
> something comes up, i plan to be there.
>
> just a little feedback and questions regarding the generate - if
> necessary could you forward to kurt.
>
> here is the background: in the OVI Verilog-A spec (from last year)
> there is a 'generate' statement to deal with the representation of
> behaviors consisting of composite (array/buss) analog signals.
> traditionally, these are not done in analog hdls due to the complexity -
> remember what the designer describes ultimately translates into systems
> of differential equations that are solved numerically, not with an
> event propagation mechanisms.
>
> the verilog-a generate goes something like this:
>
> analog begin
> generate i (0, 7, 1) begin
> I(out[j]) <+ ddt(capval*V(in[j]));
> end
> end
>
> where 'out' and 'in' are busses/arrays of electrical signals of the
> appropriate size. the idea is to provide a language mechanism for
> expanding analog behavioral code iteratively. the necessity arises
> because to do this for analog, the number of 'iterations' through
> the code/statement must be simulation-static in order to map into
> a consistent and constant number of differential equations.
>
> so the problems with the current version (not inclusive) are:
>
> -- discontinuity with vhdl (and now 1364-1998 verilog) generate
> semantics/usage.
> -- implicit declaration of generate index seems to be questionable.
>
> maybe more?
>
> what i was luckly assigned to do was come up with an alternative
> (which quite frankly is starting from behind as some are not
> particularily enthused about changing the above spec - although
> i see it as absolutely necessary for compatibility reasons).
>
> so as for questions on what you show below:
>
> -- why not use the VHDL-style generate - e.g. as a kinda block
> statement type attached to an existing iterative or conditional
> construct?
>
> IF ( cond ) generate
>
> end generate;
>
> -- what was the rationale from using the 'genvar' declaration
> for the generate? any semantic restrictions
>
> generate
> genvar i;
> ....
> endgenerate
>
> -- given the brief discussion regarding the verilog-a generate,
> what issue do you think that we also might need to consider for
> a behavioral equivalent?
>
> -- have the implications from the perspective of the acc/tf/vpi
> pli access methods been defined?
>
>
> i hope to put together something that does not fly in the face of
> 1364 as it stands and is going, but quite frankly i know i will be
> up against a lot of resistance from an entrenched party within the
> verilog-ams group. so i need to have something technically sound
> and consistent within both standard 1364 as well as throughout the
> verilog-ams specification.
>
> any help or suggestions that you can offer here will be highly
> appreciated.
>
> regards,
>
> --dan
>
> mac@silicon-sorcery.com wrote:
> >
> > Oh boy, do we ever. Kurt Baty has been sheparding through a
> > very powerful, rich generate statement that will allow all sorts of
> > wonderful description of models. As you may know Kurt is the guy who
> > wrote much of the Synopsys DesignWare descriptions.
> >
> > loosely, one can within the new keywords
> > generate .. endgenerate
> >
> > include any "module level items" (module instatiations, reg &
> > net declarartions and the like), as well as for, case and if.
> >
> > For example,
> >
> > module foo;
> > wire [size:0] o [size:0];
> > reg [31:0] i1;
> > reg [31:0] i2;
> > generate
> > genvar [31:0] i,j;
> > if (size > 2) begin
> > for (i = 0; i < size; i = i + 1) begin
> > for (j = 0; j < size-i; j = j + 1) begin
> > and a(o[i][j], i1[i], i2[j]);
> > end
> > end
> > end else
> > simple s1 (o,i1);
> > endgenerate
> > endmodule
> >
> > As you can see to support this, arrays of wires and regsisters
> > are needed, and to further depths than current memory.
> >
> > Also we have consistant naming convention to refer to these
> > instances
> >
> > Also we are contemplating adding the ability to call user
> > defined functions (with constants!) so as to define parameter values:
> >
> > parameter foo = log2(size);
> >
> > function integer log2;
> > input [31:0] arg;
> > begin
> > log2 = /* calculate log*/ arg;
> > end
> > endfunction
> >
> >
> > If you need more than this I can send you proposed BNF, sample models
> > and the like.
> >
> > -mac
>
> --
> Dan FitzPatrick voice: 650-261-2180
> Apteq Design Systems, Inc. fax: 650-261-2189
> 652 Bair Island Rd. Suite #300 e-mail: dkf@apteq.com
> Redwood City, CA 94063-2704 http://www.apteq.com
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:52:32 PDT
and
sponsored by Boyd Technology, Inc.