Is there some limitation in using a standard output format like ODB++ as an input file for those design platforms that are not yet supported?
Hi @satauren, thanks for the question!
This was actually the first thing we tried some years ago before deciding to interface with CAD files directly. I really wish there were a truly great, uniform standard that could work for moving board designs between tools - but unfortunately to my knowledge it just doesn’t exist yet.
With ODB++ in particular: ODB++ is meant for standardized export to CAM, rather than to import back into CAD - similar to gerber files. Altium actually wrote some documentation on how one might go about importing an ODB++ file into a PCB file here: https://www.altium.com/documentation/knowledge-base/altium-designer/convert-gerber-odb-fabrication-data-back-to-pcb
Unfortunately, they note quite a few limitations that require substantial manual work. For example: footprints will actually just be primitive polygons that are disjoint. So one would need to re-define all of the footprints and swap them in. Layer stackup elements have to be defined manually - which is a problem because Quilter controls the stackup as a part of the search space. There are also substantial limitations for split planes, pours that have to be re-drawn, etc. Quite simply, ODB++ was just not meant for importing back into PCB design files. It was meant for manufacturing.
The format we took a closer look at before was actually Specctra. At least that one was specifically meant to go to an auto-router, and back into the design tool. Again, however we ran into issues. First, we saw that the way that KiCAD and Altium interpret a Specctra file is different. So to guarantee quality, we would have to have variations that are targeted at different tools. Next, we didn’t see an obvious way to control placement or stack-ups by importing a Specctra file. It really was focused on auto-routers - as that is the product it supported.
In general, file conversions are really tricky and error prone. We would rather have control over the file directly, so that we know we can achieve a perfect result that doesn’t depend on the maintainers of that tool fixing bugs in their importers. In cases like KiCAD for example, this will even allow us to do things like run the KiCAD DRC on our own servers - just to double check that the representation we worked with within Quilter matched the one that KiCAD understands. I’m really excited for that feature as it will really increase the reliability we can deliver in getting a DRC-error-free design to the user.
If I missed any alternatives, please let me know! It’s not fun to support each CAD tool directly - but we think the extra work is worth it to ensure ease of use and reliability for our users.