netlist extraction from GDS does not work as expected in ngspice

[spnadig]

on running these in magic-
extract all
ext2spice rthresh 0
ext2spice cthresh 1nf
ext2spice scale off
ext2spice hierarchy on
extresist all
exresist on
ext2sim
ext2spice

the netlist generated have 2 issues:

1. the .spice file has no resistance extracted
2. the extracted .spice netlist when run in ngspice do not have expected behavior

I made a digital counter in verilog - ran it through openRoad to generate GDS file and ran the above to extract netlist to run on ngspice. When I drive it - I dont get expected output. The design is verified to work in a verilog test bench. So there seems to be an issue in extraction?

[spnadig]

@proppy

[RTimothyEdwards]

@spnadig : You might have typos in your list of commands, but the proper sequence of commands to get an R-C parasitic extracted netlist is:

extract do local
extract all
ext2sim labels on
ext2sim
extresist tolerance 10
extresist
ext2spice lvs
ext2spice cthresh 1
ext2spice extresist on
ext2spice

Also, the R-C extraction has unknown/unproven reliability when extracting a hiearchy, so it works best if you flatten the circuit first with the flatten command, load the flattened layout, and run the command sequence above on the flattened netlist. Running extresist on a hierchical layout would at least require running ext2sim individually on every subcircuit of the layout.

[spnadig]

Thanks @RTimothyEdwards - that worked! Now I see both R-C in netlist.
But I noticed that the extraction has -ve capacitors on certain nodes and also components with area = 0 for diodes (for example - there are mode) which are incorrect. Are these known issues? I fixed these manually

[RTimothyEdwards]

@spnadig : The negative capacitances are a known problem that I am actively working on, and hope to have a patch for in a day or two. The zero area of diodes is not one I'm aware of. Which type (or types) of diode is showing the problem?

[spnadig]

here are a few components that have issues that I found in my netlist:

[RTimothyEdwards]

What version of magic are you using?

[RTimothyEdwards]

Actually, I can see from the output that it is pretty recent. But I am unable to reproduce the zero perimeters and areas. Maybe the more relevant question is what PDK version you are using. The command tech version in magic will show the version line from the tech file, which, assuming from the above output is from the GF180MCU open PDK, is probably something like this: 1.0.393-3-g815863e {Global Foundries 180mcu: open PDK rules and DRC}. It is particularly odd that simple transistor width and length are reporting zero when the source and drain areas and perimeters seem to be reporting correctly.

[spnadig]

1.0.393-0-ge6f9c88 {Global Foundries 180mcu: open PDK rules and DRC}

[spnadig]

In general I have been unsuccessful in getting extraction to work and match expected results in ngspice for multi component designs. Simple designs like say the inverter and ring oscillator has worked. While I anticipate performance degradation post extraction, I see loss of functionality of blocks post extraction. In that pursuit - while debugging I found this (bug above) to be one of the issues. Manually fixing them still did not make the block functional.

I have tried this on custom layout of op-amps (has many transistors, capacitors and poly resistors) which was verified to work in schematic level ngspice sims. Post extraction the results were incorrect. I even tried this on digital blocks generated from verilog and GDS generated by openRoad. On extracting this auto generated layout - I still get incorrect extraction and loss of functionality of the block.

SO I suspect there maybe more errors in spice netlist creation. I initially thought it could be because "R" is missing. But this recent exercise of including "R" in netlist still does not yield a working netlist.

Is this a known issue?

[RTimothyEdwards]

Are you flattening the design before running extraction? I cannot guarantee that full R-C extraction works at all on a hierarchical layout, even if you have manually worked through the entire subcell tree and run ext2sim on every cell (which you would need to do in order for it to work at all). Do not save the flattened layout (it would make everything harder for DRC, LVS, and GDS generation), but just use it to generate the extracted netlist.

[spnadig]

OK I was able to get a counter work post extraction! Thanks for all the pointers @RTimothyEdwards

[proppy]

@spnadig was flattening the solution here?

[spnadig]

The solution was

1. to include R as per instructions above
2. rest of it was ngspice issues - GND cannot be associated with lab_pin.
3. ngspice netlist from symbol was mismatched from the one generated by magic extraction - can be corrected by pin placement in GUI in the same order as netlist while making symbol in ngspice
4. some components with area = 0 and l=0, w=0 generated from extraction has to be manually removed
5. -ve capacitances need to be removed as ngspice simulators would crash
6. flatten design prior to extraction

[RTimothyEdwards]

@proppy : I'm still not sure why that layout ends up with devices with area/length/width of zero, because I have not been able to come up with my own example that duplicates that issue. The issue with negative capacitance is one that I'm aware of and currently working on (as in, today).

[RTimothyEdwards]

I believe that I have now tracked down and fixed all of the issues in the extraction that produce negative capacitances.

[spnadig]

@RTimothyEdwards - thanks for fixing -ve capacitance. I have one other thing regarding extraction to bring to your attention

When I compare extraction from magic with commercial tools - the Capacitance extraction is is close agreement. However, R is inaccurate and for some nodes R is significantly different when compared to extraction from commercial tools.

Is inaccuracy in R extraction known and can this be fixed?

[RTimothyEdwards]

@spnadig : I'd have to do some comparisons. I have spot-checked some of the resistance results and they look valid to me, at least for simple geometries. I have not tried to analyze complicated resistive networks. Generally, the algorithm looks valid and its assumptions seem reasonable. I would not expect a large departure from another tool unless the underlying sheet resistance numbers are significantly different. Do you know what numbers are being plugged into the commercial tool? Can you validate the total resistance of a wire for a simple case, such as a relatively simple set of wire lengths and contact cuts?

[RTimothyEdwards]

@spnadig : Can you please send me or post a layout that has a large discrepancy in R compared to a commercial tool result, and locate the net that is showing the discrepancy? I want to debug what's going on, since at the moment I can't tell if the problem lies in the numbers put into the technology file, or in magic's extresist code.

[spnadig]

You are part of that thread already. You have access to that ppt