QRC Parasitic Extraction Issue (netlist has source/drain flipped on many instances)

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!

 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 jimstuy

Here 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 regards
Quek

Hi 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 jimstuy

a. 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 regards
Quek

The switch is called "resimulate_extracted".  If that doesn't help you should contact your support provider.  Regards, 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...