I wonder whether there is a huge demand for importing OrCAD/Allegro designs into KiCad. The Altium importer is based on reverse engineering the data format, the same should be possible for Cadence’s file formats.
I just want to get some overview how many of you would appreciate an importer like that. Maybe it’s possible to gather some people and do the RE on the file format. Personally I would like to see a direct import.
Please just give a thumbs up in the issue tracker if you like the idea:
Edit:
For those reading this post from the beginning. The relevant repositories for the project are: OpenOrCadParser OpenAllegroParser
v5.99 has fabmaster import. As I understand it, the primary purpose was to give a path for Orcad import: Orcad -> export to Fabmaster -> Import into Kicad.
Not to say that native support would be bad, but have you tried the fabmaster import?
Importers are possible if the commercial format is just undocumented by readable and someone with a license is willing to generate test cases.
If the commercial file is compressed with some unknown method, so essentially encrypted or is actively encrypted, no chance
The strings command on Linux shows some readable ASCII strings in the format, so it does not look like they are encrypted or compressed. At least not the whole file.
It would be super useful if someone knows how to use SKILL/TCL for automated file generation.
Reverse engineering a file is a painstaking process of creating trivial projects and the carefully moving one part by known amounts x or y to see what changes.
An OrCad .DSN file is a compound file containing a multitude of files making up a “database” internally. There’s a structure to it but it’s entirely binary. I went down the path of reverse engineering it a bit since it’s what my company uses for now but got lazy.
Do you mind sharing your work? I think that I will give it a shot but before that, I should consult a lawyer, I’m not completely sure what the German law thinks about RE.
@pointhi I liked your presentation it is kind of an inspiration for this project. Did Altium ever try to sue you or something like that?
I looked a bit into Allegro in the past. I was able to extract some fundamental informations (data-types for coordinates/angles) but not much more. I have to say, my work is only based on existing files and the existing viewer, as I do not own Allegro.
I was able to extract some track information, but my parser was only able to parse three or four tracks in a known data segment. After that it got out of alignment as the records had different sizes. Building a binary parser looks quite challenging after my first try.
If you want to build an importer, those would be my hints:
Settle for ASCII import for the beginning (as done by Altium, etc.), as a binary importer should be able to build on top of this work.
If you want a binary importer directly, create lots of ASCII exports to get a clue how the file-structure might look like. Then export many files with known informations:
Create a new empty project, save it
Save the project again
Close the program, open the file again and save it
Create another new empty project and save it
Check how much the file differs in those four versions (how stable it is)
Add a track and save it
Add a second track and save it
Look how tracks are added, how the record looks like, what parts of the file got updated,…
…
I never got any negative replies from Altium. From a legal perspective, you have to define how you want to apporach the problem. I settled for black-box reverse engineering, as it is explicitly allowed in the EU.
(2) Computerprogramme dürfen vervielfältigt und bearbeitet werden, soweit dies für ihre bestimmungsgemäße Benutzung durch den zur Benutzung Berechtigten notwendig ist; hiezu gehört auch die Anpassung an dessen Bedürfnisse.
(3) Die zur Benutzung eines Computerprogramms berechtigte Person darf
1.
Vervielfältigungsstücke für Sicherungszwecke (Sicherungskopien) herstellen, soweit dies für die Benutzung des Computerprogramms notwendig ist;
2.
das Funktionieren des Programms beobachten, untersuchen oder testen, um die einem Programmelement zugrunde liegenden Ideen und Grundsätze zu ermitteln, wenn sie dies durch Handlungen zum Laden, Anzeigen, Ablaufen, Übertragen oder Speichern des Programms tut, zu denen sie berechtigt ist.
(4) Auf die Rechte nach Abs. 2 und 3 kann wirksam nicht verzichtet werden; dies schließt Vereinbarungen über den Umfang der bestimmungsgemäßen Benutzung im Sinn des Abs. 2 nicht aus.
§ 40e
Text
Dekompilierung
§ 40e.
(1) Der Code eines Computerprogramms darf vervielfältigt und seine Codeform übersetzt werden, sofern folgende Bedingungen erfüllt sind:
1.
Die Handlungen sind unerläßlich, um die erforderlichen Informationen zur Herstellung der Interoperabilität eines unabhängig geschaffenen Computerprogramms mit anderen Programmen zu erhalten;
2.
die Handlungen werden von einer zur Verwendung des Vervielfältigungsstücks eines Computerprogramms berechtigten Person oder in deren Namen von einer hiezu ermächtigten Person vorgenommen;
3.
die für die Herstellung der Interoperabilität notwendigen Informationen sind für die unter Z 1 genannten Personen noch nicht ohne weiteres zugänglich gemacht; und
4.
die Handlungen beschränken sich auf die Teile des Programms, die zur Herstellung der Interoperabilität notwendig sind.
(2) Die nach Abs. 1 gewonnenen Informationen dürfen nicht
1.
zu anderen Zwecken als zur Herstellung der Interoperabilität des unabhängig geschaffenen Programms verwendet werden;
2.
an Dritte weitergegeben werden, es sei denn, daß dies für die Interoperabilität des unabhängig geschaffenen Programms notwendig ist;
3.
für die Entwicklung, Vervielfältigung oder Verbreitung eines Programms mit im wesentlichen ähnlicher Ausdrucksform oder für andere, das Urheberrecht verletzende Handlungen verwendet werden.
(3) Auf das Recht der Dekompilierung (Abs. 1) kann wirksam nicht verzichtet werden.
Paragraph $40d.(3).2 tells me that I’m allowed to analyze the behaviour of a program when I interact with it as a normal user would do. Also, this right cannot be contractually excluded, as many propertiary software licences try to do. You might now wonder if this includes analyzing the file structure, but I would argue that there is no copyright on them (excluding fonts,…) from the software-company at all. Simply, because copyright requires some sort of creativity, which a file structure does not have. (the code to create and pars them has a copyright, but not the result) The copyright of a file should only belong to the creator of the file, whose creativity was saved in it. (e.g. the actual board). I’m not 100% sure of this interpretation, but if this fails you have the practical problem that the software-company might legally be able to disallow you from possessing your own files, as they hold copyright on them.
Assuming, you cannot do black-box reverse engineering of the file, there is still paragraph $40.e which allows decompilation. It is only allowed for interoperability reasons (I would argue that file-import is a interoperability reason), you have to limit yourself to the relevant code parts, own the program, you might need to ask the company for ressources first before starting,… I would say lots of things to consider, so this is definitly a thing where a lawyer is good. You also need to be sure that you are allowed to share your results (as required for OSS) and that you do not make a copyright violation in your own parser. Simply reading source-code has the chance that you reproduce the code in a look-alike manner, which is very problematic. Thus, if you do white-box reverse-engineering, one person should write a specification of the file, and a different person has to implement a parser based on the specification, to prevent this problem from happening. This is also called clean-box reverse engineering.
Just a disclaimer at the end: I’m not a lawyer, and this text is based on my limited law-eduction from my sofware engineering studies. It can always change, and the conclusios here are mainly for the shared EU implementation of copyright.
I will work on reverse engineering the formats in the following two repositories. Everyone is welcome to contribute some code or create an issue for some insight into the format. Creating some test files is also appreciated.
It will probably take a few months until some basic stuff is available but I will keep you up to date.
If possible, I would suggest http://kaitai.io/ to document the file format. You can automatically create parsers from the schema and the stuff is way more readable than C++ code for a POC.
I have worked with Kaitai in the past, so I will definitely use it in the beginning. For more complex projects or weird data structures it becomes more tedious in my opinion. Let’s see how far I get with Kaitai.
For the record, even Alitum gave up trying to reverse engineer Allegro and they require you to have Allegro installed to be able to invoke it to import the data.
The Altium Designer Import Wizard can directly import Allegro ASCII format PCB files ( *.alg ) and Allegro footprint files (*.dra). To import a binary Allegro PCB file ( *.brd ), the file must be translated from binary to ASCII. The binary-to-ASCII translation is performed by the Cadence utility called Extracta, a configurable command-line utility that is capable of extracting and translating data from the binary PCB file, with the extraction process controlled by a Command file that details the data required to be extracted. Learn more about Extracta.
Yeah, pretty good selling point for KiCad, to have binary file import.
For Altium it may have been just too bad cost/benefit ratio when the ASCII format is available for many of their customers. It doesn’t mean their engineers had to give up in front of impossible challenge.
