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

[al davis <ad136-at-NOSPAMfreeelectron_dot_net>]

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.

The solution to this one is simple.  Adopt a syntax, perhaps 
XML, perhaps C-like, perhaps Guile-like, to represent the data 
structures.

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

So, look around for a language that is fully documented, with a 
published standards document, and has an existing user base 
that is designed to represent this.  Give a bonus if the 
existing user base includes EDA.

I found one!  It is called VHDL.

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.

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.

TCL?  huh? (except among old Bell Labs people)

XML ... This one is the source of lots of entertainment in the 
EDA industry.

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

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


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.

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


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