Hello. This is probably for Tim. I have found the ngspice extractor line-wrapping inconsistently. This odd behavior makes it difficult to debug both designs and some of the issues on this thread because file compares yield essentially false positives. For example, this morning and just now the extractor yielded the two pairs of wrapped lines below. Xip_q2w_0 ip_q2w_0/Cl p5T p4T p0T p7T p3T p2T p6T p1T ip_q2w_0/Q0T + ip_q2w_0/S0T ip_q2w_0/S0C ip_q2w_0/Q0C Q0TM S0TM S0CM Q0CM RT1 RT2 Vdd GND ip_q2n and Xip_q2w_0 ip_q2w_0/Cl p5T p4T p0T p7T p3T p2T p6T p1T ip_q2w_0/Q0T ip_q2w_0/S0T ip_q2w_0/S0C + ip_q2w_0/Q0C Q0TM S0TM S0CM Q0CM RT1 RT2 Vdd GND ip_q2n, which are the same text but wrapped at a different point. Is this a known feature for some reason and can I turn it off?

It's certainly not intentional, and I don't have any idea why it would wrap the same text differently. The relevant code involves the variable "tchars" in ext2spice/ext2spice.c lines 1600 to 1605, and always wraps whenever the line length is found to have exceeded 80 characters. I'm trying to think of any way that code could produce a different output for the same input, but I'm not coming up with anything.

Tim, if you are open to an extractor option, I suggest an option for a "sorted" .spice file. This would be helpful for large analog circuit design. To understand the effect of a small change in the layout of a large analog circuit, a "sorted" version of the .spice file would be kept in version control. After a layout change and extraction, a "diff'' would highlight the small fraction of the circuit where the layout change affects behavior. This would focus debugging an analog layout in a way familiar to software developers. To make extractor output friendly to file diffs requires sorting the transistors (by the labels ending in ^). After sorting, a diff command will show only transistors that have been added, deleted, rewired, or had their parameters changed. (Ext2spice currently outputs transistors in an unpredictable order, so a diff just shows that the lines are in a different order.) There are also strategies for passives. I wrote an ext2spice post processor that sorts this way. I started this slack thread after seeing a bunch of changes due to line wrap -- which is not a circuit attribute.

@Erik DeBenedictis: I do prefer to have output in a predictable order just for the reason you cite---so that other tools can run "diff" in a meaningful way. This is also pretty critically useful for "git", since many changes are introduced into a repository if the order of output lines keeps changing all the time. Since a lot of magic's database is done with hash tables, it's the hash enumeration that causes output to be random. To sort the output, I need to check performance impact, but I don't think there is going to be any particular performance issue with sorting devices in the "ext2spice" output. I do need to come up with some consistent metric to sort on, though. Probably something like sorting on the coordinate position of the device. If you could please do me a favor, create an issue on https://github.com/RTimothyEdwards/magic so that it is logged in the git issue system and I will be less likely to forget about it, which is easy to do for things that are buried in a Slack conversation somewhere.