Re: [Gnucap-devel] Ideas for the GSoC

[al davis]

On Tuesday 25 March 2008 19:50, a r wrote:
> What gnucap is missing (from the user perspective) is mostly support
> of external tools. 
agreed!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

> There is no good schematic editor and gnucap 
> netlister (you may try gschem or oregano - YMMV),

In both, there is a netlister, but it has issues.  I have been aware of 
them for a long time.  Notice .. fixing this is what I put at the top 
of the list.  I use gschem, but always need to be aware of the 
netlister's behavior, and often need to manually edit the netlist.  
Certain people in gEDA don't seem to realize how much this detail is 
hurting.  It's not just gnucap.  I hear it all the time, from people 
who wish they could use gEDA but can't.  (and from people who wish they 
could use gnucap but can't)

As far as gnucap is concerned, the file translation must be extendable 
to lots of formats.  Just translating from gschem doesn't do it.

> there is only a 
> simple (although functional) viewer (gwave), there is no 
> co-simulation capability with other tools tools (octave, icarus).
These are all on the list!

> Finally, it would be nice to have a wrapper (for starting jobs in
> parallel on multiple hosts and nontrivial signal postprocessing), 
I hadn't thought of that one.

> no 
> support for binary output formats, 
I didn't list this one yet, because I want to do output plugins, then it 
will be easy.  I know it is needed.

> no up-to-date documentation, 
The snapshot is in a state of flux.  I agree that it MUST be done before 
the "stable" release.

> no  
> website where users could exchange ideas/models etc (ok, there is
> this mailing list).

Introducing:
http://wiki.gnucap.org

Let's develop it into that website to exchange ideas, models, etc.

You need to create an account.  Then you should be able to edit.  I am 
somewhat concerned about vandalism, hence the requirement to create an 
account.

> Those are the real missing bits, and if anybody 
> can handle some of them it would be a big help to the community.

Yes .. and they can be done in little pieces.

> On the other hand, gnucap itself is missing many core features. The
> most important one is robustness and stability of the existing code.

I know.  Parts are super reliable.  Other parts are horrible.  In the 
stable version, the biggest problem is models.  In the development 
version, we are making progress, but there is so much that is new that 
there are many surprises.  That's why I haven't released a stable 
version in a while.

> There are also plenty of possible usability extensions (probes,
> parameters, partitioning, input and output format support). And there
> are analyses - I would settle for good support for transient and AC
> (stb?) simulations. 

What I need most to improve the transient analysis is examples of 
circuits that have problems, or can be used as benchmarks.

> Perhaps noise.  

Porting the Spice algorithm is doable in a summer, and could be a good 
SoC project.  It will be a plugin.

> If someone wants to add periodic 
> analyses - great, but please, do it in a separate code base
> (GnucapRF?). However, I can't help the feeling it's better to leave
> work on core features to Al.

That's the idea of plugins.  The core must be extremely robust, but 
anyone can make plugins.  Plugins can be experimental.  So, periodic 
steady state will be a plugin.

There are often contributions that are useful and should be shared, but 
not necessarily proven enough to go into the core.  With plugins, we 
can have the best of both.

All of the projects I suggested are either separate programs or plugins.

I am trying to get through the infrastructure issues, so I can get back 
to the core and do what I originally set out to do.

Thanks for the comments.  I agree!!

al.