RE: Minutes of: VAMS Compact Modeling conf call May 20

I have question below about the string issue.
Thanks,
--Martin

> -----Original Message-----
> From: owner-verilog-ams@eda.org [mailto:owner-verilog-ams@eda.org] On
> Behalf Of Geoffrey.Coram
> Sent: Thursday, May 20, 2004 9:15 AM
> To: VerilogA Device Modeling Reflector; verilog-ams@eda.org
> Subject: Minutes of: VAMS Compact Modeling conf call May 20
>
> V-AMS Compact Modeling Extensions subcommittee
> Minutes of May 20, 2004
>
> Attendees:
> Geoffrey Coram, Analog Devices
> Ilya Yusim, Cadence
> Colin McAndrew, Freescale
> Srikanth Chandrasekaran, Motorola
> David Zweidinger, Texas Instruments
> Jim Barby, U Waterloo
> Ninglong Lu, Intel
> Jung-Hoon Rhew, Intel
>
>
> 1. Approval of previous minutes (Apr 20).
>
>
> 2. LRM 2.2 draft b
>
> The following items are not in the draft, as mentioned in the e-mail:
> a) paramsets
> I just didn't get to it in time
> b) mfactor
> Waiting for a proposal from Cadence to the main AMS committee
> c) dc sweep for mixed-signal
> Sri will send me an updated proposal in the next day or so
> d) simparam descriptions
> Colin e-mailed me these; they will be in the next draft
> e) module descriptions
> an oversight on my part
>
>
> 3. Noise extension
>
> Ilya wanted to know if an extra node was required; I used one
> in my implementation of the Philips MOS11 (level 1101) model.
>
> Colin said one simulator does not get correlation, only magnitude,
> because it doesn't add an extra node
>
> Ilya said another simulator does get correlation without the
> extra node, but it requires a change to the noise analysis
> routine (adjoint solution method) to support loading two values
> into the RHS vector.
>
> Colin noted that we require a smart compiler to optimize away
> unneeded nodes in other contexts; so probably it is reasonable
> to expect the compiler to optimize away my noise node if its
> noise analysis routine supports correlated noise natively.
>
>
> 4. String parameters
>
> Sri asked if the range (from {"a", "b"}) is mandatory.
> This tells the simulator how much space to allocate for the string,
> (similar to how digital reg variables have a size), so I believe
> it should be mandatory.
Could someone elaborate more on this point? If the point is that the module should indicate the maximum number of chars the string should have - this is not correct. In Verilog, parameter sizes and indeed types are not finally determined until elaboration time.

>
>
> 5. Limit call
>
> Sri asked if, when using a UDF, the arguments be inouts or outputs?
> We believe they should not be; the Spice functions have only one
> return value. Thus we will sematically restrict inputs to a UDF
> use for limiting to be inputs only.
>
> Sri also asked that a table of Spice limiting functions be added
> to Annex E, in addition to the text descriptions in Section 4.4.15.
>
>
> 6. ddx(ddt(expr))
>
> This syntax is allowed by the LRM and should not be restricted.
> We should be sure that the examples for ddx show the proper use.
>
> In general, any analog_operator can be part of the first argument
> (expression) to ddx. However, the ddx() operator takes partial
> derivatives with respect to the independent variable given as
> the second argument; if the simulator creates internal nodes to
> implement the analog_operator, then one cannot reference that
> node to take a partial derivative, and that node will be held
> constant when taking the partial wrt other variables.
>
>
> 7. Paramset resolution
>
> Addressing Kevin's concerns from e-mails to the reflector, we
> agreed that we do need some resolution rules to determine
> which paramset is chosen for an instance.
>
> Setting up the system to find the "best" paramset could
> require extra memory, but it is done once at elaboration time,
> so the memory can be "recycled" for simulation.
>
> ... except for dc sweeps, in which one might be sweeping the
> transistor length and hence the "bin" or paramset selected.
>
> We could specify that the paramset selected is fixed at
> elaboration time. That's a bad idea; the user should not
> have to figure out how to split up a sweep into pieces
> that are contained in one "bin."
>
> It seems that each point of a dc sweep will require a new
> elaboration / selection of paramsets. This is consistent
> with the idea that a dc sweep is a collection of operating
> points. It may cause trouble if the topology changes
> (eg, the new paramset adds gate resistance and thus a new
> node to the system); the simulator may have to re-start
> the simulation from scratch rather than using values from
> the previous point of the sweep.
>
>
> 8. Upcoming meetings:
> May 24, 7:30PM ET, 4:30PM PT - main AMS to discuss LRM 2.2 draft
> June 1, 9AM ET, 6AM PT - CM subcommittee meeting
> June 1, 7:30PM ET, 4:30PM PT - main AMS to discuss mfactor and mix-sig
> OP
>
> --
> 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
Received on Thu May 20 09:24:51 2004