RE: MOS11 noise implementation in Verilog-A

From: <Vassilios.Gerousis@infineon.com>
Date: Thu May 20 2004 - 02:50:18 PDT

We should be careful in using tool product names and their ability to
support or not to support certain functionality. Please use generic
terminology and focus on what the standard should support. Accellera as
a non-profit organization disallows such references (Verilog-A
compilers, Colin Simulator, ADMS, etc.). The committee is implementing a
standard for the industry and not for one specific tool or a specific
simulator.

The committee should address proposals based on technical merits as the
primary focus, second is the ease or difficulty of modeling , third can
discuss "the possible" ease or difficulty of building parsers or
simulators "without a reference to a product".

I suggest that topics like noise modeling can be discussed in terms
assigning noise to variable, noise as nodes or ports, and/or noise
language extensions.

I would appreciate your cooperation on this matter.

Vassilios

-----Original Message-----
From: owner-verilog-ams-devmod@eda.org
[mailto:owner-verilog-ams-devmod@eda.org] On Behalf Of Ilya Yusim
Sent: Thursday, May 20, 2004 3:59 AM
To: Geoffrey.Coram
Cc: VerilogA Device Modeling Reflector
Subject: Re: MOS11 noise implementation in Verilog-A

Geoffrey,

    I agree that using extra nodes and a capacitor to implement the j
factor, will enable us to write most practical noise functions. The
Verilog-A compiler can even go further and try to reduce this node. But
wouldn't it be easier for the user to just write the complete noise PSD
equation directly, including the j factor. Of course, this would
require a language extension.

Ilya

Geoffrey.Coram wrote:

>Following an example in the Verilog-AMS LRM (4.5.3.5 on
>page 4-33), I believe the following code should produce
>the correlated gate noise of the MOS11 model (level 1101).
>
>I think Colin said that his simulator doesn't allow you
>to assign noise to a variable, and ADMS doesn't do noise
>at all, so I'm not quite sure anyone can test this out.
>But here goes.
>
>------------------
>
>// extra module items
>electrical noi; // extra internal node
>branch (noi) noiI, noiR, noiC;
>
>real n1, n2, n12;
>real rho_igth, nf1, nf2;
>
>// extra code for the analog block
>rho_igth = 0.4;
>nf1 = 27.0/40.0;
>nf2 = 1.0/(sqrt(nf1));
>
>n1 = white_noise(1.0 - rho_igth);
>n2 = white_noise(1.0 - rho_igth);
>n12 = white_noise(rho_igth);
>
>I(d,s) <+ NT_T / (Gmob*Gmob) * (Rideal - Tc_square * Ids * delpsi_s)
> * (n1 + n12);
>
>I(noiI) <+ NT_T * (3*Gm) * nf1 * (n2 + n12);
>I(noiR) <+ V(noiR) * (3*Gm) * nf2;
>I(noiC) <+ ddt(COX * V(noiC));
>
>I(g,s) <+ I(noiC);
>
>------------------
>
>The variables Gmob, Rideal, Tc_square, Ids, delpsi_s, and Gm are taken
>from the simkit_1.2.1 code for device_m1101i.c
>
>NT_T = temperature-adjusted value of parameter NT
>
>This does not account for drain/source swapping.
>
>What I've done is create an RC filter (R = 1/(3*Gm*nf2),
>C=Cox) driven by a white noise current source with PSD
>of NT_T * (3*Gm) * nf1. The power spectral density of
>the capacitor current is then
>
> NT_T * (3*Gm) * nf1 * || (2*pi*f*Cox)/(3*Gm*nf2 + j*2*pi*f*Cox) ||**2
>
> = NT_T * nf1 / (3*Gm*nf2*nf2) * pow(2*pi*f*Cox,2)
> -----------------------------------------------
> 1 + 1/(9*nf2*nf2)*pow(2*pi*f*Cox/Gm,2)
>
>
>With my particular choice of nf1 and nf2, this reduces to
>
> = NT_T * / (3*Gm) * pow(2*pi*f*Cox,2)
> -----------------------------------
> 1 + 0.075*pow(2*pi*f*Cox/Gm,2)
>
>The Philips documentation talks about 1/3 of the channel resistance in
>series with the oxide capacitance; in an ac noise analysis, you get a
>parallel combination of the noise current source, the R, and the C. I
>think this should give you nf1=nf2=1.0, but to match the
>equations implemented, you have to use the funny values
>given above.
>
>I think the fact that I'm sensing the capacitor current
>will give the factor of j (=sqrt(-1)) to match the value
>of rho_igth = 0.4j in the Philips report (eq. 2.120 in
>NLUR2002_802.pdf).
>
>
>-Geoffrey
>
>
Received on Thu May 20 02:50:27 2004

This archive was generated by hypermail 2.1.8 : Thu May 20 2004 - 02:50:32 PDT