Uninitialized count in pnp device count comparison

[d-m-bailey]

Slot-002 of mpw-3.

Subcircuit summary:
Circuit 1: WY_SY_ldo_v1                                                           |Circuit 2: ldo_v1
----------------------------------------------------------------------------------|----------------------------------------------------------------------------------
sky130_fd_pr__pfet_g5v0d10v5 (870->14)                                            |sky130_fd_pr__pfet_g5v0d10v5 (870->14)
sky130_fd_pr__res_xhigh_po (122->16)                                              |sky130_fd_pr__res_xhigh_po (116->9) **Mismatch**
sky130_fd_pr__nfet_g5v0d10v5 (70->11)                                             |sky130_fd_pr__nfet_g5v0d10v5 (70->11)
sky130_fd_pr__cap_mim_m3_1 (2)                                                    |sky130_fd_pr__cap_mim_m3_1 (2)
sky130_fd_pr__pnp_05v5 (-2147483647->2)                                           |sky130_fd_pr__pnp_05v5 (9->2)
Number of devices: 45 **Mismatch**                                                |Number of devices: 38 **Mismatch**
Number of nets: 28 **Mismatch**                                                   |Number of nets: 23 **Mismatch**

Will attach test case later.

[RTimothyEdwards]

Whoa, I've never seen that one before. . .

[d-m-bailey]

Actually, this may be a magic extraction problem. From the extracted spice file

X39 GND GND net9 sky130_fd_pr__pnp_05v5 area=3.25 M=-nan
**devattr s=260000,4260

[RTimothyEdwards]

I think "M=" only appears in the netlist if you use the "merge" option in ext2spice?

[d-m-bailey]

Here's a test case. Covers several issues. This is an analog design with multiple texts at the top level shorted. ext2spice short resistor is used in an attempt to keep all the ports.

test_lpo1.tgz

tar xzf test_ldo1.tgz
cd test_ldo1
./run_lvs

run_lvs runs on a layout that has been fixed so that it matches the source topologically. It illustrates the issues of unexpected pnp size extraction and parallel series resistor reduction mismatches.

test_lpo2.tgz

tar xzf test_ldo2.tgz
cd test_ldo2
./run_ext

run_ext runs on the original layout. It illustrates the issues of the loss of ports even with ext2spice short resistor and unreported shorts via merge statements. See https://github.com/RTimothyEdwards/magic/issues/245#issue-1718211525

[RTimothyEdwards]

@d-m-bailey : I just pushed an update to magic that fixes the issue of merging the PNP devices. The problem is that the merge algorithm was written for FETs (and also handles resistors and capacitors), but the PNP device in the sky130 tech file is using the "msubcircuit" type which indicates that it is a FET-like device but (other than the problem with M) produces the right netlist output for the bipolar device. I have modified the ext2spice code---provisionally---to just add together the device counts for non-FET devices (in this case identified by the fact that W and L are zero, which is what causes the NaN value to appear, after doing a divide-by-zero calculation). Ultimately I need to revisit this, because all subcircuit-type devices need to have declared parameters checked so that only devices with matching parameters are merged. As written now, two bipolar devices with the same B, C, E connections but with different emitter area will be merged.

I have not yet addressed the incorrect emitter area. This is most likely an issue in the tech file, not the magic source code, as the device declaration needs to specify which terminal is supposed to be measured to produce the area value.

[d-m-bailey]

@RTimothyEdwards Thanks.

I have not yet addressed the incorrect emitter area. This is most likely an issue in the tech file, not the magic source code, as the device declaration needs to specify which terminal is supposed to be measured to produce the area value.

Right, but the magic tech file Using technology "sky130A", version 1.0.393-0-ge6f9c88 already has

 device msubcircuit sky130_fd_pr__pnp_05v5 pnp *pdiff pwell,space/w a2=area

which means the area of *pdiff, correct?

Currently, the pnp recognition layer is coincident with the outer ptap. Does this make a difference?

[RTimothyEdwards]

The recognition (device) layer should be the BJT base (layer pnp). "a=area" would measure the area of that layer. "a1=area" and "a2=area" would measure the area of terminals 1 or 2, respectively. But the value area=3.25 seems to be pulled out of thin air. Possibly (even likely) this has something to do with a recent code change I made to better track FET source and drain area and perimeter. I'm pretty sure that not long ago magic was extracting the correct area for the bipolar devices.

[RTimothyEdwards]

I am now pretty sure that magic never was extracting the correct area for bipolar devices, because there is simply no code for calculating area and perimeter of a device terminal that is not in the same plane as the identifying type. I did just push a correction for the problem of "pulling values out of thin air"---the issue there was that the values were not initialized, so when a terminal failed to get area/perimeter calculations, it just output whatever value was left in the variables from the last device calculation. But that doesn't fix the underlying problem. (To clarify, all of these problems are in magic, not in netgen.)

[RTimothyEdwards]

@d-m-bailey : This problem should be corrected now in the most recent versions of magic (8.3.402) and open_pdks (1.0.418). The area of bipolars (and diodes) had never previously been calculated correctly because there was no code to compute area and perimeter of terminals not on the same plane as the device identifier layer. Once I added that, it was also clear that the magic techfile for sky130 needed to use a1=area and not a2=area to calculate the area of the emitter (instead of the base). Please note that I have still not addressed the issue of merging devices with non-matching properties. That one is a bit problematic because magic has always merged FETs regardless of whether terminal areas and perimeters match or not.