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
