Need for OrCAD/Allegro importer?

Software
10

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:
    1. Create a new empty project, save it
    2. Save the project again
    3. Close the program, open the file again and save it
    4. Create another new empty project and save it
    5. Check how much the file differs in those four versions (how stable it is)
    6. Add a track and save it
    7. Add a second track and save it
    8. Look how tracks are added, how the record looks like, what parts of the file got updated,…
    9. …

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.

For an more in-depth answere (in german), this is my local copyright law implementation (see https://www.ris.bka.gv.at/GeltendeFassung.wxe?Abfrage=Bundesnormen&Gesetzesnummer=10001848 ). You have to note that other laws like patents and contracts can also apply to software:

Freie Werknutzungen

§ 40d.

(1) § 42 gilt für Computerprogramme nicht.

(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.

5 Likes
11

Thank you for such a detailed explanation.

12

Also keep in mind, the OrCad Capture file format is independent of the Allegro format due to its lineage. i.e. OrCad bought Allegro.

2 Likes
13

Rather, Cadence (Allegro) bought Orcad

14

Close enuff

2 Likes
15

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. :smile:

It will probably take a few months until some basic stuff is available but I will keep you up to date.

OpenOrCadParser
OpenAllegroParser

1 Like
16

Two more hints:

  1. There is a wiki page to collect example boards: https://gitlab.com/kicad/code/kicad/-/wikis/Test-Boards
  2. 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.
2 Likes
17
  1. I didn’t knew about the test boards. Thx. :slight_smile:
  2. 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.
18

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.

2 Likes
19

Alitum gave up trying to reverse engineer Allegro

On the one hand this sounds scary, on the other one, this makes it much more interesting :wink:
Extracta sounds interesting. I will take a look at it. Thx.

20

Yeah, pretty good selling point for KiCad, to have binary file import. :slight_smile:

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.

21

Nah it isn’t about challenge. It’s about correctness. Why risk potential errors when you can just have it generate you ASCII with exactly what you ask for, no ambiguity in determining whether a field is 100% what you thought it was. The Allegro and Capture formats are otherwise very very mean with alot of historical decisions carried along.

22

This has a hint on the data items in a OrCad Capture file. Jump to " Design Database Object Model".
It’s not the actual data structure but it at least shows you what’s in there uniquely.

2 Likes
23

Just found this thread. I am one who is very interested in being able to load my OrCad work into KiCad somehow. My licensed version of OrCad is from 1998 so I will have to cross my fingers that the solution mentioned above integrates with an OrCad that old. Right now, the only export formats OrCad offers in my version is EDIF and DXF.

I’ll install Target 3001 (the new name for Fabmaster software) and try that. And the other suggestions here too.

24

In case you are willing to generate a lot of test files it is definetly possible to parse such an old format. Otherwise it’s hard because OrCAD is only provided in its latest software version and it’s difficult to find designs on the internet, generated with that particular version.

I have seen some ‘older’ designs (though I do not know from which exact version) that have at least the same file structure as todays files. You can figure out if the file uses the same CFBF container by building OpenOrCadParser and running ./OpenOrCadParser --input schematic.DSN --print_tree. If the output is a similar structure, then they use the same container. Alternatively you can send me a schematic file (an empty schematic is already enough) and I will check it.

25

Oh, well, in normal circumstances I would be very willing, however, atm, I’m planning on driving my RV south for the winter so I’ll be on the road for quite a while. So ‘breaking camp’ while dodging rain storms.

I’ll try to get some test files made up soon…between bursts of breaking camp activity.

PS: I installed Target 3001 and initially it had menu items for exporting in different types of formats but it asked me if I wanted to upgrade…which I did. And those menu items were not in the software afterwards.

Okay, attached is a simple OrCAD DSN file.

SERVO.DSN (68 KB)

26

No pressure. Have fun and enjoy your trip. :slight_smile:

Btw. I can verify that your schematic uses the same file container as the latest OrCAD versions. Therefore, I assume/hope, that the file structure is kind of similar.

1 Like
27

Yes, Capture has never changed file format, they only added some new features over time but that’s it. Capture will refuse to load newer versioned files but at the same time opens older ones no problem.

1 Like
28

21 posts were split to a new topic: Implications of Reverse Engineering

29

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.