Stats

  • Locked Locked
  • Replies 13
  • Subscribers 126
  • Views 5683
  • 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

IBM cms9flp & Assura QRC strange problem

jimito13

Hello all,

I will try to describe my problem the better i can.I have an op-amp design that consists of several cells (main opamp,gain boosters,cmfb,biasing).I have created the layout of all the above cells and i pass successfully from DRC and LVS runs (clean runs,no errors no warnings).The last step is to perform the parasitics' extraction and run post layout simulations.Well,here things become a little bit strange...Before i describe my problem in depth i must say that my design kit is IBM's cms9flp and the versions of cadence virtuoso and assura are IC6.1.3.500.13 and 3.2_USR2_HF11 respectively.

I run LVS for each cell successfully (clean results) and then i run successfully as well the assura QRC run (no errors-no warnings) for all my cells and the result is the well known message of assura with the av_extracted view's name and location in the library.

Next step is to simulate the av_extracted views.For this i create a schematic with all the above cells interconnected as symbols and i use the av_extracted declaration under Environment submenu of ADE L.

I run DC analysis at first and here is my issue.The currents in all branches of the circuit are far away from the designed values.From a quick thought you can say that i made mistake in transistor sizes during layout but this should be reported by LVS but in any case i double checked this by myself to be absolutely certain.Second thought is that i have not calculated correct the widths of all metals that make the interconnections in the design,i double checked this as well according to pdk's rules for metals and viases.With a more careful view in the values of the currents that dc analysis resulted i noticed that all of them are divided by the product (m*nf),where m is multiplicity and nf number of fingers!Looking at the vdd symbol i see that my circuit consumes X mA but if i add all the currents from the subcells i do not ever reach X/4 mA,so i ask myself where is the rest of the current consumed?!Another strange thing is that even though that all currents are wrong calculated the biasing voltages from the current mirrors are exact to the design values...

Has anybody else come up with such an issue with this or another IBM's pdk??Do you think that i should report this straightly in IBM's support??


Thanks in advance for any helpful answer.


PS. It is urgent for me since tape out date is close!!

Parents

  • Hi Jimito

    Here is what happens during QRC parasitic extraction:
    a. QRC reads in gds or DFII layout data and creates a netlist (let's call it "netlist_pre")
    b. RC parasitics are calculated for each net
    c. QRC writes out the final netlist that has RC parasitics (let's call it "netlist_post")

    Gemini opens all parasitic caps and shorts parasitic all resistors/inductors in netlist_post and compares it with netlist_pre. The 2 netlist must be equal. Otherwise it means that QRC has accidentally modified netlist_pre wrongly when inserting the parasitic RCs. Gemini does not check for parasitic resistor mismatches in symmetrical nets. This is not the purpose of gemini checking.

    I am not refering to layout or testbench problems. I am refering to design problems. I am wondering if the circuit is robust enough to within the addition of some parasitics. E.g. suppose I design an amplifier and get a very nice flat low-pass ac response. Layout and extracted view are then created and I proceed to do post layout sim on the extracted view. If my ac response now shows some peaking (e.g. 1dB), naturally I cannot conclude that QRC has given me a bad extracted view. It is simply because my amplifier is not robust enough to with the parasitics. For example, I might need to trade off some bandwidth for stability by increasing the compensation cap a little.

    You can also try adding some small resistors from analogLib into your schematic and simulate your circuit again using the modified schematic. If there are no problems, then most likely the problem does not lie with your circuit.

    I think your next step should be to simply try the latest version of QRC in EXT913HF2. If the simulation problems are resolved using this version, then it simply means that it is a bug and that it has been fixed in the latest version.

    Best regards
    Quek

Reply

  • Hi Jimito

    Here is what happens during QRC parasitic extraction:
    a. QRC reads in gds or DFII layout data and creates a netlist (let's call it "netlist_pre")
    b. RC parasitics are calculated for each net
    c. QRC writes out the final netlist that has RC parasitics (let's call it "netlist_post")

    Gemini opens all parasitic caps and shorts parasitic all resistors/inductors in netlist_post and compares it with netlist_pre. The 2 netlist must be equal. Otherwise it means that QRC has accidentally modified netlist_pre wrongly when inserting the parasitic RCs. Gemini does not check for parasitic resistor mismatches in symmetrical nets. This is not the purpose of gemini checking.

    I am not refering to layout or testbench problems. I am refering to design problems. I am wondering if the circuit is robust enough to within the addition of some parasitics. E.g. suppose I design an amplifier and get a very nice flat low-pass ac response. Layout and extracted view are then created and I proceed to do post layout sim on the extracted view. If my ac response now shows some peaking (e.g. 1dB), naturally I cannot conclude that QRC has given me a bad extracted view. It is simply because my amplifier is not robust enough to with the parasitics. For example, I might need to trade off some bandwidth for stability by increasing the compensation cap a little.

    You can also try adding some small resistors from analogLib into your schematic and simulate your circuit again using the modified schematic. If there are no problems, then most likely the problem does not lie with your circuit.

    I think your next step should be to simply try the latest version of QRC in EXT913HF2. If the simulation problems are resolved using this version, then it simply means that it is a bug and that it has been fixed in the latest version.

    Best regards
    Quek

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.