Re: gEDA-dev: Fwd: google soc

[al davis <ad136-at-NOSPAMfreeelectron_dot_net>]

On Monday 28 May 2007, John Doty wrote:
> >> "A program should do one thing well."
> >
> > The plugins are like separate programs.  The simulator will
> > call it to read any format.  The simulator core will have
> > no file reading capability.
>
> But for your ambitions, it needs:
>
> 1. An internal data representation for *any* data any EDA
> tool might   use.
>
> 2. A plug-in interface capable of passing such data.

That is what I am working on.  The simulator core is just a 
core, like the kernel of an operating system.  Everything else 
is plugins, like drivers and applications.

Each driver and application is like a separate program.  In the 
context of a simulator, that means models, commands, and 
interfaces are like separate programs.

The power of this system is incredible.  Now the DC analysis is 
a separate program, the AC analysis is a separate program,  
Each model is a separate program,  Each file format read or 
written is a separate program. ...

With a good interface, and the core providing the needed 
services, all these become much easier.  With a few wrapper 
modules, it becomes possible to use modules designed for 
something else.

The model and command interfaces have been working for a while, 
and fully pluggable for a few months.  I am now working on the 
interface for getting raw data (circuit descriptions) in and 
out.  Next will be a way to get analysis data in and out.

With models as plugins, many more become available.  It can use 
unmodified spice C models as plugins.  The model compiler (a 
group of separate programs) will enable the use of models 
written in languages like Verilog-AMS, VHDL-AMS, Spectre, 
Saber, IBIS, and eventually others.  Anyone can develop and add 
models, without digging into the core.  This is possible only 
because of the plugin system, and making the model compilers 
separate programs.

With commands as plugins, it becomes possible to do scripting 
beyond what any other simulator can do, and provide any user 
interface you might want.  Anyone can develop and add, without 
digging into the core.  Again, it is possible only because of 
the plugin system.

Having the net reader/writer as a plugin makes it possible to 
read many netlist formats.  The Spectre reader took only about 
an hour to do.  It's a plugin, not part of the simulator.  The 
hardest one is Spice.  There are many variants, and all are 
very irregular.  They can all be plugins, not part of the 
simulator, yet appear to be part of the simulator.  Anyone can 
do this, without digging into the core.

> That's not a focus on simulation: it's a focus on things the
>   simulator should not be dealing with.

The idea here is that with old style architecture, simulators do 
need to deal with this.  That is what limits what Spice can do.  
Every new model adds a new set of name clashes.  The irregular 
format is built in, and hard to change.  It's a real headache 
for simulator developers.  

So the purpose of the plugin system is exactly what you say is 
needed .. so the simulator won't need to deal with those 
interface issues.  It all moves to plugins.

To a user, you don't need to carry the bloat of features you 
don't use.

Back to the original question ..  Dario asked what he can do ...  
I suggested some plugins that will provide functionality that 
is needed.  I want someone else to do it so I can go back to 
real simulation work.

Another related need is for plugins mimicing some of the 
proprietary variants of Spice.

I am excited about the new capability the plugin system is 
enabling.  It is turning out to be much more effective than I 
expected.



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