https://open-source-silicon.dev logo
Join Slack
Powered by
It also seems to have output some zero sized devic...
# analog-design
w
It also seems to have output some zero sized devices which causes issues with ngspice
Copy code
X0 vss.t54 m1_n4941_3600.t20 m1_n6489_502.t23 vss sky130_fd_pr__nfet_g5v0d10v5 ad=0p pd=0u as=0p ps=0u w=0u l=0u
d
Hi @User, were you able to solve the zero sized devices when doing PEX in magic? I have this problem when i run 
extresist
. If I don't extract resistance, there are no zero sized devices. The full extractions command i'm using are:
Copy code
extract all
ext2sim labels on
ext2sim
extresist tolerance 10
extresist all
ext2spice lvs
ext2spice hierarchy on
ext2spice subcircuit on
ext2spice scale off
ext2spice cthresh 0.01
ext2spice extresist on
ext2spice
w
I had it pop up once or twice. Its no longer an issue, but I dont know what I did exactly to make it go away
Some combination of updating things and flattening my design? My script is:
Copy code
load folded_cascode_n_in 
box 0 0 0 0 
flatten folded_cascode_n_in_extracted
load folded_cascode_n_in_extracted
box -100um -100um 100um 100um 
port ibias index 1
port in_m index 2 
port in_p index 3
port out index 4
port vdd index 5
port vss index 6


extract all
ext2spice lvs
ext2spice -o folded_cascode_n_lvs.spice

extract all
ext2sim labels on
ext2sim
extresist tolerance 10
extresist
ext2spice lvs
ext2spice cthresh 0.01
ext2spice -o folded_cascode_n_pex.spice
ext2spice extresist on
ext2spice -o folded_cascode_n_w_res_pex.spice
t
Flattening seems like the most likely reason, although if I can get a tarballed failing example, I'd like to look at it. It should be a simple thing to fix. The device in the .ext file that is being replaced by the one in the .res.ext file should have the correct dimensions, so it seems like in the worst case I should just ignore the properties of the replacement device and just substitute the new terminal names.
w
Whats the current recommendation for extraction? I was under the impression that flattening was suggested (there can be errors in the resistance extraction without it) but you told John
Copy code
Don't ever flatten a design unless you have to, as it makes everything so much more complicated.
d
After a few runs, I've reached the following conclusion: The zero-sized devices problem is solved when running 
flatten
before the extraction. This also solves the floatting parasitics.
t
@Weston Braun: Flattening for resistance extraction is one of those few cases where "you have to". Mainly for LVS you don't want to flatten the circuit because it makes reading the LVS output a lot harder.
@Diego Hernando: All right, then, I probably won't try to debug the problem with zero-sized devices because there are multiple issues with running extresist on a hierarchical design, and the method needs a major overhaul, which I was planning anyway.
d
@Tim Edwards Sorry to bother you again, but the 
extresist
command makes magic crash (segmentation fault) as the desing gets more complex. I've tried this with and without flattening the design, and in both cases magic crashes, The C extraction works fine everytime i run it.
t
extresist
has not been tested on nearly as many cases as the standard extraction. If you have a crash condition, please tarball up the example so I can look into it.
d
Here you can find all the .mag files. The top one is the PFD.mag There is also a 
pex_commands.txt
files with the several cases i have tested in orden to get a PEX. After a couple of more runs, i think the issue is between the ports and the extresist command. If i don't generate ports (port make ...) the extraction works with falttening (there are no zero-sized devices) and without flattening (there are zero-sized devices). However without ports it's complicated to run simulations in ngspice of the extracted devices. Thanks for your help.
PFD.tar.gz
f
Hi @User, sorry to bother you, we would like to know if there was any news with the RC extraction? We are not yet able to obtain an working RC extraction for our simulations with the files attached by @User
t
I am working on it. What I have decided so far is that the RC extraction algorithm is different from the standard extraction and has fallen behind some of the development done for the basic extraction. This is causing it to miss certain classes of device. However, the whole thing seems unnecessary because it is trying to duplicate, the hard way, information which is in the .sim file and which it has already parsed. If I can confirm that, the fix may be pretty simple.
I have decided that the existing code, while somewhat redundant, is also the only code which can really distinguish an individual transistor source or drain, so it looks like it is necessary. The main problem is that it has no code right now for dealing with things like capacitors and bipolars which are topologically different from transistors, so that needs to be implemented. Having studied the problem most of yesterday, I think I can take a stab at it today.
f
great! thank you
Open in Slack
PreviousNext
Powered by