From Slack This issue started on Slack and Tim asked me to enter it here. The issue is to enhance the magic-to-spice workflow so .spice files can be kept under version control. Lines are currently output in the order of Magic's internal data structures, often appearing random to the eye, and making diff output unhelpful.
I got engaged with this issue when trying to make and debug a complex analog circuit, which had me pulling my hair out for months, so one day I wrote an ext2spice post processor. I will describe the approach and results here. If this is of interest, I can advise or possibly provide code. It would be preferable for magic to sort as opposed to a postprocessor.
The main issue is the sort order, which I believe should depend on workflow and the device type:
Transistors The fact that a circuit is important will positively correlate with the circuit being in version control and documented in a paper, patent, datasheet, etc. Transistor circuits in documents name transistors using terms like T1, T2, Bias, out2. Magic supports this type of naming through labels with an uparrow/caret (^) at the end.
So, my program sorts transistors is lexicographic order of the label. The **devattr line sticks with the device line.
Wire-to-wire capacitance The objective is a sort order that will cause the version control system to track a capacitor by its function even though its value changes and capacitors are added and deleted in adjacent lines. So, I first interchange the terminals of each capacitor, if necessary, so the lexicographically smaller node name is on the first terminal.
I then sort the capacitors using the two (now sorted) node names as the key. This creates a sort order unperturbed by rotation or reflection of the layout, value change, adding, or deleting additional circuit nodes.
I then renumber the sorted capacitors C1, C2, C3... I then follow each "C" device line with a second line "**node1 node2" as shown in the screenshot. The extra line causes a "diff" program to resynchronize after insertion/deletion and a capacitance value change.
Narrating the capacitor algorithm in the screenshot:
(1) C237 changes from 14.5f to 3.12f based on a user layout change
(2) Ext2spice added a new C238, which will make all subsequent C lines different (so there will need to be a mitigation).
(3) Diff nonetheless recovers synchronization in the area in blue, which you can see capacitors with values 6.64f 2.16f and 7.49f. The capacitors have different "C" numbers but the same connections.
Other devices and design flow The two methods above apply to other devices, but there may be other issues. For example, the source and drain of transistors could be put into lexicographic order to eliminate false positives, but that would require changing parameter names for area and perimeter. In general, I think thought should be given to what designers will want to track and how to lay out the format so readily available "diff" (or version control like github) will work naturally.
Runtime I find "extract all" on a test file runs about 15 seconds and my post processor reports running under .2 seconds.
Further steps Tim, you're the guy that makes the decisions. If you would like to pursue this direction, I have some experience with the approach and could contribute to an informal "design review." I could prepare some viewgraphs elaborating on some of the ideas here.
From Slack This issue started on Slack and Tim asked me to enter it here. The issue is to enhance the magic-to-spice workflow so .spice files can be kept under version control. Lines are currently output in the order of Magic's internal data structures, often appearing random to the eye, and making diff output unhelpful.
I got engaged with this issue when trying to make and debug a complex analog circuit, which had me pulling my hair out for months, so one day I wrote an ext2spice post processor. I will describe the approach and results here. If this is of interest, I can advise or possibly provide code. It would be preferable for magic to sort as opposed to a postprocessor.
The main issue is the sort order, which I believe should depend on workflow and the device type:
Transistors The fact that a circuit is important will positively correlate with the circuit being in version control and documented in a paper, patent, datasheet, etc. Transistor circuits in documents name transistors using terms like T1, T2, Bias, out2. Magic supports this type of naming through labels with an uparrow/caret (^) at the end.
So, my program sorts transistors is lexicographic order of the label. The **devattr line sticks with the device line.
Wire-to-wire capacitance The objective is a sort order that will cause the version control system to track a capacitor by its function even though its value changes and capacitors are added and deleted in adjacent lines. So, I first interchange the terminals of each capacitor, if necessary, so the lexicographically smaller node name is on the first terminal.
I then sort the capacitors using the two (now sorted) node names as the key. This creates a sort order unperturbed by rotation or reflection of the layout, value change, adding, or deleting additional circuit nodes.
I then renumber the sorted capacitors C1, C2, C3... I then follow each "C" device line with a second line "**node1 node2" as shown in the screenshot. The extra line causes a "diff" program to resynchronize after insertion/deletion and a capacitance value change.
Narrating the capacitor algorithm in the screenshot:
(1) C237 changes from 14.5f to 3.12f based on a user layout change
(2) Ext2spice added a new C238, which will make all subsequent C lines different (so there will need to be a mitigation).
(3) Diff nonetheless recovers synchronization in the area in blue, which you can see capacitors with values 6.64f 2.16f and 7.49f. The capacitors have different "C" numbers but the same connections.
Other devices and design flow The two methods above apply to other devices, but there may be other issues. For example, the source and drain of transistors could be put into lexicographic order to eliminate false positives, but that would require changing parameter names for area and perimeter. In general, I think thought should be given to what designers will want to track and how to lay out the format so readily available "diff" (or version control like github) will work naturally.
Runtime I find "extract all" on a test file runs about 15 seconds and my post processor reports running under .2 seconds.
Further steps Tim, you're the guy that makes the decisions. If you would like to pursue this direction, I have some experience with the approach and could contribute to an informal "design review." I could prepare some viewgraphs elaborating on some of the ideas here.