gEDA-dev: New diagram (attempt at UML)

[al davis]

On Wednesday 11 April 2007 16:50, John Doty wrote:
> But I have to see some purpose to the effort. Is gnucap
> moving in a   direction that is *practical*? I'm not a
> corporate manager who wants bullets for his powerpoint: I
> want something that will help me do astrophysics. I use gEDA
> because, in the end, it is very practical for the things I
> do.

I think it is.  I would not put any effort into it if I didn't 
think so.

I had a few dead years, mostly due to a job problem.  I am 
starting to come out of it.  I did get rid of the job that was 
causing the problems.

The intent is to provide a comprehensive, extendable simulator 
to move us beyond spice, to move into the turf that is owned by 
commercial simulators like spectre and nanosim.

The appearance to a user will be customizable through plugins.  
This capability is growing rapidly and will continue to grow.  
The current development snapshot will take unmodified spice 
models (C-code) as plugins.  So, to download there is the core 
3 sets of models, and one with added features.  One of the sets 
of models is the full set of BSIM models, including the latest.  
Another is from ng-spice.  There are more coming.  

I expect to have a way to use everything that is available, 
regardless of language.  I don't want to port everything.  I 
want to make an environment where they all just work.

The intent is to be able to accept lots of different formats, as 
plugins.  The interface to any particular format is in a 
plug-in, so it can grow.

One of the problems with Spice is that to make any significant 
changes, you need to dig into the core.  If someone contributes 
a change, do you include it?  What about quality, importance, 
etc?  With plugins, anything can be added, regardless of 
quality, ownership, license, or whatever.

Even if you choose to continue with Spice style netlists, you 
still benefit.  First, they are not going away.  Second, since 
the format is defined in a plugin, now exact compatibility is 
possible, with several choices depending on which spice you 
want compatibility with.  The missing models can be defined in 
Verilog-AMS, compiling to a plugin, which can be automatically 
attached.

With Spice, if a model is missing, there is not much you can do.  
If you have a netlist for one spice and have another, you tweek 
it, or maybe hit a block you can't handle.

There are also other formats like spectre, touchstone, and qucs.  
There is also the possibility of reading gschem and pcb files 
directly, all defined in those language plugins.

The idea here is that I am working on providing a core that 
makes these extensions possible, and moves them into a domain 
where users can add what they need.  In time, there will be 
many tools to help you do this.  Some will be made specifically 
for gnucap.  Some will be made for something else, but because 
the plugin system is so flexible they can be used.

If somebody wants to do it, it should be possible to make a 
plug-in that makes gnucap look exactly like ng-spice (or 
Hspice, or Pspice ...)  ..  But it has to be a plugin, because 
whatever way you choose today is not the way for everyone.

Going back to your question ...  
>  Is gnucap
> moving in a   direction that is *practical*? 

That is one of the reasons I seek your help, and the help of 
everyone reading this.  The way to make sure it moves in a 
direction that is practical to you is to participate, to try it 
and let me know what you like and dislike.  To let me know what 
you wish you had, even if you think it is impossible.  That is 
what will determine if it moves in a direction that is 
practical.

You won't use all of the features.  Part of the reason for 
plugins is so you are not burdened by what you don't need.  
Another reason for plugins is so anyone can add features, 
including ones that I never thought possible.