Re: gEDA-dev: gnetlist as one way path?

[John Doty <jpd-at-NOSPAMwispertel_dot_net>]

On May 31, 2007, at 1:12 PM, al davis wrote:

> On Tuesday 29 May 2007, John Doty wrote:
>> 2. Guile data structures are themselves flexible and
>> completely   extensible. They are easy to store portably in
>> files. This could give us a *neutral* file format for design
>> data interchange. This seems much better to me than adapting
>> a drawing, layout, or simulation format to cover all of these
>> bases. Use a format simply designed for representing data.
>
> I thought of that.  Actually, a long time ago.
>
> If it is simply a dump, it is not truly neutral.  It ties us
> into Guile.

You and I mean different things by "neutral". I think the format  
should have a foundation unencumbered by any model of what the data  
means. We provide the meaning (and can therefore extend wherever we  
need to go). That's "neutral" to me.

>
> The solution to this one is simple.  Adopt a syntax, perhaps
> XML,

Neutral but clumsy and incompatible with what we've been doing.

> perhaps C-like,

Eh? C is a programming language, not a data representation language.

> perhaps Guile-like, to represent the data
> structures.

Guile has some advantages here:

1. We're already using it with great success. It ain't broke, don't  
fix it.

2. It's neutral in my sense. And my objection to C (it's a  
programming language) really doesn't apply to a Lisp dialect: program  
and data are fundamentally the same thing. But Lisp as data  
representation is more neutral than Lisp as program representation. A  
data dump from Guile should be readable by other Lisps, although the  
functions that interpret it might not port.

>
> "Guile-like" is especially interesting in this context because
> it is really your suggestion with some extra rules.
>
> Now, look at other languages (C, C++, Python, ...) and you will
> see that on a fundamental level, they are all the same:  A list
> of objects with connections and attributes.  It can be
> recursive.

C and C++ are unsuitable because there's no common portable  
representation of internal data.

>
> So, look around for a language that is fully documented, with a
> published standards document,

A portable implementation is more important.

> and has an existing user base
> that is designed to represent this.  Give a bonus if the
> existing user base includes EDA.

A bigger bonus if the existing user base includes gEDA.

>
> I found one!  It is called VHDL.

Not neutral. Tied to a particular set of hardware description ideas.

>
> To be honest here, I think Guile data structures in Guile syntax
> is actually a nicer format.  Maybe I should take it a step
> further and say that the VHDL format is aesthetically horrible.
>
> One apparent problem with VHDL (and also Verilog) is that the
> true hardware description base is only a small piece of the
> total, and most literature on it only devotes a page or two to
> this (structural) part.  This is a distraction, not a real
> problem.
>
> There are some other formats that come close:  Verilog, TCL data
> structures, XML, ...  (each a little farther away)
>
> So, suppose we pick one, (maybe even guile-derived) and adopt
> it.  To get buy-in from others, including developers who would
> like to join us but see problems, we need to fully document it
> as a language standard, so the language rather than the tool
> becomes the common point.
>
> What's the response I see or hear, outside of gEDA???
>
> VHDL ... not much to do here.  Just define what subset we are
> using.  VHDL was not designed as a simulation format.

This suggestion reminds me of the astronomical data file standard,  
FITS. FITS was designed to represent rasters, but extended to  
represent arbitrary data. The trouble is that when you use the  
extensions, the standard ceases to mean much. You just have a useless  
capsule around something that needs special treatment anyway. It's  
general but it's not neutral.

>
> Verilog ... The committee is receptive to the idea, and would
> probably incoporate what we need into the official standard,
> with the possible (likely) side effect of gEDA becoming
> recognized as a serious player.  Verilog (including AMS) really
> was designed as a simulation format.

Not neutral.

>
> TCL?  huh? (except among old Bell Labs people)
>
> XML ... This one is the source of lots of entertainment in the
> EDA industry.

Neutral but clumsy and incompatible with what we've been doing.

>
> Guile?  ...  oh .. scheme  ....  "skill"  ...   Cadence!!!

I don't know what point you're trying to make here.

>
> and for completeness:
> the format promoted by "si2" under "openeda" ... Like the
> Microsoft/Novell deal "helped" SuSE.

You left out EDIF (shudder).

>
>
> But whatever the choice, VHDL and Verilog (structural subset)
> are required end points, and we need to be disciplined enough
> that any of these would work, and be just an AWK script away
> from any other.  What is most important is just to have one.

Seems to me we already have it, we just never dump it to a file. But  
that's trivial.

>
> .. and remember that if the new one doesn't work, you still have
> the old one.

Maybe. Unfortunately, software rots.

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




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