Re: pointer to the latest proposals

J.A. Barby wrote:

>....
>
>On the paramset proposal issue/question we may want to adjust how a
>paramset is viewed. It is actually a level in the hierarchy above the
>generic device model which supplies the generic device model process
>parameters and/or geometry parameters in such a way as there is only one
>copy of the parameters in memory rather than one copy for each instance
>of the generic device model. Memory usage would exploid in all 200+
>device model parameters were copied into memory for every instance of
>the device model. If this happens, verilog-AMS will not be usable for
>anything other than small/simple mixed-signal circuits. My experience
>is that designers want the parameterized device model and not the
>generic device model. ie the parameters fixed by the silicon foundary
>should be transparent to the circuit designer.
>
>...
>Jim
>
The proposals so far use inheritance to access common parameters or just
expect overrides per instance. I don't think anyone intends that each
instance should have its own copy of all the parameters, and if the LRM
(accidently) implied that was the case I'm sure the folks building the
simulators would implement the mechanisms in such a way that it would
only appear to happen (no multiple copies will actually exist).

Parameter evaluation is an elaboration time exercise, the values are
(usually) constant for actual simulation, modern compiled-code
simulators will only carry the minimum of information into simulation
since a lot of the parameter arithmetic will collapse during code
optimization.

Kev.

>
>>From owner-verilog-ams@eda.org Thu Jun 24 03:12:56 2004
>
>
>>Subject: RE: [sv-ec] Quick poll for AMS extension to overload modules
>>From: <Vassilios.Gerousis@Infineon.com>
>>To: <kcameron@altera.com>, <Geoffrey.Coram@analog.com>,
>> <Srikanth.Chandrasekaran@motorola.com>
>>Cc: <sv-ec@eda.org>, <verilog-ams@eda.org>
>>
>>Hello Kevin and Goeffrey,
>>
>> It looks like this topic has generated a large amount of email
>>traffic. Can I ask you to do the following favor, please:
>>
>>1- Put a proposal together that summarize the following:
>> a- The problem that you are trying (Verilog-AMS) to solve.
>> b- Desired features that you would like (Verilog-AMS) to see to
>> address the problem.
>> b- Add a section on proposed solutions (different ideas that
>> people so far proposed).
>>2- Set up a special meeting and discuss this in length and agree as a
>> committee on the proposal, solutions and agree on an approach.
>>
>>Make sure that Sri is in agreement prior to publication.
>> We must operate under the following operating guidelines (as you
>>have seen from the feedback):
>>
>>1- The solution must be compatible with IEEE Verilog 2001 standard. We
>>cannot afford to get broken tools or models. The goal of the current
>>Verilog-AMS LRM, is to be compatible and not to ask for enhancement.
>>
>>2- The solution should not conflict with SystemVerilog 3.1A standard.
>>
>>3- The solution should be easy to mode and use.
>>
>>Best Regards
>>
>>Vassilios
>>...
>>
>>
>
>--
> J.A. Barby <jabarby@UWaterloo.ca>
> E&CE, University of Waterloo, 200 University Ave W,
> Waterloo, Ontario, Canada, N2L 3G1
> 519-888-4567x3995, FAX 519-746-5195
>
>
Received on Tue Jun 29 09:28:25 2004