| Thread Previous • Date Previous • Date Next • Thread Next |
Remy wrote:
Hi, 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 related sofwares. 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 alot 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!!! Greetings. Remy.
Remy,
From my experience, the surest way to create a standard file format isto 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
diam="12.5" 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 problem. 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 parsers.
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 roadmap.
Jean-Pierre, what are your thoughts on the current *.brd file format? Would you want to stay with the current format forever, or possibly change it?
Dick
| Thread Previous • Date Previous • Date Next • Thread Next |
