I have a question about ext2spice port numbering. The documentation says subcircuit ports will be in the order of the port numbers, but I've noticed that Vdd and GND become the last two ports irrespective of their port number. My question is whether there are other special cases -- or whether I have just not found the right documentation. The problem arises in keeping layouts in synch with designs that originated with ngspice circuits. (In chasing this down, I resorted to editing the mag file to change port numbers more efficiently.)

@Erik DeBenedictis Is this what you’re looking for?

Port order is only violated if magic sees implicit ports---connections to cells further up in the hierarchy that are not explicitly marked as ports. However, I'd have to see the layout to comment on why your power and ground did not end up in the order specified. Yes, sometimes it's easier just to hack the .mag file than to do something in the layout editor. It's true of many applications, and one reason I strongly dislike binary formats.

@Tim Edwards Interesting, I totally missed this feature of magic. In case I only have a symbol view in xschem (because I read in the extracted netlist), is there any option to read that and match thereby the port ordering?

@Harald Pretl: I don't have an equivalent for reading a .sym and ordering ports; I had basically considered that you could just write the netlist from xschem and import that, but reading the .sym directly should be pretty easy to do. Just another file parser.

Thank you for the responses, yet the issue is different. I cut a 18 transistor circuit back to one transistor and a substrate tap. I probably have some sort of error in the construction of the tap due to unfamiliarity with Sky130 -- although there are no DRC errors. If I run extract all and ext2spice, the circuit is correct but the the ports are in the wrong order. The spice is:

@Erik DeBenedictis: I think the issue here is that ports are ordered by an internal index that has nothing to do with the port name. So I think all you want/need to do is to select each port in turn an use the

port index

command; e.g., select port

p1

and type

port index 0

, select port

p2

and type

port index 1

, and select port

p3

and type

port index 2

. This also may or may not have anything to do with the power and ground ports being at the end of the list.

Tim, I don't think this is the issue. I did what you said and the pertinent lines of the mag file are: << labels >> flabel metal2 88 66 88 66 1 FreeSans 80 0 0 0 p1 port 1 n flabel metal1 0 235 0 235 2 FreeSans 80 0 0 0 p2 port 2 ne flabel metal2 19 66 19 66 1 FreeSans 80 0 0 0 p3 port 3 n << end >>

I'm confused then. It absolutely should output the ports in the correct order. . .

I am not familiar enough with Slack to add a file, but the ext file is short enough to paste. The problem seems to be that port P1 got superseded with a_170_590#. Port P1 was then unnecessary and the internal signal got added to the end. timestamp 1683127729 version 8.3 tech sky130A style ngspice() scale 1000 1 500000 resistclasses 4400000 2200000 950000 3050000 120000 197000 114000 191000 120000 197000 114000 191000 48200 319800 2000000 48200 48200 12800 125 125 47 47 29 5 parameters sky130_fd_pr__nfet_01v8 l=l w=w a1=as p1=ps a2=ad p2=pd port "p3" 3 38 132 38 132 m2 port "p2" 2 0 470 0 470 m1 port "p1" 1 176 132 176 132 m2 node "p3" 414 607.785 38 132 m2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 8664 580 0 0 6764 400 4156 268 17624 1236 0 0 0 0 0 0 0 0 node "p2" 200 306.35 0 470 m1 0 0 0 0 0 0 0 0 6800 336 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 2508 208 11928 804 0 0 0 0 0 0 0 0 0 0 node "a_170_590#" 3000 0.44669 170 590 ndif 0 0 0 0 0 0 0 0 400 208 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 substrate "p1" 0 0 176 132 m2 0 0 0 0 0 0 0 0 15000 504 8000 360 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 9568 548 11668 656 26944 1252 0 0 0 0 0 0 0 0 cap "p3" "p2" 59.4899 cap "a_170_590#" "p2" 0.0284137 device msubckt sky130_fd_pr__nfet_01v8 170 412 171 413 l=30 w=100 "p1" "p3" 60 0 "p1" 100 15000,504 "p2" 100 6800,336

@Erik DeBenedictis: There should be a "+" in the bottom corner of the text box in slack where you type responses, and if you click on that it should let you select files to post. The node "a_170_590#" name is constructed from the location of a shape on the net, so that's coordinate (170, 590) in magic's internal units. It appears to be a small sliver of n-diffusion that is above the tap, and therefore is electrically isolated from everything else. But it shouldn't have anything to do with the port order. Apart from that minor point, everything looks correct in the .ext file, so I can't see any reason that the ports would output in any order other than that specified by the indexes.

@Tim Edwards what was the conversion factor for internal units to microns again? Is it in the tech or rcfile? Is there a default if it’s not specified? In the ext files, there’s a line

scale 1000 1 500000

Can those values be used to calculate the conversion factor?

Every coordinate in the .ext file multiplied by the third value (

500000

) gives you a physical distance in centimicrons.

Maybe 500000 is the number of data base units per centimicron? This would make each data base unit 0.2 nm. For example, there’s a cell at 173490 497666 in the ext file. Looking at this cell in klayout show the origin at 867.45000 2488.33000. So it looks like dividing the ext file coordinates by 200 gives the location in microns. This means that one data base unit is 5nm, but I don’t see how to calculate that from the

scale

values.

Here is a minimal test case for the port numbering. The .mag file is 33 lines and attached. Note that I learned to make a substrate contact from a hierarchical design youtube by bminch. The pN port names correspond to port number N, which can be seen in the mag file, but p1 ends up as the last parameter of the subckt, as posted earlier. It is not necessary for the contact to abut the transistor; you can put a space between green and brown and get the same behavior. I've also painted pwell over the entire cell, with no change in behavior. I used docker tools from JKU and the efabless/foss-asic-tools:theta, yielding the same result. This is not obstructing my work, so I'm not suggesting anybody spend time on this, but this tread seems to have started some discussion.

Huh. The ports really are out of order. Thanks for the example .mag file, which I can use for debugging.