Subject: V-AMS DevModeling Dec 16, minutes from Dec 2
From: Geoffrey.Coram (Geoffrey.Coram@analog.com)
Date: Fri Dec 12 2003 - 15:42:52 PST
Greetings -
The device modeling extensions subcommittee will be meeting
Tuesday, December 16, at 11 AM Eastern (8 AM Pacific).
The dial-in information is below; thanks again to Ilya
and Cadence for sponsoring it.
> Toll-Free Number: 888-454-9810
> Toll Number: 1-415-228-4715
>
> PASSCODE: 92821
We'll talk about inheritance (see message below) and about
any issues that have come up as we've started to write the
BNF for the current list of proposals.
I also want to note that the main V-AMS conference call
scheduled for Monday, December 15 at 4:30 PM Pacific
will be devoted to a quick pass through our proposals to
make sure they don't conflict with anything the AMS
committee is doing. The numbers for that meeting are
USA Toll Free Number: 877-346-8823
USA Toll Number: +1-203-320-0407 (for international call-in)
PARTICIPANT PASSCODE: 602538
but I don't think the rest of the subcommittee needs to
call in for this.
-Geoffrey
Minutes of the December 2 meeting:
Geoffrey Coram, Analog Devices
Ilya Yusim, Cadence
John Moore, Agilent
Laurent Lemaitre, Motorola
Colin McAndrew, Motorola
Marek Mierzwinski, Tiburon
Jim Barby, U Waterloo
Al Davis, Kettering U
1) Approval of previous minutes (Nov 18).
2) Al Davis's proposal was swallowed by the reflector
(perhaps when eda.org went down). It is included below.
3) Assignments
The sections of the current proposals were divvied up
among the participants for us to get a start at writing
the BNF. Those who took assignments will find the
appropriate sections that need to be modified and
send me some plain text that I will assimilate into
the FrameMaker master document.
I think we will find some areas where the proposal document
is not specific enough to write a BNF description.
----- Forwarded message from Al Davis -----
===================================
Here are some thoughts on inheritance....
Syntax extensions:
1. inherit statement, or one line header like paramset.
2. Ability to call overridden blocks in a base module.
3. Value overrides like paramset.
=========
Declaring a hierarchical module.
Consider a base module...
-----
module mod1 (ex1, ex2);
inout ex1, ex2;
electrical ex1, ex2;
electrical int1, int2;
parameter real g = 1.0;
resistor #(.r(10))
r1(ex1, int1),
r2(ex2, int2);
branch(int1, int2) ab1;
analog begin
I(ab1) <+ g * v(ab1);
end
endmodule
-----
Nothing new here. It is just a simple module using a few of
Verilog-A's features.
For reference, and to confirm my understanding, we could have a
paramset...
paramset ps1 mod1;
parameter real L=1;
parameter real W=1;
g = g * W/L;
endparamset
As I understand, this is equivalent to...
-----
module ps (ex1, ex2);
inout ex1, ex2;
electrical ex1, ex2;
electrical int1, int2;
parameter real L=1; // added
parameter real W=1; // added
//parameter real g = 1.0; // replaced
parameter real g = g * W/L; // by this
resistor #(.r(10))
r1(ex1, int1),
r2(ex2, int2);
branch(int1, int2) ab1;
analog begin
I(ab1) <+ g * v(ab1);
end
endmodule
-----
... but for less typing, etc.
I propose taking it a step farther. Another module might be...
-----
module mod2 mod1;
parameter real L=1;
parameter real W=1;
g = g * W/L;
endmodule
-----
So far, it looks like paramset.
Now, add to the structure...
-----
module mod3 mod1;
parameter real p1=1;
parameter real p2=1;
electrical int3;
capacitor #(.c(1.2pf))
c1(int1, int3),
c2(int2, int3);
branch (int1, int3) ab2;
branch (int2, int3) ab3;
analog begin
mod1; // Call the evaluator for mod1.
// It won't unless you do this.
// This lets you completely replace it.
I(ab1) += p1 * I(c1);
end
endmodule
-----
Some notes...
1. At first it may look like you could accomplish this by
including an instance of mod1 in the structure, which can be
done now. Inheritance allows you to replace the analog block
entirely. The new block replaces the old. Including an
instance of mod1 creates a "has a" relationship. This
inheritance, like paramset, creates an "is a" relationship.
2. In some cases an element could be modeled as either a mod1 or
mod3, automatically as by a homotopy algorithm.
3. A simulator that does not support model hierarchy or
inheritance could implement this feature by text macro
expansion at minimal expense.
4. A simulator that supports model hierarchy or inheritance
could generate more efficient code based on the hierarchical
information provided.
5. The derived module is easier to comprehend and maintain
than the larger module that would be made without inheritance,
in the same manner as subroutines enhance a traditional
language.
6. I did not address changes to the connections. In this case,
the connection list is inherited. Probably adding to the
connection list should be allowed, but not arbitrary changes.
----- End forwarded message -----
-- Geoffrey J. Coram, Ph.D. Senior CAD Engineer Analog Devices, Inc. Geoffrey.Coram@analog.com 804 Woburn St., MS-422, Tel (781) 937-1924 Wilmington, MA 01887 Fax (781) 937-1014
This archive was generated by hypermail 2b28 : Fri Dec 12 2003 - 15:43:24 PST