Re: [Gnucap-devel] SPICE to gnucap transition

[al davis]

On Monday 19 March 2007 00:07, Scott Dattalo wrote:
> > > http://www.dattalo.com/spice/inverter.cir
> > > http://www.dattalo.com/spice/TSMC_025u_Mosis.txt
> >
> > First, you need to change the command order.  This is the
> > difference I mentioned.
>
> Can you be more specific? I tried putting the model include
> file in different places, but I did not experiment with
> putting the print statements before the netlist or anything
> like that.

That is what is wrong.

You build the circuit
Attach the probes.
Turn it on.....

The confusion is that the "print" and "plot" attach the probes, 
then "dc" or whatever "turns it on" printing or plotting as it 
runs.  You need to put "print"or "plot" before "dc" or 
whatever.  Those commands are ececuted in order, like a C 
program.

Doing print/plot that way actually turned out to be a mistake, 
but the fix is not the obvious one, and all that will change 
anyway.  How much effort should I put into changing something 
that will be thrown away?

I thought of changing it so that the "dc" and "tran" commands 
are setups and the "print" actually does the work, but this 
causes a different set of problems.

Spice did a work-around with the ".control" keyword.  This was 
not in Spice-3 until later.  When I did that work in gnucap, 
Spice-3 was not out yet, so any spice connection is Spice-2.  
That ".control" key is not documented, but it seems everyone 
knows it.  It wraps commands that you would use interactively.

That would have been a better way for gnucap to do it.  At this 
point, to change it in the old architecture would be so much 
work that it would likely kill the project.  To make the 
architectural changes, then the appropriate plug-in, is easier 
and will work better.

Making it truly spice compatible causes other problems, and 
makes it restrictive enough that I could not do the kind of 
analysis I want to do.

The intended way to run it has always been to have separate 
command and circuit files.  The combined file is a concession 
to Spice.

> If you can fix my inverter.cir example, then I can 
> give you a half dozen other examples that will work with
> gnucap.
>
> > Also, I noticed that one file has a comment on how you
> > needed to change it because ngspice is missing something. 
> > Surprised??? Go from one to another, you will always find
> > something missing.
>
> Actually, before making accusations against ngspice you may
> wish to read the Mosis FAQ. 

That was a generic comment, not directed at anyone in 
particular.

> They specifically note that their 
> models are SPICE compliant except for the XW and XL
> parameters. These parameters were introduced by HSPICE and
> subsequent proprietary SPICEs have adopted them. But ngspice
> *is* SPICE.
>
> > So, there are certain hacks you just accept .. like the
> > need to put in a voltage source where you want to measure
> > current. That's a hack because spice only lets you view
> > voltages, so you add a subcircuit that has an internal node
> > whose voltage corresponds to the current through the end
> > points.  You may not realize this, but that is what you are
> > doing.
>
> I realize these things. I know they're hacks. I also know how
> to work around them! I also know that except for the promises
> of gnucap there is no other decent open source circuit
> simulation tool out there. I'm hoping gnucap lives up to my
> expectations!

You get a different set of hacks.  I try to minimize it, but any 
engineer knows......
>
> > gnucap lets you print the values of all internal variables,
> > so you can just ask for "IS(M1)" or whatever you want.
>
> Cool! That sounds really useful. This is the kind of thing
> that should be written up in a tutorial/user's manual. I
> didn't see it the first time I read through the gnucap
> manual, and I just did a quick search and still couldn't find
> it. I suspect there are many, many other tidbits of really
> useful information/features that we can capture into a form
> that others can begin to start using.

There is always the question of what to do first, what to hope 
someone else will do, etc.  If I did all that, there would be 
no time left for the good stuff, leaving no reason for gnucap 
to exist at all.

> I'm fairly certain some pre-processing and post-processing
> scripting is needed. However, a .param statement that works
> could greatly simplify them!

Of course.  I never even implied otherwise.


> No. Synaptics will not fund this. This is something I'm doing
> on my own. I'm a research engineer and focus primarily on
> algorithms. I'm using SPICE (and hopefully gnucap) as a means
> of investigating some ideas that couple algorithms more
> tightly to hardware. In addition, I'm interested in the
> concept of simulation. (More on this later).

> I've been following the gnucap saga for quite some time. In
> my opinion, you should take a step back from making things
> better and a step towards making things easier. I don't mean
> that in a critical or mean way - seriously! I get the sense
> that very few people are using gnucap because they can't
> understand it.

Some people define the old way as "easier".  Some windows users 
define "easier" as more like windows.  That is not what I want 
to do.  The Spice way is not easier.  If you are not 
preconditioned to Spice, gnucap is easier.  Once you grasp the 
ordering diffference, gnucap is easier.

The mistake was trying to strike a balance between spice 
compatibility and moving forward.  Every step forward 
introduces compatibility problems.

That is why the solution is to move away from the spice format 
completely.  The plan is that gnucap will become primarily a 
Verilog-AMS simulator, with a spice-compatibility plug-in.  
That way "easier" can be done in the Verilog sense, which is 
more consistent, and a compatibility plugin needs no 
extensions, so it can be truly compatible.

When this is done, I think many will see that Verilog-AMS is 
better than Spice in every way, including being easier and more 
predictable.

The biggest problem has been with models.  Gnucap doesn't have 
them all.  That too is being solved by Verilog and by plugins.

There is a serious need for beginner documentation.  I plan to 
do that, when Verilog works.  For now, it doesn't bother me to 
lose the people who want Spice as Spice.  I am glad that 
ng-spice exists, to take up this slack.