Re: multiple analog blocks

From: Marq Kole <marq.kole_at_.....>
Date: Wed Dec 20 2006 - 06:06:02 PST

Geoffrey,

I share Martin's concerns on current (compact) modelling practices. What I see a lot of compact model developers do is to use @initial_step to perform some kind of initialization, under the mistaken assumption that this is the right (and only) place to do so. An analog initialization can provide a syntactically appealing place for those looking for a "standard" place to put their initializing code. In that sense the analog initialization is no more than some syntactic sugar.

Why do you think it forces a particular coding style? I would definitely be against being forced to move all "initialization" code to an analog initialization block. In my opinion a compiler that optimizes named blocks on activity should work whether an analog initialization block is used or not -- consider that compiler optimization is not enforced in the language either, but it is a way compiler developers can offer more performce to their users. Considering (assuming?) there already are optimizing Verilog-A compilers, the advantage of an analog initialization block would be on the modeller's side.

Cheers,
Marq


Marq Kole
Competence Leader Robust Design

Research
NXP Semiconductors








"Geoffrey.Coram" <Geoffrey.Coram@analog.com>

Sent by:
geoffrey.coram@analog.com

20-12-2006 13:04

To
Marq Kole <marq.kole@nxp.com>
cc
verilog-ams <verilog-ams@eda-stds.org>
Subject
Re: multiple analog blocks
Classification





Marq Kole wrote:
>
> I do support your idea of having a separate analog initialization
> block with the given restrictions. We'd finally be done with
> @initial_step - this should really only be used for time-domain
> modelling/analysis.

I don't support this analog initialization.  A person can easily
identify what variables don't depend on biases, and a compiler
can reasonably easily be taught.  It's a cop-out to force the
compact model author to write in a particular style because the
compiler writer is lazy.  The author may or may not remember to
move all the appropriate calculations -- even in hand-coded
BSIM3, there are a number of calculations that are done in the
evaluate section rather than pre-computed (for example:

         tmp3 = pParam->BSIM3weff + pParam->BSIM3b1;
         tmp4 = pParam->BSIM3b0 / tmp3;

) or the author may want to group, say, all the avalanche
calculations together, rather than splitting up the
initialization from the bias-dependent.

-Geoffrey

Received on Wed Dec 20 06:17:19 2006

This archive was generated by hypermail 2.1.8 : Wed Dec 20 2006 - 06:17:26 PST