pcb-rnd knowledge pool


The FOSS EDA ecosystem: common interchange file format

ecosys_edacore by Tibor 'Igor2' Palinkas on 2017-02-13

Tags: insight, ecosystem, compatibility, tools, export, import, convert, bridge, file, format, file format

node source



Abstract: EDA ecosystem proposal: interchange file format.


The EDA ecosystem is booted up and is called coralEDA.

History and background: there is a lot happening in pcb-rnd these days. As of early 2017, a set of these seem to nicely connect up and form something that's a big portion of the edacore idea, just implemented in a different way. We did not have a grand edacore-like plan behind these, they mostly started to happen independently. But they really happen to connect that way. In the same time edacore seems to be in hibernation. When I realized this, I contacted the edacore people to find out if they are interested in a reboot. But we decided to walk separate ways.

This is not an edacore reboot, just happens to have similar goals. This effort is called "EDA ecosystem" .

This article focuses on how the ecosystem idea differs from edacore and other similar ideas floating around these days.

Acceptance and mutual respect

Before we start, we must accept that we have alternative implementations, different projects going in different directions. Although this means code and effort duplication, this is not a bad thing, this is a good thing . Most of us don't want to live in a world where there's only one EDA software available, even if every development effort is concentrated there. (If you think you do, then rethink it with substituting your favorite package with one you really dislike and imagine that's the only one available.)

Respecting the choices of another project seems to be simple in theory, but it is important to see a few examples of what we need to accept in practice. Else we make decisions that are unacceptable for one project or another too easily. An incomplete list of examples of what differs in another EDA project:

In practice this means if we are to do anything common, shared, we either accept the ways of the other projects and come up with a minimal common denominator or the common/shared effort will be refused by some (or even most) projects we target. This has a few consequences, some requirements we must obey while designing the common:

What we could do within these limits?

These problems are not new. There are good examples on how people have solved these in the past - some examples implemented decades ago and are still widely used in one form or another! The most trivial of these are network protocols: SMTP, ftp, HTTP, TCP/IP, the IRC protocol, etc. What's common in them:

This is a pretty important difference compared to the original edacore idea (of the 2015 FOSDEM talk: "we should try to write a lib and give that to the common"). Instead, in the ecosystem idea, we should:

In other words: solve the interchange problem, not the code duplication problem !

What we don't need to do?

We could also do any of these, but to get the project started and be useful, we are not required to do them. It's an important consideration: we don't have much resources, we should spend it where it's spent the best. I believe we don't need to do the below in order to get the ecosystem idea work:

What we could expect from such a project?

Assume we designed a set of interchange formats and maybe mechanisms and we optionally provided some libs and tools.

What we should NOT expect from such a project?


We are trying to show good example with pcb-rnd , which is compatible with a wide variety of open source and proprietary EDA systems and file formats.

I've designed a minimalistic interchange format called tEDAx .

We are also running edakrill , an EDA and format agnostic data sharing service.