Re: gEDA-user: Using .global statements in GNUcap and mult

[al davis <ad151@xxxxxxxxxxxxxxxx>]

On Tuesday 10 March 2009, r wrote:
> On Tue, Mar 10, 2009 at 2:11 PM, al davis 
<ad151@xxxxxxxxxxxxxxxx> wrote:
> > Can you send me some examples of where it crashes?
>
> I sent you a bug report recently. As for the newest revision,
> I haven't tried it yet, sorry.

It was an assert fail, in a development snapshot.  Just remove 
the assert and it's ok, or compile without debugging.  I sent 
you the "fix" a long time ago.  It was in the "spice-wrapper" 
plugin interface, that's new code, in "alpha".  And .. the 
problem only happened on Intel processors, due to a known 
artifact of the math where the same operation doesn't always 
give the same results, depending on whether a result is in a 
register or not.  I develop on AMD, so it didn't crash for me.

> >> ability to probe signals at lower levels of hierarchy,
> >
> > You can.
>
> How to do it without adding probing devices to the circuits?
> Or, how to save all signals or all classes of signals?

Wildcards?????

Gnucap makes a lot more information directly available than 
other simulators, perhaps more than any other.  The Gnucap way 
of doing it is a lot more flexible than any pre-defined 
categories.

Part of the idea of plugins is so you, a user, can add things 
like "saving classes of signals" yourself.

In the decision of how to spend my time, I have chosen to build 
a flexible base and the development tools so regular users can 
extend it, rather than chasing all of the little things myself.

> >> robust operating point analysis etc.
> >
> > Can you send me some examples of where it doesn't work?
>
> I sent it to you a while ago (an example with a simple CMOS
> opamp). Your conclusion was that OP analysis failed because
> of missing homotopy.

Not quite, but close.  I never claimed it was perfect.  Nothing 
is.  There is a lot on the to-do list, including several 
homotopy methods for recovering from a convergence failure.

What I said was that other simulators I tried that example 
on also failed initially, but some were able to recover 
something using homotopy, which is essentially an automated way 
to tweek the options.

Comparing to Spice, one key difference is in the convergence 
checking.  Spice checks very few parameters.  Usually it 
combines several parameters mathematically into a single number 
and checks that.  As a result, it is prone to false 
convergence.  Gnucap checks all of the state variables, 
all of the matrix stamp values, and all of the currents, 
separately.  For acceptance, all checks must pass, not just a 
single number that is an average of them or the sum of them.

One of the problems I had with early versions of the 
spice-wrapper (for using Spice C models) is that convergence 
checking is part of the model code, and what came with the 
Spice models was inadequate.  The version in the current 
snapshot seems to work well.

You often get an extra iteration because of this, sometimes a 
few more iterations.  Occasionally, it might say it doesn't 
converge when Spice would appear to converge in just a few 
iterations.

Which would you rather have ..  strict checking that 
occasionally fails because it is too strict?  or sloppy 
checking that occasionally gives you a completely wrong answer 
with no indication of anything wrong?

Actually, the job of making it robust is never done, and none 
are perfect.  I have a long list of ways to make it better, and 
not enough time to do it all.

> >> its transient simulation time step
> >> control is very brittle
> >
> > Really?  can you give some examples?  I don't have access
> > to the big-bucks simulators for comparison, but in my tests
> > the time step control is consistently better than Spice.
>
> Earlier last year I did a bunch of tests using clocked CMOS
> digital circuit - they tend to exercise time step control
> quite well. I didn't even need other simulators for
> comparison - just analysing output data was enough to see how
> the time step control algorithm performed. It was fairly
> difficult for me to tune Gnucap options so that it scaled
> time step "reasonably" without causing excessive errors or
> ringing. Again, I'm going try the newest version of Gnucap,
> including its gear method.

So long ago! and even then the step size control 
was "consistently better than Spice".  You will always find 
cases that go the other way.

I admit, most of my work is pure analog, so I may not see some 
issues until somebody tells me about them.  I have several test 
cases that work fine on gnucap that are completely bogus on 
spice  (Negative resistance oscillator, stopping an oscillator)  
and more where spice produces results that are believable but 
not really useful (measuring frequency or distortion of an 
oscillator, spectrum analysis of RF circuits like modulators.)

Spice step control is based on truncation error, iteration 
count, and pre-scheduled "break points".  Gnucap does all of 
this (except that when you use "Euler" it appropriately ignores 
truncation error).  In addition, it considers cross events, 
curve fitting of voltages, currents, and state variables, and a 
full event queue.

Time step control is another of those areas that is never done.  
Whatever is there, it will always be possible to find some way 
to make it not work.  This applies to the big bucks simulators 
too. I have a long list of ways to make it better, and not 
enough time to do it all.

Based on the problem reports and service requests I have 
received, most issues that are perceived as step size control 
issues are really something else.  I agree that the error 
reporting could use improvement.  By far, the most common 
problem is an error in the netlist.

> >> and output data are saved in
> >> non-indexed text files.
> >
> > Eventually, the output will be through plugins too, so you
> > will be able to add other formats.  For now, I had to put a
> > stop to new features to focus on making an official
> > release.
>
> That's OK. Perhaps even I can help you with this someday. My
> point is that it's a bit early to advertise performance of
> the tool, when many important bits of functionality are still
> missing. E.g. text file format may be great for simple
> simulations but it isn't terribly useful for long running
> simulations (i.e. those which need a fast simulator).

Advertise?   Telling people about some benchmarks on the gEDA 
list?

All tools have strengths and weaknesses.  With free software, 
telling people about the strengths is one way to get help with 
the weaknesses.  Without this, none would ever get off the 
ground.

One application with very large circuits that needs a fast 
simulator is signal integrity.  You get huge RC or RLC networks 
from an extractor, and only care about a few end points, so the 
output stream is small.

Gnucap, like anything else, has certain places where it works 
very well, some that work ok, and some that are not acceptable.  
In time, more will move to the very well category.  For now, I 
I don't see anything wrong with telling people about the places 
it works very well, just because there is some other place 
where it doesn't work well.  Maybe telling people might bring 
in some people to participate in the project, or some funding 
to work on the areas in need.

> BTW., you are probably aware of a renewed interest in high
> performance analog simulators (not mixed-signal and not
> "fast-spice" type). Guys are trying to parallelize as many
> operations as possible (evaluating models and matrix
> operations) and optimize all other bottlenecks (time step
> control, IO). If you want to compete in this field it's going
> to be tough now. However, even with lower performance Gnucap
> can still be a very valuable tool as long as it does its job.
> People often want to run many small simulations in parallel
> and in such scenario other simulators can be very pricey.

Not just reading about it.  I know some of the people.  We meet 
at conferences, at committee meetings, .....

Free software is all about community.  What features you get 
depends on who participates in the community, and how they 
participate.

The plugin system is intended to make it easier for casual users 
to participate in the community.  You can participate this way, 
or by funding some of the work you need.  A little bit goes a 
long way.



_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user