Re: [ng-spice-devel] Dotcards.c


To ng-spice-devel@ieee.ing.uniroma1.it
From Alan Gillespie <alan.gillespie@analog.com>
Date Tue, 12 Sep 2000 10:06:49 -0400
Delivered-To mailing list ng-spice-devel@ieee.ing.uniroma1.it
Mailing-List contact ng-spice-devel-help@ieee.ing.uniroma1.it; run by ezmlm
References <Pine.LNX.3.96.1000912072850.5164A-100000@ieee.ing.uniroma1.it >
Reply-To ng-spice-devel@ieee.ing.uniroma1.it
Sender agillesp@epc.co.uk

Paolo Nenzi wrote:

> On Mon, 11 Sep 2000, Alan Gillespie wrote:
>
> I will check this evening. Can you tell me why you have changed the order
> of AC and OP analsyses in conf.c, bconf.c and so on ?
>

I changed the order of the analyses because I was getting the following
behaviour - if you run both a .OP and a .TRAN, then the voltages
printed to the output file reflect the result of the .OP, but the operating
point data for all the devices would be for the state they're in at the end
of the .TRAN

Oh wait a minute, you're talking about the AC and the OP. Ah, it's coming
back to me :-) That was to do with option to save the DC operating
point conditions between analyses. I can't remember the exact name of
the option, but I think the .OP came after the .AC, and the flag didn't seem

to work in that direction.

With certain circuits which had multiple stable states, the .OP and .AC
dc solutions didn't always match, so you'd get .OP data that didn't
match the conditions under which the AC analysis was run. Using that
option so save the DC operating point between analysis forces the .OP
solution to be used for the AC analysis, but it didn't work if the AC was
done first. I can't remember the details of why this was the case.


>
> I am stiull thinkng that the cause of the malfunction is related to the
> vectors database routines. When I run the fourbitadder.cir test, it works
> when ngspice is run in batch mode and does not work when in interactive
> mode. Does not work means that ngspice computes the solution but does not
> output any vector.

I managed to download that snapshot that you put in my home directory
last night, and I had a look at the new version. I think what you need to
do is to revert back to your original outitf.c. The device internal node to
terminal current conversion hack that I've got in there should be done
"properly" anyway.

It looks like you've incorporated all my changes from that, including the
format change from Berkeley Spice to PSPICE. You probably don't want
that just now, if at all.

If the problem you're seeing is just for .OP's then I think there's a
test in dotcards.c which checks if this is a .OP analysis, and if it is,
it doesn't output the vector to the "rawfile". This was because of the
way I use my Spice, i.e. I look at all .OP results in the output file. It
was
no use to me in the rawfile. Obviously, if you're used to working another
way, then this won't be appropriate.

It looks like this test made it into the ng-spice code, although it's not
exactly the same as the way I wrote it, so I can't actually be sure. I
think it's now a currplot == OP test, or something like that.

There's another test in that file which was if (terse) and is now if
(false).
You might want to change that back. I had two if (false) statements in
there, which were just to make sure  that the text output of node voltages
and device parameters happens even if a rawfile is being generated. You
might not want to work this way.

Anyway, I've a question about that snapshot. There wasn't a configure
script to run, so I guessed that I might need to run autogen. Is that right
?
Or can I steal the configure script from rework 12 ? autogen told me I need
libtool, which I thought I had, but I haven't got to the bottom of that yet.

Also, I uploaded the code which I meant to send you the last time, with
the level 2 BJT and the level 9 MOS separated from level 3. It's in the
top level of my home directory in source.tar.bz2 (or something like that).

Cheers,

Alan


Partial thread listing: