Magic is extracting

sky130_fd_pr__pnp_05v5_W0p68L0p68

as

sky130_fd_pr__rf_pnp_05v5_W0p68L0p68

causing LVS to fail when using netgen. If I remove the 'rf_' manually from the Magic-extracted netlist, LVS passes. Anybody seeing the same issue with bipolars?

Can you tell what version of the pdk you’re using?

I think it’s 1.0.470 Is there a way to query open_pdk to tell for sure which version it is?

I think the extract log shows at the bottom. You should be able to see it in

$PDK_ROOT/$PDK/libs.tech/magic/$PDK.tech

at the top in the version number. If you’re using LVS in precheck, the pdk associated with may be out of date.

Thanks, found it: version 1.0.470-0-g6d4d117

I wouldn’t recommend updating yet. The diode changes haven’t been tested. I looked in the tech file for

1.0.470-0-g6d4d117

but I couldn’t find

sky130_fd_pr__rf_pnp_05v5_W0p68L0p68

. That’s why I asked about what version you were using. Are you extracting directly in magic with manual extraction commands or using a script?

Extracting directly in Magic by typing

extract

and then

ext2spice

Check your magicrc file to be sure that it’s loading the correct technology.

Thanks Mitch, following your tips, I may have found where it could be coming from: This is how I start Magic w/ -rcfile:

magic -d XR -rcfile /usr/local/share/pdk/sky130A/libs.tech/magic/sky130A.magicrc ibias_gen.mag

In the rcfile, I found this line:

source $PDK_ROOT/sky130A/libs.tech/magic/sky130A.tcl

If I then go to the .tcl file above, I find this code where it links non-rf to 'rf_' versions:

proc sky130::sky130_fd_pr__pnp_05v5_W0p68L0p68_draw {parameters} {  
return [sky130::fixed_draw sky130_fd_pr__rf_pnp_05v5_W0p68L0p68 $parameters] }

Nice detective work! But, I don’t know if that’s relevant or not. Can you share your netgen lvs command and the schematic source spice?

netgen lvs ibias_gen.spice ibias_gen_wip.spice /usr/local/share/pdk/sky130A/libs.tech/netgen/sky130A_setup.tcl

Xschem netlist:

ibias_gen_wip.spice

Magic extracted netlist that LVS's correctly after manually editing out 'rf_':

ibias_gen.spice

Original extracted netlist that doesn't LVS correctly:

ibias_gen_rf.spice

@Robin Tsang I’d be interested in your comp.out file too. The recommended practice is to set the

Simulation->LVS netlist: top circuit is a .subckt

option before netlisting. (the actual location of this option may be a little different depending on the xschem version). and then, since the layout and schematic cell names differ, run netgen with

netgen lvs "ibias_gen.spice ibias_gen" "ibias_gen_wip.spice bias_gen_wip" /usr/local/share/pdk/sky130A/libs.tech/netgen/sky130A_setup.tcl

However, this still doesn’t explain where the

rf_

is coming from. I’m thinking that the

sky130_fd_pr__rf_pnp_05v5_W0p68L0p68

mag file might have a

LEFview

property. Can you share the

ibias_gen.mag

and

sky130_fd_pr__rf_pnp_05v5_W0p68L0p68.mag

(if there is one) file? From the looks of the extracted layout, maybe ports haven’t been added either. I only see

avss

. Is this the correct schematic? Just an isolated pnp and resistor?

XQ1 avss avss net2 sky130_fd_pr__pnp_05v5_W0p68L0p68 m=1 
XR1 avss net3 avss sky130_fd_pr__res_xhigh_po_1p41 L=0.0007 m=1

Netgen

comp.out

of LVS matching correctly when 'rf_' manually edited out And

comp.out.err

shows what it looks like if I don't edit out 'rf_' Yes, its the correct schematic, just a resistor and a pnp. I'm working on the layout bit by bit and started with the pnp and resistor. Will add ports later.

@Robin Tsang: Sorry for taking all day to weigh in on this---I have been in meetings literally all day. The setup is backwards from what I would expect. If I create a bipolar in magic with

Devices1->PNP 0.68 x 0.68

, then it will use a subcircuit called

sky130_fd_pr__rf_pnp_05v5_W0p68L0p68

(with the "rf"). But this subcircuit references a "gencell" called

sky130_fd_pr__pnp_05v0_W0p68L0p68

(without the "rf") which is the actual device. Extracting a layout with this subcircuit should produce something like the following, where I have a top level called "bipolar_test":

.subckt sky130_fd_pr__rf_pnp_05v5_W0p68L0p68 Base Collector Emitter m=1
X0 Collector Base Emitter sky130_fd_pr__pnp_05v5_W0p68L0p68
**devattr s=18496,544
.ends

.subckt bipolar_test
Xsky130_fd_pr__rf_pnp_05v5_W0p68L0p68_0 B C E sky130_fd_pr__rf_pnp_05v5_W0p68L0p68 m=1
.ends

The lowest level device in this netlist is the PNP without the "rf" in the name, and is the one defined in the PDK library. I may need to see the layout to understand why you're getting something different.

Thank you Tim. So somehow during extraction my setup is not descending far enough down the hierarchy to see the real pnp. Here is my layout. I've added a bunch of stuff to it but the pnp device is still the same. I type

extract

and then

ext2spice

in Magic to get the netlist: https://github.com/ajcci/sky130_ajc_ip__overvoltage/tree/main/mag/ibias_gen

Your

ibias_gen.mag

file has the PNP cell correctly pointing to the location

$PDKPATH/libs.ref/sky130_fd_pr/mag

. So the question seems to be what is in your PDK in file ``$PDKPATH/libs.ref/sky130_fd_pr/mag/sky130_fd_pr__rf_pnp_05v5_W3p40L3p40.mag` ? For correct handling of the extraction, the tech file for magic has

device msubcircuit sky130_fd_pr__pnp_05v5_W0p68L0p68 pnp *pdiff \
        pwell,space/w a1>0.45 a1<0.47

and the version of magic needs to be at least 8.3.411 to handle the syntax in the extraction statement.

Using Magic 8.3.466 Inside this file:

/usr/local/share/pdk/sky130A/libs.ref/sky130_fd_pr/mag/sky130_fd_pr__rf_pnp_05v5_W0p68L0p68.mag

at the bottom, this is what's there:

<< properties >>
string GDS_END 10361160
string GDS_FILE $PDKPATH/libs.ref/sky130_fd_pr/gds/sky130_fd_pr.gds
string GDS_START 10353234
string gencell sky130_fd_pr__pnp_05v5_W0p68L0p68
string library sky130
string parameter m=1
<< end >>

"Hand edit + figure it out later" is probably the easiest solution for now.

Thanks, I'll do that. Appreciate your help and your time @Tim Edwards @Mitch Bailey

@Robin Tsang: I have figured this out. It's a really obscure bug in magic. It has something to do with setting

ext2spice hierarchy off

. If you use

ext2spice lvs

it sets

ext2spice hierarchy on

(among other things). With

hierarchy

set to

off

, the circuit is supposed to be flattened. For reasons I have not yet delved into, magic is not flattening the PNP subcircuit, but leaves it at the wrapper (the subcircuit with the "rf" in the name). I will log an issue in the github issue tracker for magic about it, but I probably won't get around to it for a few days. You can either stick with the manual workaround, or maybe you can get by with the hierarchical extraction mode?

Awesome! Thanks a bunch.

I fixed this in the magic code, so now

ext2spice hierarchy off

will properly flatten the PNP down to the device level (in the process, however, I discovered that

ext2spice subcircuit descend off

is broken, but that will have to wait for another day to be fixed).