Open schematic file formats

[Robert.Adams]

Hi everyone,

I've been digging around file formats that are used by CAD tools and I found a decade old project from Upverter that had an open JSON format (https://github.com/machinaut/schematic-file-converter) as an intermediary file format while converting between CAD tools. Their forum (https://forum.upverter.com/t/documentation-for-open-json-format/154) shows that project was moved internally by at the latest 2016.

Does anyone know of any other projects like this? Something that converts various CAD tool formats into one standardized format, preferably one that is easily parse-able?

[PKTKS]

Yes at least a half dozen ones .. some dead some zoombies...
and some defuncts..

http://sk1project.org

ALIVE: https://sk1project.net/

used to be here http://sk1project.org/modules.php?name=Products&product=uniconvertor

https://sk1project.net/uc2/

seems a defunct zoombie although you can still try some repo on line RPM or DEB
i have an old ancient copy ... packed and installed
still alive...

probably the most successful "UNI" converter (see uniconvertor)
yes the syntax is that.. at least last time I checked

Regarding EDA converters the thing exists since 80s and **NONE**
ZERO ZIPPO  manufc are willing to converter "to" others.. just import.

EDIF is de facto (since 80s)  the EDA format but nobody is interested
in using EDIF...

Best folks kindly to EDIF are from Cadence in which former OrCAD EDIF
support is the best possible among all others..

They exist and PYTHON sweat hearts are very enthusiastic thinking
that some py stuff will obliterate the industry nonsense..

yet to see that.. since 80s... nothing tangible,

Paul 

[SiliconWizard]

EDIF would be the de factor standard indeed.

Whereas it's still not widely used, we have to understand why that is so, which is probably going to be a lot more enlightening than trying to devise yet another universal format.

There are standards that are being used though, such as ODB++? It's more for exchanging layout data than schematics though, and it's a proprietary format, but it does contain netlist data IIRC (as opposed to Gerber.) Similarly, there is the IPC-2581 format.

The reason why standards for exchanging layout data have taken off, but not for exchanging schematics are probably rather obvious, but that will at least partially answer the question.

Now feel free to either implement EDIF, or design your own format. The hard part, of course, will be to write converters to and from existing formats, most of which being proprietary, except for KiCad. Oh, and Eagle is not "open" strictly speaking (not quite sure about the licensing), but it's fully documented, it's XML, and it's actually not too badly thought out (talking about the XML Eagle format of course.)

The harder part, too, would be to have EDA vendors adopt this new format.

[PKTKS]

oooo  I bet that they won't  (adopt any other format besides their own)

Regarding GERBERS I think that is probably the UNIQUE common
format among them all..

It would be magic if someone could reverse the GERBER format
into the source ... preferably EDIF (as nobody would like to have
their format excluded)

I bet this will not happen any time soon 
Paul

[langwadt]

EDIF would be the de factor standard indeed.

Whereas it's still not widely used, we have to understand why that is so, which is probably going to be a lot more enlightening than trying to devise yet another universal format.

There are standards that are being used though, such as ODB++? It's more for exchanging layout data than schematics though, and it's a proprietary format, but it does contain netlist data IIRC (as opposed to Gerber.) Similarly, there is the IPC-2581 format.

The reason why standards for exchanging layout data have taken off, but not for exchanging schematics are probably rather obvious, but that will at least partially answer the question.

Now feel free to either implement EDIF, or design your own format. The hard part, of course, will be to write converters to and from existing formats, most of which being proprietary, except for KiCad. Oh, and Eagle is not "open" strictly speaking (not quite sure about the licensing), but it's fully documented, it's XML, and it's actually not too badly thought out (talking about the XML Eagle format of course.)

The harder part, too, would be to have EDA vendors adopt this new format.

"why don't you implement this new format that makes it easier for you customers to switch to a competitor", that'll be a hard sell

[SiliconWizard]

"why don't you implement this new format that makes it easier for you customers to switch to a competitor", that'll be a hard sell

Yep of course...
Now that is a two-edge sword. Making it easier to switch to a competitor potentially makes it easier to lose customers, but also to gain new ones. Whoever would be favored by this in the end is hard to tell, but I think it's now a known fact that excessive competition mostly favors customers, not vendors.

[PKTKS]

"why don't you implement this new format that makes it easier for you customers to switch to a competitor", that'll be a hard sell

Not  a chance in hell...

I 've been through this drama with a dozen folks:
- OrCAD SDT III and  SDT IV  (oo and some modern Cadence era versions)
- Accel TANGO since version 1.x and post versions until incorporated by PROTEL
- AutoTRAX and TraxMaker and PADs and ...
- ALL PROTEL versions until they re branded  to Altium ..
- EAGLE and KiCAD...

One thing I have learned:
- All **ALL**  ALLLLLL  pop and vanish...
- Sticking with a single one is the worst thing one can do.

(I would choose OrCAD if forced to do so... for several reasons)

Once I have learned that .. I have hunted down any possible
ways to convert among them or ... at least between 2.

By this way I could update my old stuff including OrCAD, TANGO
and PROTEL and TraxMAKER and EAGLE... to today.

3 or 4 dozen scripts and methods and countless problems
with the symbol and footprint libraries...

I won't even consider such project unless they **ALL** agree
into a simple industry standard format..  (obviously EDIF..)

I bet they won't. The current economic sales and market model
is not only a fiasco ... but proven already a drama to sustain
in mid term...

I am waiting the next KiCAD juggernaut from the industry
screaming "We can NOT compete with free.." 

Paul

PS> I had a good laughing session reading the post THE CLOWN..
and the NETFLIX  model for EDA...

or WTF is that NETFLIX board PCB...

[SiliconWizard]

Just a note about all this: if you have to switch to a different EDA, having to re-enter schematics (unless you literally have thousands of them) is not the hard part. It's often just a matter of a few hours. The hard part is obviously with all the libraries.

So, much more so than schematics, the really useful feature would be some kind of universal component database format. And, if this format were also adopted by distributors, then it would definitely make both design and supply much easier.

[PKTKS]

Yes the critical part are the libraries...

but not only the library contents... the
format used is also a serious problem.

I remember that by 90s only OrCAD could
actually convert their OLD BITMAP SYMBOLS
to their new vector ones... and even so only
if you had carefully saved the SDT iV cfg file
to allow a secondary library set generation.

These new 3D binded formats made that task
a serious drama.. I had to allocate some hundred
Gigabytes in my NAS ONLY to store alternative STEP
files for 3D symbols and binded footprints...

things are converging fast and WITHOUT a proper
rational agreement.

Paul

[pointhi]

Some people say KiCad might become the future general format EDA programs can import from. At least the format is documented: https://dev-docs.kicad.org/en/file-formats/sexpr-pcb/

There are also already integrated importers for Eagle, PCAD, Altium Designer/CircuitMaker/CircuitStudio, Fabmaster and CADSTAR and some third-party ones. The main problem with EDA formats is something else: data interchangeability. Every program has its own graphic primitives, operating principles and drc/erc rulesets, and you can only lossy convert between them. The first program does not support oval holes, the next one does not support padstacks, and the next one handles zones differently. One uses a clearance matrix, the second one only has some simple clearances and the third one has a complex drc rule language which might or might not be able to be a superset of all other drc rules you can define in other programs.

[Robert.Adams]

Just a note about all this: if you have to switch to a different EDA, having to re-enter schematics (unless you literally have thousands of them) is not the hard part. It's often just a matter of a few hours. The hard part is obviously with all the libraries.

So, much more so than schematics, the really useful feature would be some kind of universal component database format. And, if this format were also adopted by distributors, then it would definitely make both design and supply much easier.

Oh don't get me started on component data formats...years ago I got mad enough at Kicad that I bought a personal copy of Altium just because the libraries were less insane.

It sounds like I have some reading to do on the EDIF data format. In general, I'm not worried about re-entering schematics at the moment. My main goal here is to examine a lot of open source designs and see what I can learn about them. My initial thought was that I wanted to look through netlists to see if it was possible to automatically cluster functions together with a script (e.g. components R1, C1, R2 are used to connect function AIN1 from the micro to a connector, components R3, C2, R4 are for AIN2, etc). The problem here is that most projects don't publish netlists - they publish schematics and board files that are in a wide variety of formats. Earlier today I downloaded 31 .zip files of eagle projects from the Arduino site and I'm not very excited about having to open all of them manually, generate net lists, and then figure out how to cluster them only to find my script only works with their specific annotation or design conventions.

The utility of being able to automatically cluster functions together would be to improve automatic documentation generation like hardware-software interface specifications, worst case circuit analysis, etc.

[Doctorandus_P]

The underlying problem is that manufacturers of commercial EDA programs have no interest whatsoever in tools that make it easy for their customers to switch to other tools.

oooo  I bet that they won't  (adopt any other format besides their own)

Regarding GERBERS I think that is probably the UNIQUE common
format among them all..

It would be magic if someone could reverse the GERBER format
into the source ... preferably EDIF (as nobody would like to have
their format excluded)

I bet this will not happen any time soon 
Paul

KiCad has the ability to take a set of Gerber files and back-import them into a PCB project.
It is of course not perfect, as there is no concept of "footprints" in gerber files and lots of other info is also missing.

Just for fun I got an old Protel project (with ATmega, Wizznet Ethernet controller and chicken fodder to make it work) and made a full KiCad project out of it.
I had a .pdf of the schematic, so that was mostly completely re-drawing it in KiCad (And redrawing from an example is much quicker then designing a schematic, (for which you have to reference datasheets, decide pin assignments etc).

I converted the set of Gerbers back to a PCB. What you get this way is:
* PCB Outline & mounting hole locations.
* All the tracks in copper.
* Locations of all footprints, which are implicitly encoded in the end points of the tracks.
* Netlist, as KiCad can use DRC to check between differences in the schematic and the actual copper on the PCB.

So after re-entering the schematic, I did the normal footprint assignment and got all new footprints for all components. This was badly needed, because I started with a very old Protel project, and it used a lot of "painting" both for big zones and for pads. Each rectangular rounded pad was made up out of 7 or so line segments, but KiCad has a pretty good PCB editor, so those were relatively simple to delete (I mostly used box select, with dragging from left to right, which only selects items that are completely enclosed in the box)

Moving the new footprints to the locations of the old ones was also pretty simple. You just grab a footprint by a pad, and snap that pad to the end of one of the tracks. All copper tracks that get connected to one of the other pads of that footprint automatically get the name of the netlist, and you can use the Ratsnest function to decide which part you'll do next. This builds the PCB and expands the netlist until everything has it's place.

Near the end I did the normal DRC check, and it got me a bunch of errors. Most were from old garbage (the pad painting) which I had not completely cleaned up. But it also caught a few differences between the schematic and the PCB. It turned out I had made a few errors while re-creating the schematic, and DRC caught that nicely for me.

[olkipukki]

So, much more so than schematics, the really useful feature would be some kind of universal component database format. And, if this format were also adopted by distributors, then it would definitely make both design and supply much easier.

Ultra Librarian BXL is most adopted vendor neutral format supported by top manufacturers (TI, Microchip, Analog, Maxim etc.)

[PKTKS]

So, much more so than schematics, the really useful feature would be some kind of universal component database format. And, if this format were also adopted by distributors, then it would definitely make both design and supply much easier.

Ultra Librarian BXL is most adopted vendor neutral format supported by top manufacturers (TI, Microchip, Analog, Maxim etc.)

unlucky me not having such tool way back in 90s to
convert stuff .. all across the 2000s as well.

But 2 things get me really bugged using such tool:
- the first one is requirement to be online and using a logged account
- the second goes together by not having a proper local script or converter

both are counter intuitive in the workflow and when things
are really messed these solutions are more like the NETFLIX thing..

bottom line they are forcing all customers to use THEIR COMPUTERS
and uploading stuff which should not obviously be part of any sane
workflow on EDA...

smells like the NETFLIX nonsense..
however having such tool is a great accomplishment

it would be sane being FOSS and readily available
to compile execute run ... on offline facilities

Paul