gEDA-dev: Fwd: google soc

[John Doty]

On May 28, 2007, at 9:45 AM, al davis wrote:

> 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.

We already have operating systems. We don't need another.

>
> 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.

You are trying as hard as possible to convince me that this is all  
vapor, aren't you?

>   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,

I blew $100 on that Verilog-AMS book you recommended. Yuck. Too much  
hype, too little substance (this seems the defining characteristic of  
the Verilog-AMS community). The authors seem clueless about actual  
mixed-signal design. It isn't just computer programming...

> 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.

No they don't. The simulator does not need to see my telephone number  
from the title frame. It needs to see the stuff gnetlist extracts.

> That is what limits what Spice can do.

SPICE put my dreams into space and my kids through college. It's easy  
to criticize, but hard to beat.

> 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.

I'm mostly a simulator user. It appears to me that simulator  
developers don't even understand what gives users headaches.

>
> 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.

No it doesn't. In your approach, the simulator has to deal with the  
*union* of all the plugin data structures. How is this better than  
gnetlist? gnetlist is radically flexible and very effective at its  
one job.

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

gnetlist isn't bloated.

>
> 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.

Quit the hype and design a real circuit, show us how it's done. Then  
maybe you'll convince skeptics like me.

John Doty              Noqsi Aerospace, Ltd.
http://www.noqsi.com/
jpd at noqsi.com