Re: gEDA-dev: Last call for input on SOW for Linux Fund....

[al davis <ad151-at-NOSPAMfreeelectron_dot_net>]

On Sunday 30 November 2008, Robert Fitzsimons wrote:
>  but we need to develop a suitable
> suitable interchange file format, which represents the
> physical component;

I said that a long time ago, and got shot down.

Since then, I have seen so much evidence of the need for it that 
I wonder what we are waiting for.

It's not just layout.  It's not just forward annotation.

The lack of a translator is the only reason we don't have 
post-layout SI simulation, static timing analysis, 
kicad,pads,orcad,eagle import and export, truly interactive 
simulation, and more.


We need a translator system that will go between any source and 
any target in two steps.  Source to the interchange format, 
then interchange format to target.

The system needs to be able to make a lossless round trip.  That 
is, any source to interchange format and back to the same 
source must be lossless.

The system needs to be able to merge changes.  For example, 
schematic to interchange to layout.  Then merge layout changes 
back to the interchange format.  Then generate a schematic, 
which is the original with the changes back-annotated.

The system needs to allow the tool formats to evolve without 
burdening other tools that need to be compatible with it.

The translated file needs to be ready to use if possible, but it 
is unreasonable to expect the destination to have info that is 
not in the source.  For example, if the source is schematic and 
destination is simulation, ALL symbols must be correctly 
translated, no exceptions.  But, it is reasonable for the user 
to need to add a ".model" statement.

The same schematic should work for layout, (any layout), 
simulation (any simulator), bill of materials, etc.


It is best if the interchange format is externally defined, with 
an official document to define it.  It must not be the specific 
format of any tool, but it is ok for tools to adopt the 
interchange format directly.  

There are formats that are already in use by much of the EDA 
industry.  We only need to identify the appropriate one and map 
it to our needs.  Since the  need is to represent structure, 
the structural subset of either Verilog or VHDL are appropriate 
choices. The Spectre format would also work, but it is 
proprietary.  It doesn't matter which one.  They are only an 
awk script apart.

If you look at any of these formats, they are all lists of 
objects with connections and attributes.  Some objects and some 
attributes only have meaning in some contexts.

What is needed to get moving is to define those objects and 
attributes.  Some are obvious.  There is work to be done 
defining how to represent placement and the visual aspects of a 
schematic.

I am willing to do a detailed spec if someone is willing to do 
the code, and someone is willing to figure out how to map some 
of the foreign formats.  I have some code as part of gnucap 
("language" plugins) that can be used as a starting point.


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