Noticing something weird. Extracting my layout wit...
# magic
j
Noticing something weird. Extracting my layout with this script:
Copy code
extract all
ext2spice lvs
set filename [cellname list window]
set spicefilename [lindex [split $filename .] 0]
ext2spice -d -o "../lvs/$spicefilename.spice"
I see 16 nfets in the resulting .spice, which makes sense for my layout. Using this script on the same layout:
Copy code
extract do local
extract all
ext2sim labels on
ext2sim 
extresist tolerance 10
extresist
ext2spice lvs
ext2spice cthresh 0.01
ext2spice extresist on
set filename [cellname list window]
set spicefilename [lindex [split $filename .] 0]
ext2spice -d -F -o "../pex/$spicefilename.spice"
I see 6 nfets. Little weird that the number is different. Should I expect this? The real troubling part is that in the latter extraction, an nfet which serves as a power on reset is not in the netlist. at least I can't find it. Anyone heard of this kind of issue before?
t
That is odd. . . The .res.ext file produces a set of devices with alternate connections (from the split-up network), and ext2spice just reads this file as a supplement to the .ext file and replaces the existing devices with the same but replacing the terminal connections with the ones from the .res.ext file. So there should not be any for it to end up with fewer devices. In theory.
j
In the .res.ext file I see the new nodes due to the split-up and I can trace the net
porst
(the name of the power on reset signal) to its corresponding nfet. Also, the number of nfets in this file is 13
So somewhere between the .res.ext step and the .spice file, the porst nfet disappears, along with 6 other nfets
t
This is the same layout you gave me?
j
yup
t
Okay, that matches the count I have in the output, too. The 13 devices in .res.ext is okay; that just means that three of the devices were connected to nets that either didn't get split up, or the original net name is at the device terminal so that the terminal connections didn't change. But why ten of them vanished is a mystery that needs solving.
Looking closer at the output, all the MiM cap type m3_2 somehow got converted to m3_1, which won't make any difference to simulation but is definitely not right.
j
Very weird. The model types are playing musical chairs. For now do you think I should stick to the extraction which does not involve extresist?
t
Yes, please. I will need to figure out what is going on. I have your failing example, so I should be able to use it to figure out why some devices are getting dropped and others getting changed.