Hello everyone, I am working on a PTAT current generator. The magic extraction tool creates a correct C-only netlist, however when asking for RC-type extraction, then some PMOS and NMOS devices are excluded from the simulation netlist. I created 2 simple test cases, with 1xNPN, 1xPMOS, and 1xNMOS, in an attempt to debug my layout flow: 1. Place the _sky130_fd_pr__rf_npn_05v5_W1p00L1p00, sky130_fd_pr__pfet_01v8, sky130_fd_pr__nfet_01v8_ devices into magic and run the extraction, all the generated netlists were OK with both C-only and RC extraction. 2. Connect with M1 the COLLECTOR of the _sky130_fd_pr__rf_npn_05v5_W1p00L1p00_ to the GATE of the _sky130_fd_pr__pfet_01v8_ and the DRAIN of the _sky130_fd_pr__nfet_01v8_ in this case the “LVS” netlist was OK, however, the “XSCHEM SIM” netlist was OK only with C-only extraction, with RC extraction the “XSCHEM SIM” netlist was missing the NMOS and the PMOS devices. Note when RC extraction is done the following messages are returned: Missing terminal connection of device at (13420 374) on net dw_9704_244 Missing gate connection of device at (6438 571) on net dw_9704_244 Currently, I’m using the 8.3.505 version of Magic from the iic-jku/IIC-OSIC-TOOLS and the tt06-analog-relax-osc-main as the starting point both are amazing. Wonder if any of you encountered this issue? Thank you!

Can you please post the layout so that I can attempt to reproduce the problem?

Hi Tim, thank you for looking into this. Please find the layout attached.

@Istvan Kovacs: I also need the layouts for the two generated devices

sky130_fd_pr__pfet_01v8_C47HKB

and

sky130_fd_pr__nfet_01v8_KU6TM2

.

Hi Tim, Please find bellow, reattached the complete layout + sub-cell (hopefully it will work). The sequence I use is: set project [lindex $argv $argc-1] load $project.mag flatten tt_um_flat load tt_um_flat select top cell cellname delete $project cellname rename tt_um_flat ${project}_parax #extract do local extract all ext2sim labels on ext2sim extresist tolerance 10 #extresist all #if no tolerance is required extresist ext2spice lvs ext2spice cthresh 0 ext2spice extresist on #ext2spice no need #ext2spice -d -o $project.sim.spice -d was depracated ext2spice -o $project.sim.spice quit -noprompt

I can see the immediate problem, which is that in the

.res.ext

file created by the

extresist

command, there is a "`killnode`" line followed by two uses of the node that was supposed to have been "killed" in the device lines. If I modify the

tt00-device-test_parax.res.ext

file and change the two instances of

dw_9704_244#

in the lines starting with "`device`" with

dw_9704_244.n0

, then I rerun the extraction (without doing

extresist

so that it doesn't overwrite my edits), then I get a valid (syntactically, at least) netlist. This does appear to be a magic extraction error, and I will look into it.

Hi Tim, I really appreciate for taking the time to look into this. I will try and use the above method for now for estimates. Please let us know once the fix is complete.

@Istvan Kovacs: I see I have some work to do to prevent magic from generating bad output in this case. However, the basic issue is that the R-C extraction operates by finding "drivers" and "terminals". A "driver" is assumed to be a power supply, but more generally, any port of a subcircuit can be a driver. The issue with this simple circuit is that it has no clear drivers, since only a few device pins have been connected together. If all device pins are labeled as ports, in particular the ones that don't connect to anything, then the devices don't just disappear from the output netlist. Obviously devices should never just disappear from the output netlist, but this explains why the issue does not come up in practice in real circuits and just pops up for your simple test case. I will debug the underlying issue, but at least you have a clear workaround.

@Tim Edwards At one point I started putting ports (pins) to every node in the circuit to monitor the voltage levels as I was suspecting the layout not being good and to my surprise the thing was working correctly. Your explanation makes it completely clear now why that version of the layout worked. The main takeaway when using NPN's and unexpected strange results happen is to avoid leaving any of it's terminals unconnected to a port/pin. Thank you for your help!

That said, magic still needs a proper "fallback" position so that it does not produce an invalid and unsimulatable netlist, and I think that fix should be fairly straightforward to implement.

@Tim Edwards great news, thank you for the implementation, going to test it in the upcoming iic-jku/IIC-OSIC-TOOLS release :)