gnucap-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gnucap-devel] A follow up to a question from a while ago.


From: Thaddeus Meizelis
Subject: [Gnucap-devel] A follow up to a question from a while ago.
Date: Wed, 13 Aug 2008 21:59:03 -0500

I want to follow up with something I sent a while ago. (November 13, 2008 to
be exact.) To recap, I asked if there was a reason why the BV and IBV
parameters were not added in and if not, I offered to add them in. I was
invited to submit my work on it. I did some studying and work on it, and I
want to show what I did. (Bear with me, I am a newbie at this.)

First I added the breakdown mode:

h_headers {
  enum region_t {BREAKDOWN=-3, INITOFF=-2, REVERSE=-1, UNKNOWN=0,
FORWARD=1};
  enum polarity_t {pP = -1, pN = 1};
}

Now not being an expert in diode spice models at the time (and still not), I
did some research. In most of the models I have found, there seems to be a
disconnect between operation in the reverse region, and operation in the
breakdown region. More specifically, many times, the published saturation
current(IS) did not correspond with the breakdown voltage(BV) and the
current at the breakdown voltage(IBV). The model that I liked the most was
the HSPICE model. The HSPICE model adjusts the BV and IBV so that the three
parameters "match". I added this near the beginning of the YJ to calculate
the effective BV and IBV:

/* Adding effective BV and IBV for HSPICE parameters */
    double ibreak = -p->_isat*(exp(-m->bv/vt)-1);
    double bveff,ibveff;
    if (m->ibv>ibreak)  {
      bveff=m->bv-vt*log(m->ibv/ibreak);
      ibveff=m->ibv;
      }
    else {
      bveff=m->bv;
      ibveff=ibreak;
      }

Then I replaced the reverse bias code with this:

if (!has_good_value(m->bv) || volts >= -(bveff) || amps > 0.)  {
  double expterm = p->_isat * exp(volts/vt);    /* If not in breakdown... */
  y.f0 = expterm - p->_isat;/* i = f(x) = _isat * (exp(volts/vt)-1) */
  y.f1 = expterm / vt;        /* f'(x) = (_isat/vt) * exp(volts/vt)   */
}else{
  p->_region = BREAKDOWN;                       /* If we are in
breakdown...*/
  y.f1 = (p->_isat-amps) / vt;
  y.f0 = amps + (vt * log(1-(amps/p->_isat))+bveff)*(y.f1) + volts*y.f1;
}

I tested it with a couple of simulations and it seems to work, so I will
include this in my personal builds of Gnucap.

Now for some questions.

1. What is the proper way of attaching one of the spice3f5 models? I tried
to do an "attach ./dio.so" but it gave me a message and didn't seem to
replace the model. I tried to detach the builtin model, but it wouldn't let
me detach the builtin.

2. I get the impression that models are going to be replaced. things such as
user-generated models, standard spice models, in short that any work done on
the current builtin models won't be useful in the future. Is this the case?

3a. If so, I won't do any more work on the models themselves, and the diode
model in particular, because if they are going to be replaced, I don't want
my efforts to be in vain. I have been listening on this mailing list, and I
understand that there are other areas which I can concentrate my efforts on
other things, such as other gnucap plugins, or maybe n extension to Oregano,
Gschem, etc, etc.

3b. If not, since i picked up a lot of knowledge on diode models, I could
clean the "Yj" section in the diode. I could comment sections. I could allow
the user to configure which model (HSpice, Spice2, Spice3, PSpice) and LEVEL
he/she wanted to use. I have a couple questions regarding this: Do any other
models depend on the diode model? It seems the MOS models depend on the
diode model, but I am not sure. Where are the diode flags used? Can I change
those without breaking other things?

4. What's the proper way to submit a file to this list in case you guys want
me to submit my diode? I can't just send my post as an attachment can I?

5. By the way, just out of curiosity, how will the models work? From what I
gather, The plugins will be in a directory with a configuration file calling
out models and simulators in use. The models will be human readable and can
be downloaded during run time. Is this correct?  I like the idea and am
willing to contribute toward it.

IMHO, I would like to see the BV and IBV parameter included in the default
diode model in some way. I know there are ways around it, but without those
parameters, you exclude a class of components.

Thank you for reading my long post.

Tad


reply via email to

[Prev in Thread] Current Thread [Next in Thread]