Schematic interchange format

[hpretl]

I think currently there is little need, but: if Xschem could read and write the EDIF format (https://en.wikipedia.org/wiki/EDIF) and other open-source tools (I am thinking of Qucs-S) could read and write this format too, then we could nicely bring schematics from one tool into the other, w/o the need to resort to SPICE-netlist only.

@StefanSchippers What do you think? Is this something that you would eventually want to support? (Given that other tools also support this?)

I have to admit I have not looked into EDIF much, so I don't know if there would be any technical drawbacks when using this format to transfer schematics between tools.

[StefanSchippers]

The history of EDIF is not so bright. Edif 2 0 0 had a very loose semantic, so it was possible to describe the same data in different ways (It's like a piece of LISP). Many EDA vendors provided at the time EDIF readers, almost none provided EDIF writers (they essentially wanted to lock -in their user base).
EDIF 3 0 0 was created in 1993 to fix the looseness of EDIF 2 0 0, It became a standard, IEC 61690-1 , and was published in 4 volumes (!). EDIF 4 0 0 was added with more constructs for PCB in 1996.

My thougths on EDIF:

• EDIF is essentially a DInosaur. Too old.
• EDIF 2 0 0 and 3 0 0 are not at all compatible. The first was too loose, no clear indication of what tags to use to describe things, the second was reputed as too complicated to work with.
• It is now bitrotten, according to Wikipedia: "Since the release of EDIF 4 0 0, the entire EDIF standards organisation has essentially dissolved. There have been no published meetings of any of the technical subcommittees, the EDIF Experts group, etc. Most of the individuals involved have moved on to other companies or efforts. The newsletter was abandoned, and the Users' Group no longer holds yearly meetings".
• It's "too European", that means, 6000+ pages of language specificaton that you have to pay to get a copy. Too abstract, over complicated, over everything. I have considered many times 25+ years ago to read EDIF, but I never found a single example, so I many times gave up.

My thoughts for tool interoperability:

• I think more modern tool-neutral descriptions of circuits can be done using modern data interchange formats, like YAML or JSON. Many young people here could probably code a reader or a writer from/to other EDA tools in few days, given the support libraries (python but not only that) that are available.
• I should avoid XML. It should fit the bill, but in my opinion XML achieved two negative goals, being both difficult for humans to read and difficult for computers to parse. Too verbose, leads to horrendously big files.

[hpretl]

Thanks for your perspective on EDIF. So let's forget it then. Maybe tool-to-tool conversions could be good enough for quite a while. So far, I think it would be sufficient to have xschem2qucs and qucs2xschem. And once more tools would be interesting for exchangability, a new intermediary format (like you describe) would be make sense for several to support.

[hpretl]

So let's close this issue on EDIF.

[StefanSchippers]

I am open to do something to interchange circuits with any other tool. May be we can have a discussion about the best approach to follow. I am almost sure we don't need EDIF. There is no "real" open source interchange format to date as open source EDA tools are very new, and proprietary EDA vendors are not interested to do anything on this. They'll do some marketing by flaunting interoperability, but in reality it's just fluff

So we can as open source come up with a simple and documented format for this task. Perhaps we can fit the doc in 4/5 pages and not in 4 volumes!.

I think it is a good time to consider this, as new (m) tools are coming into the arena and we probably want to avoid the (m - 1) x (m - 1) translators.

[hpretl]

That would be really great to have! For layout, we have GDS/OASIS/LEF/DEF (not perfect but existing), for netlists we have SPICE and Verilog (not perfect either, but existing), but for schematics and symbols there is a gap.

[StefanSchippers]

Exactly. there are perfect interchange formats for layout and simulation , yet there is a gap for schematics.

It is not easy, as in general to read a schematic you need to read and translate also the used components.
Something like that was done to read GEDA schematics, the importer in xschem is almost complete, but as the GEDA project is not very active I think nobody used it.
But was a nice test case and was not terribly difficult.
If the foreign file format is documented everything is much simpler.
https://xschem.sourceforge.io/stefan/xschem_man/tutorial_xschem_slides11.png

[kwmartin]

I pretty well agree with what Stefan is saying; especially regarding not using EDIF. I am in the latter phases of debugging the port of my libraries from Viewdraw to xschem, so I am somewhat familiar with xschem schematic and symbol semantics (ditto for Viewdraw). As part of this port, I have a personal standard for describing hierarchical structures and connectivity that is yaml based. It somewhat follows the verilog standard for structural blocks. It basically allows for input, output, and ioports ports that are buses, sub-components, and concatenating sub-nets at circuit bus inputs. I'm also hoping to use it for some (for fun) simulators I am playing with (one in julia, one in C). I have iterated on the standard a few times, and it seems to be standing up and is relatively clean and simple (at least in my biased opinion?). This could be a reasonable starting point. If there is any interest, Steffan, could you suggest where to put it (I'm not familiar with Sourceforge, but could become so). I could put together an initial spec document (in markup?). A moderately complicated block that is part of a complex direct frequency synthesizer can be down-loaded from sine.yml. Ignore the functionality, but it has enough to give an idea of the current syntax (it doesn't have sub-circuit parameters in this example; I have other examples that do). I have used it as input for my toy simulators, so it has been exercised at least a little.

[StefanSchippers]

@kwmartin I think github is the best choice. Create a project repository on github. This is what most of the people use I think.

The example sine.yml is on a google drive I am not able to access even if logged in into google/gmail.

[kwmartin]

The google drive link to sine.yml is supposed to be accessible to everyone for download unless I got the permissions incorrect. I actually asked perplexity what was the preferred location to put a file for downloading and perplexity said google drive was preferred as github is primarily for project management not for general download.

[StefanSchippers]

I understand, but this is what I get when I click he link to sine.yml.
I am already logged in to google in the browser. HTTP error 403 is an authorization problem.

If the file is small you can simply put it here as text using the code formatter