Some questions on pin naming in magic. When I do import spice in magic using a .subckt generated by xschem, the subcircuit portname

i_x4[1]

(member of a bus) appears as

{i_x4\[1\]}

in magic. What is the purpose of the added braces and escape characters, and are they necessary? Also, what's the preferred notation for bus indexing in magic? Are square brackets OK, or is something else preferred? Thanks.

The purpose of escaping is that magic is in a Tcl interpreter, and square brackets in Tcl indicate an expression to evaluate. I'm not sure if the text above is correct, though, since

i_x4\[1\]

should need escaping but

{i_x4[1]}

(string inside braces) should not. One or the other should be necessary, but using both is redundant (and possibly wrong). Square brackets are okay to use but there are gotchas having to do with when to use escapes, and when not to. Magic uses square brackets for indicating instance arrays, and I think I have worked the code such that it can disambiguate between the use cases for brackets, but I wouldn't say that with 100% confidence. ngspice also has an uneasy relationship with square brackets, which it uses for input and output buses for xspice primitives. Net names with square brackets usually work, so I think ngspice also disambiguates the use cases.

Thanks Tim. I went ahead and manually generate the pins. I had to enter them as

"i_x4\[1\]"

in magic and they appeared as

i_x4[1]

in the layout and in the netlist. Interestingly, when I got to LVS, it failed in netgen. After some debugging, I realized that the netlist coming out of ext2spice was missing pins in the top level subcircuit definition (ef_smsdac8_ladder). Literally:

.subckt sky130_fd_pr__res_high_po_0p35_CN8CXG a_1708_1984# a_712_1984# a_n948_1984#
... 
.ends

.subckt ef_smsdac8_ladder
Xsky130_fd_pr__res_high_po_0p35_CN8CXG_0 vdac m1_2648_n4006# m1_988_610# gnd m1_1652_n4006#
+ m1_988_610# m1_2648_n4006# m1_2648_n4006# i_x1[1] i_x2[0] i_x8[0] gnd m1_2648_n4006#
+ vdd vdac i_x4[1] gnd m1_2648_n4006# m1_1652_n4006# m1_2648_n4006# m1_988_610# gnd
+ m1_1652_n4006# m1_1652_n4006# m1_2648_n4006# gnd gnd m1_2648_n4006# m1_1652_n4006#
+ vdac gnd vdac m1_1652_n4006# m1_988_610# i_x2[1] m1_988_610# i_x1[0] m1_2648_n4006#
+ m1_1652_n4006# i_x8[1] gnd i_x4[0] m1_988_610# m1_1652_n4006# m1_988_610# m1_1652_n4006#
+ gnd vdac vdac m1_2648_n4006# gnd m1_1652_n4006# m1_988_610# sky130_fd_pr__res_high_po_0p35_CN8CXG
.ends

When I changed the subcircuit definition manually...

.subckt ef_smsdac8_ladder vdac vdd gnd i_x4[1] i_x1[1] i_x4[0] i_x2[0] i_x2[1] i_x8[0] i_x1[0] i_x8[1]
...
.ends

then it worked fine. I found the problem in a roundabout way; I had ext2spice flatten the output netlist, and then it produced no .subckt line, and I had to add this manually. This "fixed" the problem and I thought it was a flattening issue. I realized the .subckt line was missing its ports later. Do you think this square bracket business contributed to this weird behavior?

If

ef_smsdac8_ladder

is the top level, then the problem is that there aren't any pins (ports) drawn at the top level. Magic can infer port connections for any subcell by figuring out what connects into that subcircuit. But it can't do that for the top level.

Mystery solved. I had recreated the labels and hadn't declared them to be ports. It's working now. Thanks for your patience (I see you field a lot of questions!)