https://open-source-silicon.dev logo
Join Slack
Powered by
Have a question about parasitic extraction. My de...
# klayout
v
Have a question about parasitic extraction. My design flow goes like this: 1. Generate devices in Magic (since it is possible to import a spice circuit directly) 2. Import to klayout and perform layout 3. Import GDS to magic for LVS 4. Extract using netgen magic for parasitic extraction 5. Change port order in the extracted netlist by copying the subcircuit definition from my schematic 6. Simulate extracted layout Is there a way to set the port order in Klayout instead of in magic, or manually?
m
@Vladimir Vesely In step 4, I think you mean use 
magic
for parasitic extraction. Before After reading the gds in magic, try 
readspice <spicefile>
before reading and subsequently flattening the gds. See http://opencircuitdesign.com/magic/commandref/readspice.html.
đź‘€ 1
v
That works! Thanks David. The "before reading the gds" note is very important. Accidentally placed it after the "gds read" in one of my scripts and had quite a time trying to determine why it had issues.
Turns out there are some more subtle issues here. 1. It is important to run the command after reading the GDS file. Otherwise, there is nothing the layout for the script to order. An error is thrown in the GUI, and when running scripts I confirm that it does not work properly before the gds read. 2. Trying to flatten the design eliminates the effects of readspice. I have tried using readspice at several points in my script, but I cannot get a port order to stick regardless of where I place it. 3. Cell order matters. (Edit: but only if you do not use the load command directly after readspice) The first cell I tried it on consisted of a single sub-circuit in the reference netlist. This is functional out-of-the-box if following points 1 & 2. However, when xschem netlists a design, the top-level cell is placed at the beginning of the netlist. readspice seems to interpret the final subcircuit as the toplevel. Thus, for a multi-cell comparison netlist (e.g. one that will be used for LVS), the top-level cell must be placed last. (sidenote: a fun workaround is to make a second file that only has the toplevel subcircuit, then use that as the reference for readspice. I checked, and this works!). I hope there is a solution to this. It would be nice to flatten before extraction, as that appears to be a little faster for me (not to mention strongly recommended on this slack). For reference, here is the script that works for me. The $1 is just the block name.
Copy code
gds read $1.gds 
load $1 
readspice $1_port_list.spice
select top cell
#expand
#flatten $1_flat
#load $1_flat
#cellname delete $1
#cellname rename $1_flat $1
#select top cell
select top cell
extract all
ext2spice lvs
ext2spice
m
@Vladimir Vesely Thanks for the update.
Thus, for a multi-cell comparison netlist (e.g. one that will be used for LVS), the top-level cell must be placed last.
I was under the impression that reading a spice netlist would reorder the ports for all subckts. Are you saying that this doesn’t work?
Copy code
gds read $1.gds 
load $1 
select top cell
expand
flatten $1_flat
load $1_flat
cellname delete $1
cellname rename $1_flat $1
readspice $1_port_list.spice
select top cell
extract all
ext2spice lvs
ext2spice
v
Using readspice with a heirarchical netlist causes the last subckt to be treated as the top-cell! It changes the port order of the last cell, then extraction is messed up because the top-cell is incorrect. Yes, the code you quoted does not result in the correct port order. Doesn't seem to matter where you put the readspice command. Commenting out the lines that flatten the code results in a hierarchical netlist with correct port order. It does result in a netlist that passes LVS.
Ah, it seems like the top cell is just "whatever cell is loaded at the moment"? By running load $1 after the readspice, it fixes the extraction for an unmodified netlist (i.e. order was not manually changed). Still doesn't work with flattening, which is the primary goal since port order is required for extracted circuits. :(
Copy code
gds read $1.gds 
readspice $1_xschem.spice
load $1 
select top cell
#expand
#flatten $1_flat
#load $1_flat
#cellname delete $1
#cellname rename $1_flat $1
#select top cell
extract all
ext2spice lvs
ext2spice
m
@Vladimir Vesely Ok, I think there may be some confusion with terminology. The top cell is the currently loaded cell. So you’re saying that doing a readspice sets all the ports for cells listed and loads the last one. If that’s the case, maybe the solution is to load the flattened cell (again) after readspice.
Copy code
gds read $1.gds 
load $1 
select top cell
expand
flatten $1_flat
load $1_flat
cellname delete $1
cellname rename $1_flat $1
readspice $1_port_list.spice
load $1
extract all
ext2spice lvs
ext2spice
v
I tried this, and after playing around with the flatten options, it does work. -dotoplabels fixed it. I guess there are some subcell label shenanigans occuring. The code below will produce flattened, c extracted layout with correct port order:
Copy code
gds read $1.gds 
readspice $1_xschem.spice
load $1 
select top cell
expand
flatten $1_flat -dotoplabels
load $1_flat
cellname delete $1
cellname rename $1_flat $1
load $1
extract all
ext2spice lvs
ext2spice
Final take aways: • -dotoplabels should be used in conjunction with flatten, if port ordering from readspice is desired • Readspice may be placed before or after the flattening, but should be followed by a load command. This make reordering or messing with the netlist unnecessary.
đź‘Ť 1
37 Views
Open in Slack
PreviousNext
Powered by