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

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!

Parents

  • 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.

Reply

  • 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.

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.