gEDA-dev: Re: GEDA development ....

[al davis]

On Tuesday 08 May 2007, John Doty wrote:
> On May 8, 2007, at 9:31 AM, al davis wrote:
> > The bit about compatibility of file formats is one reason
> > why I brought up VHDL, the structural subset, a while back.
> >  Verilog would work too, but require a hack to work around
> > the missing entity/architecture feature.
>
> That's what's making me nervous. We have been extremely well
> served in gEDA by custom open file formats designed for
> specific parts of the flow. For capturing the abstraction
> beneath the drawing, gnetlist is a work of genius. Even this
> old grey haired physicist's rusty, barnacle encrusted Lisp
> suffices to coax out netlists in any format I've been able to
> get documentation (or even just an example) for.
>
> I have that book you have on order. Maybe next code sprint
> I'll try to cons up a Verlog-AMS gnetlist back end.

It's almost done.  Just add attribute passing to the existing 
Verilog back end.

> I was burned by EDIF back in the 90's. Huge waste of time and
> money.

I remember EDIF too.

> It worked much better just to translate one tool's netlist
> into the other's format with an AWK script. So pardon my
> skepticism.

With some cleverness, we can get back to having translations 
simple enough that an AWK script will do it all.

> >   Unfortunately, most people here
> > don't understand the problem, don't follow leading
> > developments in EDA, and don't see where they are looking
> > to us to lead.
>
> If where you're leading is a better simulator, I'm
> interested. If where you're leading is breaking gEDA's
> flexible modularity to better support your vision of a better
> simulator, I'm opposed. Remember, your problems are different
> from my problems.

The problem with Spice is that it is not flexible enough.  It 
might be flexible enough for you, but lots of people bump 
against its problems on a regular basis.  That's why there are 
others like Spectre, Touchstone, Hyperlynx, Nano-sim, Rice, and 
many others.

What I want, and the way gnucap is going, is to be more modular, 
and so more flexible.  Gnucap now accepts Spice C models as 
plug-ins.  The current development effort is on "language" 
plugins, so it can easily cope with the many formats that come 
and go.  The Spice compatibility won't be just "Spice", but 
several plugins for exact compatibility with several variants 
of Spice.  Since the language is not built into the simulator, 
you can have language plugins for any language you want.  I 
expect soon to be able to read and write gschem format and pcb 
format directly.  With not much more effort, maybe Touchstone, 
Spectre, and Qucs formats too, but only after the framework is 
in place.  You will be able to have all this without 
recompiling, without waiting for another release of the 
simulator.

"gnetlist" does one kind of translation.   ..  From gschem out.  
I was addressing all the others.  The concept I proposed is to 
translate in two steps.  In to a common interchange format, 
then out.  That way we need only 2*n translators, instead of 
n^2.  I want to make it easy to support many formats, without 
adding the baggage of carrying them all.

The only thing stopping us from having full board simulations, 
with parasitics, is the lack of the appropriate translator, 
between two of our own formats.