I am working on a analog design in Cadence IC184.108.40.2060.5, and I have completed the layout of the chip with DRC, LVS, floating gate check that is clean (I amworking with IBM's CMRF7SF process).After I ran Assura QRC to generate av_extracted, and av_analog_extracted views I go back into my testbenches to run toplevel sims with these new views, and I am running into problems.
I am comparing the netlist with extracted views, and I noticed that on many of the NMOS and PMOS devices, the source and drain is flipped from what I intended them to be in my design. For example, I expect N1 to have a netlist of N1(D G S B) according to my schematics, and instead of that, the parasitic netlist of the instance N1 has a netlist of N1(S G D B). Wondering why that's the case. I passed LVS, and this only shows up in av_extracted and analog_av_extracted views... Thanks for any tip/advice from you!
I did some more digging aorund by looking at the operating point of the av_extracted layout view. And I noticed that for the operating point, my devices which have a combination of m and f (multiples and fingers) are fine, as in, all the instances have the same terminal voltages.
However, all of my devices which have m=1, but are fingered, is messed up. As in, when I look in the av_extracted view. I see three instancess with three different drain/source voltages. They have the same gate voltage. This is peculiar, since if I have a device of m=1, f>1, shouldn't there be simply one instance of drain, source, gate, bulk voltage in my operating point, instead of conflicting voltages?
Hope this sheds more light on my dilemma here, thanks!
In reply to jimstuy:
apologies, here's a third update:
After digging in the netlist textfile. I confirmed that al of my devices with m>1, f>1 have identical S,D,G,B nets. As in, they are devices in parallel, as it should be. But, for all my devices with m=1, f>1, each instance (e.g MN1_1_rcx, MN1_2_rcx, ..., MN1_n_rcx), where n=number of fingers of my device, has source and drain netnames flipped! This is miraculous, I've created a ... I don't know what to call it, a MESSFET.
How can this happen, when my layout is clean on DRC, LVS, gloating gate, orthogona grid check, etc. And only shows up when I include R,C extract in my Assura QRC runs?
Okay, im done facepalming... thanks in advance for any advice anyone have out there. X:-(
Hi jimstuyHere are my comments:a. It is ok for the S/D nets to be flipped since they are permutable for mos devices. You will find that the corresponding AS, AD, PS and PD parameters will also be changed accordingly and hence everything will still be correct.b. It is not uncommon for your multi-fingered devices (e.g. m=1, nf=3) to be represented as mfactored devices(e.g. m=3, nf=1) after layout extraction. The change happens during Assura LVS. There are 2 possible reasons for this:- Assura and all other verification tools is not able to correctly identify multi-fingered devices that are abutted unless there are special marker layers. This is due to the merging of original layers when reading in the database. The layers are merged for more efficient processing but also unfortunately creates this problem. Hence most rule decks do not extract mos fingers.- It is possible to extract fingers for single devices that will never be abutted (e.g. RF devices with individual special guardrings). For such cases, the rule deck usually has a switch (e.g. extract_fingers) to enable this. Please check if this applies for your situation.There is indeed a simulation impact when using mos bsim4 models if sch uses (m=1, nf=3) and layout ends up as (m=3, nf=1). So unless the simulation uses nf, you should be fine. If the final current and voltages looks fine and extracted parasitic values are also close to what you have estimated, please apply the 1st principle of engineering:No further action needed unless things are broken. : )Best regardsQuek
In reply to Quek:
Thanks for your prompt reply, and great advice. My only problem is... my DC operating point is not right after running extracted toplevel sims. =(
Regarding your inputs: a) I see your point, but would this still be okay: In the extracted netlist textfile that I created in ADE-L, I checked for MN3, which is m=1,f=3 device. And I do indeed find three instances of them like this:
MN3_rcx ( D G S B ...), MN3_1_rcx(S G D B), MN3_2(D G S B), where D G S B are the nets of the schematic instance. You notice that one of the instances, according to the extracted netlist, has the source and drain flipped. Wouldn't that be an issue?
b) I will check for the switch for extract_fingers, would i find this under Assura QRC menu, or the parasitics menu?
Bottomline is, I wonder if my design doesn't work when simulating with extracted RCs is due to some technicality/flag/bug of the software, or my own poor layout skills... I have written down the voltages of all nodes in av_extracted view, and verified them against the schematics. And the only discrepancy I am seeing that is glaring if these m=1, f>1 devices, where I get different readings for the sources/drains that should be shorted together.
I'll dig into this more tomorrow back at work. I'll start by checking the current (what direction they are flowing) of each instance to see if these mislabeled D/S terminals are truly an issue, or as you mentioned Quek, they are perfectly fine.
Hi jimstuya. If the connections are still correct, it is not an issue.b. Please press "switches" button in the Assura LVS form.You can also consider contacting your local Cadence support so that you can send them a testcase for more detail checking. : )Best regardsQuek
The switch is called "resimulate_extracted". If that doesn't help you should contact your support provider. Regards, Zach
In reply to Zach:
Thanks to both your inputs Quek, Zach.
P.S. I have a singaporean friend whose surname is also Quek, Guo is the mandarin pronounciation right?
Partially right. It can also be "Kwok" depending on the dialect group. : )
Morning Quek, and hi everyone.
I am still experiencing issues here with my extraction verification. But I think I've found the rot cause. I 've been playing with the threshold to which a parasitic R gets saved, and I am at a point where I set the value such that only one parasitic R gets extracted and becomes part of the netlist of my overall av_extracted design. I then exhaustively check my netlist for discrepancies.
Here's what I found: My design is a fully differential design, and after running a DC sim of my extracted netlist, my outputs rail. This gave me the idea to look in a particular circuit block (common mode feedback amp, but it's not central to this discussion) What I find is that: Say I have a resistor RRR0 connecting to a mosfet called TN9. The netlist for TN9 shows the following:
TN9( net0 \1\:SH5\voutcm net1 net1), and the resistor netlist is showing up as RRR0 ( SH5\voutcm ....)
There's the problem... the addition of "\1\:" in the gate terminal of TN9 effectively disconnected the resistor from the nmos's gate. Is anyone else aware of this issue or any potential fixes?
I use multisheet in cadence to document my design, so the TN9, and RRR0 both appear on sheet 5 of the design. Hence the SH5\ designation.
I then went back to the Assura QRC menu and chose C extraction only. My sims work fine, and my netlist for TN9 and RRR0 both have the same netname called "SH5\voutcm". In this case, there was no random insertion of "\1\:" into the netname...
Hi jimstuyI think the addition of "\1\:" is for the subnets formed by the parasitic resistors between the terminals of R0 and the mos gate terminal. If you check the netlist, you should be able to find parasitic resistors linking R0 and the mos gate. If you suspect that the netlisting problem lies with QRC, you can check it using gemini connectivity checker. When enabled, it will short the parasitic resistors and open the parasitic caps so as to check if the input to QRC is still equivalent to the output after the removal of the parasitic devices. You can enable gemini as follows:a. Add the following line to your cshrc file:setenv DBGRCX_CONNECTIVITY Yb. Source the new cshrc file and restart Virtuosoc. After running QRC, look at the log file for the results of gemini. If you still have any doubts, please upload the log file as an attachment.(Note that gemini is in semi-retired mode. The new checker is pvsnvn but we will not go into that for now)Best regardsQuek