question on double extraction issue in RF mos

[snaildr]

Hi all

I'm a student new to circuits. Recently I've been working on a CMOS tapeout using TSMC 65nm RF CMOS process and ran into an issue with the foundry RF MOSFETs. After spending some time debugging I'm still puzzled. I'd really appreciate your input. I currently left some of the numbers in this posting as "X" for confidentiality reasons, but I'd love to share them and also some screenshots via message, if you have the access to the PDK.

I was trying to design a traveling-wave amplifier, using foundry RF mosfet and HFSS simulated transmission lines. I found that post-layout simulation showed significant bandwidth degradation compared to schematic simulation (BW dropped from 71GHz to 46GHz). I was able to locate that the main problem is the parasitics from the RF mos (nmos_rf), because when I did a "skeleton" extraction by keeping everything in the layout but the nmos_rf, the bandwidth reached 64GHz.

Then I did ft simulations on the nmos_rf that I was using. The setup is just a two port S-parameter simulation of the mos with (gate, gnd!) being port1 and (drain, gnd!) being port2, and watch the H21 crossing 0dB to get ft. In schematic simulation I got ft= X GHz. Then I created the corresponding layout by using one nmos_rf layout from the library and placed pins for the 4 terminals (the pins are on "pin" purpose layer so they shouldn't create actual shapes). Post-layout simulation was done by both Assura QRC (RC mode) and Calibre PEX (R+C+CC mode), the resulting H21 curves from Assura and Calibre almost overlap exactly. But they are very different from the H21 obtained from schematics simulation, and the ft now is only 0.73*X. Similar thing for fmax, but in the fmax case Calibre generates more pessimistic result than Assura. When I opened the av_extracted view or the calibre view, I saw parasitic resistors and capacitors inside the nmos layout region (on the fingers, on the guard ring, everywhere).

I was under the impression that the foundry builds RF mos models specifically for these nmos_rf, so that Assura and Calibre shouldn't go into the cell to do extraction, right? During schematic simulation I certainly saw the RF model elements such as the gate resistance rgx and metal capacitance cgs_m, cgd_m etc being calculated correctly compared to what I get based on the RF model manual. I think these elements are being used too, because if I replace RF mos with non-RF mos I got significantly better results. So, it seems to me Assura and Calibre are doing double-extraction, do you know how to fix this?

thanks a lot,
Ran

 

[erikl]

Assura -- being a C@dence tool -- follows the view list & stop list mechanism. So if you remove (hide, disguise) the schematic of the cell (nmos_rf), extraction will stop at the symbol and cannot intrude in its inwards.

With C@libre I don't know, but I think there are appropriate options.

 

[dick_freebird]

Within the Cadence environment, extract algorithms might
exclude the intradevice geometries from parasitic extraction
(these being embedded in the device model instead). But an
external tool without such LPE-block comprehension will pull
all capacitances including those already in the FET model
(Cgd includes the gate poly - drain metal fringing within the
device extents, and so on).

GDS file stream-out may not include these non-mask layers
and an external tool might have nothing to go by, if so. That
can all be fixed by extra effort.

 

[snaildr]

Assura -- being a C@dence tool -- follows the view list & stop list mechanism. So if you remove (hide, disguise) the schematic of the cell (nmos_rf), extraction will stop at the symbol and cannot intrude in its inwards.

With C@libre I don't know, but I think there are appropriate options.

Hi erikl

Thanks for the reply. The nmos_rf cell is a pdk component, it doesn't have a schematic view. I think right now the extraction tool has to stop at symbol. One thing I can think of doing is to declare the cell as a black box in Assura, but then I'll have the risk of messing up the connections from the layout into nmos_rf, because the LVS doesn't keep anything but the pins of a black box cell.

I feel TSMC pdks are so popular, someone must have run into the same issue, and found a solution other than black-boxing stuff...

Ran

---------- Post added at 22:00 ---------- Previous post was at 21:46 ----------

Within the Cadence environment, extract algorithms might
exclude the intradevice geometries from parasitic extraction
(these being embedded in the device model instead). But an
external tool without such LPE-block comprehension will pull
all capacitances including those already in the FET model
(Cgd includes the gate poly - drain metal fringing within the
device extents, and so on).

GDS file stream-out may not include these non-mask layers
and an external tool might have nothing to go by, if so. That
can all be fixed by extra effort.

Thanks for the reply. Yeah, excluding the parasitics is exactly what I need the extraction to do. So, I actually would hope the tools can make use of the non-mask layers (you mean the RF recognition layers, right?)

 

[dick_freebird]

How it works, depends on the CAD group. I see lpeblock1
and lpeblock2 layers, and I haven't ever looked at which
does what. The extract can get pretty elaborate, and for
high performance RF it has to be. to be accurate.

In the native CAD environment the PCell for a RF device
ought to have a few non-mask layers down in it, and the
naming of these might tell you what one(s) are tagging the
internal features for no-extract.