https://open-source-silicon.dev logo
Join Slack
Powered by
Happy Thanksgiving! (if applicable) I'm having tr...
# magic
t
Happy Thanksgiving! (if applicable) I'm having trouble with the extresist part of my PEX flow. It seems that when I turn it on parts of my circuit just disappear or are left unconnected, yet when I turn it off I don't have the issue. I have a 10-bit DAC and when i follow the path from "din[0]" for example in the version with extresist on I only manage to get to the gate of the nFET in the first buffer but not the pFET. This explains why in the simulation waveform the drain never goes high. If on the other hand I turn off extresist, I can get to both the pFET and the nFET of the first buffer, and as expected, the simulation works. I have attached both netlists incase anyone would be able to taka a look for me. I'f be grateful for some insight as to what's going on. The net 
din[0].t0
in the resistor extracted netlist goes to the gate of the nFET but I can'd find an equivalent path to the pFET, which aligns with the failing simulation. My extraction procedure is as follows:
Copy code
load $MAG_CELL
flatten ${CELL_NAME}_pex
load ${CELL_NAME}_pex
box values 0 0 0 0
extract all
ext2sim labels on
ext2sim
extresist tolerance 10
extresist all
ext2spice lvs
ext2spice cthresh 0
ext2spice extresist on
ext2spice -o $OUTPUT_FILE_NAME
exit
Thanks in advance!
t
I have the older complete layout of yours from about 10 days ago. I ran full R-C extraction on that and I do see some oddities which look like they are the same thing. The R-C netlist ended up with 2102 devices while the .ext file for it has 2130. Extracting without R-C parasitics yields a netlist with all 2130 devices. I can compare the two netlists side by side and find each of the missing devices. There is nothing unusual about the devices that went missing, and there were no error or warning messages related to them during extraction. It is a bizarre error, and even more bizarre that the result you posted just above is missing nearly half of the devices. I am investigating. No idea how long it will take me to track this down. The extresist code is pretty complicated.
t
Thank you very much for looking into it, Tim!
t
@Tom: I just pushed an update to magic (version 8.3.451) on opencircuitdesign.com. There were two independent errors and I'm not sure why they haven't shown up before (maybe they did and I didn't know what I was looking at, at the time). Both were causing devices to disappear from the final netlist. After the fix I believe I am getting correct output for your layout. There is one oddity remaining where a dummy device loses its source area and perimeter values which is harmless where it occurred but needs looking into.
t
Oh great! Thanks, @Tim Edwards. I'll give it a try
It still looks broken actually @Tim Edwards. I just re-extracted using magic built from
Copy code
commit 84af8016081eb5d433a910512a9ff0b6cd319aeb (HEAD -> master, origin/master, origin/HEAD)
Author: Tim Edwards <tim@opencircuitdesign.com>
Date:   Fri Nov 24 16:51:26 2023 -0500

    Fixed two independent errors, both of which can cause devices to be
    missing from a netlist generated by ext2spice with the "extresist"
    option enabled.  The first had to do with some parts of nets being
    given alias names for a net, and the second was caused during
    "extresist" and would also result in error messages about devices
    missing terminals.
With the following commands:
Copy code
load $MAG_CELL
flatten ${CELL_NAME}_pex
load ${CELL_NAME}_pex
box values 0 0 0 0
extract all
ext2sim labels on
ext2sim
extresist tolerance 10
extresist all
ext2spice lvs
ext2spice cthresh 0
ext2spice extresist on
ext2spice -o $OUTPUT_FILE_NAME
exit
And the netlist (attached) still seems to be missing the din[0] buffer pFET connection. I also get the following singular matrix errors which I do not get when I only extract pcaps (extresist off)
Copy code
Note: No compatibility mode selected!


Circuit: 

binary raw file "/home/tom/results/dacr2r/tb_tran.raw"
Doing analysis at TEMP = 27.000000 and TNOM = 27.000000

Note: v1: dc value used for op instead of transient time=0 value.
No. of Data Columns : 8289  
Warning: singular matrix:  check node x1.a_20476_10878.t1

Note: Starting dynamic gmin stepping
Trying gmin =   1.0000E-03 Note: One successful gmin step
Trying gmin =   1.0000E-04 Note: One successful gmin step
Trying gmin =   1.0000E-05 Note: One successful gmin step
Trying gmin =   1.0000E-06 Note: One successful gmin step
Trying gmin =   1.0000E-07 Note: One successful gmin step
Trying gmin =   1.0000E-08 Note: One successful gmin step
Trying gmin =   1.0000E-09 Note: One successful gmin step
Trying gmin =   1.0000E-10 Note: One successful gmin step
Trying gmin =   1.0000E-11 Note: One successful gmin step
Trying gmin =   1.0000E-12 Note: One successful gmin step
Trying gmin =   1.0000E-12 Note: One successful gmin step
Warning: singular matrix:  check node x1.a_8828_27650.t1

Warning: Dynamic gmin stepping failed
Note: Starting true gmin stepping
Trying gmin =   1.0000E-03 Warning: singular matrix:  check node x1.a_8828_27650.t1

Warning: Further gmin increment
Trying gmin =   5.6234E-03 Warning: singular matrix:  check node x1.a_8828_27650.t1

Warning: Further gmin increment
Trying gmin =   8.6596E-03 Warning: singular matrix:  check node x1.a_8828_27650.t1

Warning: Further gmin increment
Trying gmin =   9.6466E-03 Warning: singular matrix:  check node x1.a_8828_27650.t1

Warning: Further gmin increment
Trying gmin =   9.9105E-03 Warning: Further gmin increment
Here's the PEX netlist for the above message
t
Aaugh, it deleted all the ports. Try this as a stop-gap measure: When you flatten, use 
flatten *-dotoplabels
.* I think that a lot if not all of the problems are coming from the handling of multiple labels on a net. The "dotoplabels" option will retain only the ports of the cell, and remove the rest of the labels.
t
That works, @Tim Edwards! Thank you! does that flag only preserve labels at the top level after flattening? Or does it preserve all port labels prior to flattening?
t
It preserves port labels as it flattens, and removes all the other labels.
t
does that mean that at the end, the only labels which are preserved are the ones at the final top-level?
I ask because if a sub block has multiple VDD ports for example, I don't want the tool to connect them internally before passing them up. I'd like it to honor the layout, and only connect them when passing them to the top level subckt interface
t
The 
-toplevel
option will remove all the lower-level labels completely. However, in general, if you want to make sure that ports aren't connected by having the same label, then use 
extract unique
before running extraction.
I think I managed to figure out the problem and fix it at the source, so from magic version 8.3.452, it should not be necessary to use 
flatten -toplevel
. It was really just allowing non-port labels to take priority over port labels during a node merge.
🌍 1
t
Thank you, @Tim Edwards
9 Views
Open in Slack
PreviousNext
Powered by