double counting of MOM capacitors in extracted view

Dear Svilen64,

In a post-layout based netlist, treating a metal capacitor as a set of parasitic elements is often preferred as this permits one to include the impact of the local environment on the capacitor. 

This concept is discussed in a recent article by Mentor "Parasitic extraction of MIM/MOM capacitor devices in analog/RF designs" at URL:

https://www.eeworldonline.com/mim-mom-capacitor-extraction-boosts-analog-and-rf-designs/

or directly from Mentor at URL:

resources.sw.siemens.com/.../white-paper-parasitic-extraction-of-mim-mom-capacitor-devices-in-analog-rf-designs

where it states:

"During extraction of this design, the MOM capacitors are marked as pcells and their contents are not extracted. Only the interactions between the routing and the pcells are modeled."

I hope this helps Svilen...

Shawn

Hi Shawn,

I think you misunderstood my question. It is perfectly Ok to have the mom cap cells and the parasitics in parallel with them in the extracted netlist, However, what I see in the netlist is the cap cell itself AND a parasitic cap with the value same as that of the cell capacitor. As a result, the capacitance is doubled in value.

Svilen

Dear Svilen64,

Svilen64 said:

I think you misunderstood my question.

Obviously, MY response was not worded clearly enough  - my apologies Svilen64! That is exactly what I meant. Your extracted view based netlist contains BOTH the schematic PCELL for the CID capacitor AND a parasitic element that represents the capacitor. The article I referred to explains that the overall accuracy of the CID model is far greater when the schematic CID PCELL is removed and replaced with the capacitance of its feature layout elements in an extracted netlist. For example, the traces alongside a CID capacitor may have signals that add capacitance or couple into the capacitor whose effect will not be captured well if only the schematic PCELL is invoked in the extracted netlist. Hence, the extraction process must remove the CID  schematic based PCELL and in its place include the layout features comprising the CID.

I hope this explains my comment and the motivation for the included reference URL more clearly this time!

Shawn

Hi Shawn,

Yes, now it makes sense. The only thing for me to do is to find out how to force the extraction to remove the pcell and replace it with the extracted features only. So far it is not happening.

Thanks

Svilen

Hi, Svilen64, have you solved this probkem? I also encountered this problem, could you please share your solutions?

Thanks

Yong qi 

Hi, Svilen64, have you solved this probkem? I also encountered this problem, could you please share your solutions?

Thanks

Yong qi 

There is more than one way but here are a few things you might look at.  In the Quantus manual, look up the  "extraction_setup" command.  This is a command that goes in the .ccl file for the extraction run.  In particular, read about

  extraction_setup -parasitic_blocking_device_cells_file <file>

This is something that an engineer using an extraction setup can use and it blocks capacitance extraction to areas where the named devices are sitting.  I'm guessing your foundry provides that file and you just need to point at it.  Another option is when the QRC tech file is being compiled, the "-blocking" argument can be added to the compilation step. 

  Techgen -compilation -blocking lvsLayer|qrcgate[:grow_amt],procLayer1,...

That option blocks capacitance extractions to the listed process layers in the region defined by the lvs layer.  This is often used when some parasitic capacitance is going to already be accounted for or included by the model for the device.  Techgen is nearly always run by either someone in your EDA group or by the foundry and less typically by design engineers.  My feeling is there are few experts in the world on Techgen and it requires quite a bit of understanding of the process (for the -simulation step) and of the LVS deck (for the -compilation) step.

 The approaches above are to prevent something like a MOM (or even MIM) from getting extracted as interconnect when the expectation is the extracted netlist will instantiate a model for the device that has the capacitance.  Another approach if you want to remove for example MOM instances from an extracted view is use a custom callProc.il file.  You set this in the Quantus GUI Setup tab or with the CCL command "output_db -postprocess_extracted_view "callProc.il".  Read about this in the Quantus Extraction Users Manual in the Quantus Command Files section.  In short, this is a mechanism that allows your custom SKILL code to get called as pretty much the last step during creation of an extracted view.  It is fairly straightforward to write some SKILL code to find all instances of some cellview and delete the instances.  I'd probably use something like this to find the MOM instances and then use mapcar and dbDeleteObject for the deletion.

   all_mom = setof(X cv->instances X->libName == "myLib" && X->cellName == "myMOMcell")
   

I find this functionality helpful in a number of situations but you have to be quite careful because when you start modifying an extracted netlist you have an opportunity to accidentally modify your simulation netlist in an unexpected way.

Hope this is helpful.

-Dan

Hi, the tool that I used is Calibre, I find a way to block MOM capacitance which is that using Xcell files and set the extraction type to gate level. In my opinion, this method is blocking MOM capacitor, meaning that the extracted MOM capacitance is the same as the value in the schematic. 

I don't know if this method is feasible,  hope you can give me some advice about this approcah. Thanks a lot.

Yongqi

I am also having the same problem with MOM caps in calibre extraction using Calibre CB license and would appreciate if someone knows a solution to prevent the extraction from having double counting for MOM caps

The last couple of posts in this thread have been asking about extraction using Calibre. Well, my hint is that it would be far more sensible to ask this on a Siemens EDA forum (since Calibre is their product) rather than a Cadence forum (since Calibre is not a Cadence product). Or you could ask Siemens EDA support. Asking BMW about an issue with your Tesla would be a little strange...