kicad-developers team mailing list archive
Mailing list archive
Re: EDA in a better (open and free) world :-)
Defining open formats for schematics, libraries, netlists, PCBs,
foorprints, projects, routers input could be (very) interesting for
kicad users, as well as gEDA, QUCS, KTechLab, FreePCB, and other EDA
Unlike commercial sofware companies, free sofware is not interested in
keeping users trapped in one sofware only.
These formats could be a strength :
- everyone using one of these tools would be able to use the most
interesting for a project.
- People in a common project could use different tools, maybe on
different OS, everyone using the "best" software, knowing that the
best is often the one we usually use.
- As far as I know, no EDA suite can cover every aspect of electronic
design : the simulator, or the autorouter, or something else is
missing, or not as good as we want.
- Using a common and open file format would reduce the time spent in
creating efficient and bugsfree format translators, especially between
free and proprietary file formats. The work can be shared between the
different EDA software developpers.
- using a common format could incite our preferred magazines to adopt
these open formats. In particular, it is very annoying to have a PCB
design with components impossible to find (i.e. I'm unable to find
that power connector with the footprint in this PCB... but I have a
lot of other power connectors that could suit for this usage!). In the
same way, there's a lot of sites (the electronic cookbook,
universities, private individuals...) offering thousands of
interesting projects, but in a number of "static" file formats :
impossible to modify anything, schematic or PCB.
- common libraries, well organized and online (some kind of
superkicadlib.org ;-) ), for schematics as well as for footprints.And,
why not, an online tool to search and import!
- ability to use different autorouters, because they have different
abilities and... prices, for different usages (hobby or pro).
The first step in this better world is about to be done with the
Specctra bridge. Thanks Dick (and others?), for all that work.
Of course, it may exist some reason that the idea is not convenient :
please feel free to tell us what could be wrong!!!
From my experience, the surest way to create a standard file format is
to capture the dominant market share. (But wait, is capturing market
share a sure thing? No.) So while I agree that there would be value in
a common format, convincing the world to do it is nearly impossible.
For if this were easy, worldwide we would already be speaking one
language and all using the metric system.
I have a few things to say about Kicad's *.brd file format and all the
work that is being invested in it currently:
1) It is not self documenting. There is a tendency to think that
because it is ASCII, there are no secrets. While that may be true, in
Kicad's format, *there are also very few hints*. By comparison, an XML
file or a SPECCTRA DSN file has plenty of self documenting hints. For
example consider an XML attribute like
this is self documenting.
2) It is not arbitrarily extensible. Each extension of the format
requires too much careful design thought. By comparison, an XML file or
the DSN format is far more obvious, particularly when it comes to
nesting elements within elements.
3) All the work that is being done now on conversion programs which
write directly to the *.brd file format are precariously vulnerable to
any future change in the *.brd file format. I see recently that klui
wrote a drill diameter consolidator that spits out a revised *.brd
file. Well when and if the *.brd file format were to change, this
utility would instantaneously encounter a problem: its output files
would be obsolete, if not its input files. This is exactly the reason
I wrote the SPECCTRA code so that it is not an external program which
accessed a *.brd file. The truth is, my SPECCTRA work knows nothing of
the *.brd file format. It knows only of the internal memory
architecture of a BOARD tree, and in theory it is more immune from
changes in the *.brd format. While this is an argument that all
conversion programs should become integral to Kicad, following this path
to the extreme would lead to code bloat and quality degradation in my
opinion. So what is best? I think Python is the answer here. If we
had a stable memory/document model in PCBNEW, and a Python language
binding, then these conversion programs and utilities could be written
in Python and that code would *not be loaded unless it were needed*. So
it solves the code bloat problem, it solves the file format lock-in
I would suggest that if a file format change were to be done, that it be
done ASAP, and then the Python support be added ASAP, so folks could
start writing these conversion utilities to work on the document model
in memory rather than to/from disk.
What format would be better? A better format would have these qualities:
A) It would be largely self documenting.
B) It would be easily parsed with standard software tools.
C) It would have the capability to represent all the constructs in a PCB
design file, many of which are embodied in the SPECCTRA DSN spec. Not
all constructs would be present in each file, but the capacity to
represent them if needed is desirable.
Two 2 solution paths that should be in the discussion:
1) SPECCTRA DSN with exentions. The extensions would be for text and
for library references and any other required extension we would need.
We could use the same lexer and parser as we use now for the DSN files.
2) XML syntax wrapper around a grammar to be determined. I would
propose a SPECCTRA like grammar (wrapped in XML syntax instead of the
parentheses based DSN). We could use libxml2 or expat which are C++ XML
Kicad has had a SVN repository for only a year now. So I would say that
it is just getting legs. It can and will take on more developers than
it has now.
*But adding developers without a common vision could lead to chaos.*
Therefore this discussion is important because it helps settle the
vision issue before the developers come in larger numbers.
The file format discussion becomes part of a larger vision for the
direction we want to take the project. Such a vision could be called a
Jean-Pierre, what are your thoughts on the current *.brd file format?
Would you want to stay with the current format forever, or possibly