• Skip to main content
  • Skip to search
  • Skip to footer
Cadence Home
  • This search text may be transcribed, used, stored, or accessed by our third-party service providers per our Cookie Policy and Privacy Policy.

  1. Community Forums
  2. Custom IC Design
  3. QRC Parasitic Extraction Issue (netlist has source/drain...

Stats

  • Locked Locked
  • Replies 11
  • Subscribers 126
  • Views 6758
  • Members are here 0
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

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

jimstuy
jimstuy over 14 years ago

Hi,

   I am working on a analog design in Cadence IC6.1.4.500.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!

  • Cancel
Parents
  • Quek
    Quek over 14 years ago

    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

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
Reply
  • Quek
    Quek over 14 years ago

    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

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
Children
No Data

Community Guidelines

The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.

© 2025 Cadence Design Systems, Inc. All Rights Reserved.

  • Terms of Use
  • Privacy
  • Cookie Policy
  • US Trademarks
  • Do Not Sell or Share My Personal Information