gnucap-devel
[Top][All Lists]
Advanced

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

Re: [Gnucap-devel] SPICE to gnucap transition


From: Scott Dattalo
Subject: Re: [Gnucap-devel] SPICE to gnucap transition
Date: Sat, 17 Mar 2007 19:13:24 -0800 (PST)
User-agent: SquirrelMail/1.4.6

> On Saturday 17 March 2007 13:30, Scott Dattalo wrote:
>> (perhaps this should go to the 'help-gnucap' list?)
>
> Try it.  You will get a more user oriented answer there.

Okay - for the next thread I'll ask there.

<snip> - differences in user's SPICE and gnucap perspectives.

> There is a need for documentation here.  If you want to help, it
> would be very much appreciated.  I have been concentrating on
> enhancing the program itself, with the idea that the transition
> will come in time.

>From my viewpoint, gnucap is mostly a one-man-show. I'll be glad to make
some contributions to the degree I can.

> Compatibility will improve when the language plug-in capability
> is working, but actually I consider Spice to be very crippled.

Even if SPICE is crippled, it does work!

> For a real challenge, try to move the other way .. gnucap to
> spice, and see what is missing.

It would be a challenge since I know nothing about gnucap but am fairly
familiar with SPICE.

> If you tell us the specifics about the ones that don't work, I
> my be able to help more.

Okay, here's an example from some experiments I've conducted on TSMC's
0.25u process:

http://www.dattalo.com/spice/inverter.cir
http://www.dattalo.com/spice/TSMC_025u_Mosis.txt

The inverter.cir is fairly well commented; but in summary it is a SPICE
circuit designed to measure a CMOS inverter's current draw as a function
of the input voltage. The second file contains the N and P MOS models. If
you run the spice commands described in inverter.cir, you can produce the
output:

http://www.dattalo.com/spice/inverter_current.png

This example is one way in which I use SPICE; test out simple circuits in
an interactive mode. The other way I use SPICE is to model circuitry in
the capacitance sensing ASIC's we produce at Synaptics
(http://www.synaptics.com/). I'm not at liberty to post these models,
however I can say that I have to write a good chunk of C-code to wrap
around SPICE's limitations. For example, I have defined parametric models
of capacitance sensing circuitry that are parsed by C scripts and turned
into SPICE models. These in turn are batch processed by SPICE and the
results fed back to other C scripts that perform post processing. Despite
being a custom application, I doubt my requirements are too unusual. I
have not tried gnucap for this.

>> 2) Are there any gnucap unit-test style examples?
>
> I do have a test suite that I probably should package up.

Most users will read examples and ignore documentation.

>> For example, most people familiar with electronics will
>> understand basic things like say the step response of an RC
>> low pass filter. Has anyone designed a set of examples that
>> attempt to minimize circuit complexity but maximize gnucap's
>> capabilities? I google'd around but didn't find anything
>> useful.
>
> Not much.  I agree that it is needed.

And there are several people like myself both capable and willing to
contribute in this form.

>> 3) What is the preferred waveform viewer? From the archives
>> it appears that gwave is the one. (Or, at least gwave is the
>> only one that accepts the ASCII tabular output of gnucap.)
>
> gwave ..
>
> I find it strange that gwave is the only one that accepts the
> gnucap files.  The gnucap files can be read by anything that is
> not spice specific, easily.  The only viewers that have a
> problem are the ones specifically written for the bizarre
> format that spice uses.  There are many of these.

I was under the impression that there was some modification made to gwave
to accommodate gnucap since the web site specifically mentions gnucap. I'm
somewhat reluctant to use gwave because it would be the *only* application
installed on my FC6 box that depends on the ancient gtk-1.2.x!

> You can also read the files with gnuplot, octave, most
> spreadsheets, and many others.

I'm familiar with Octave so for now I will use that.

> There are plans to have output plugins, which will make the
> interface to postprocessor programs better.

Yep.

Thanks,
Scott




reply via email to

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