What is the right format of "Subcircuit file" for defining "scasubckt" cell in "analogLib" library?

Hi, 

I have an elementary question.

I am using Cadence Virtuoso version IC6.1.7-64b.500.18. My goal is to include post-layout parasitic capacitance and resistance to the original ideal circuit. The parasitic cap/res can be in hundreds, so it is time consuming to instantiate each of them in the schematic. Clearly, there is more efficient method, for example, pass those parasitic R/C elements in a file to the circuit. Could you advise the typical way to do so? I know I can simply include the R/C list in model file of ADE. But if the R/C file is only for a subcircuit of a hierarchical circuitry, it does not work when doing top level circuit simulation since CIW cannot recognize subcircuit nodes and thus does not know where to attach those R/C elements.

One cumbersome way I am trying is as follows: instantiate a "scasubckt" cell from "analogLib" library into the original ideal circuit schematic --> connect the 24ea pins of the "scasubckt" cell to the original circuit --> attach the parasitic R/C file to the "Subckt file" CDF parameter of the "scasubckt" cell, as fig 1. Now the problem comes:

1. the input/output pin name of the "scasubckt" is by default named as b1, b2, etc. Assuming b1 is connected to VDD, b2 to s1, in the higher level circuit, as shown in fig. 1. Which name should I use in the CDF "Subckt file", b1/b2, or VDD/s1?

2. What is the right format of "Subckt file"? When I use format like fig.2, CIW complains "instance is referencing an undefined model or subcircuit".

Thank you!

Fig.1

Fig.2

I joined your duplicate posts together to avoid confusion.

Where is this parasitic data coming from? This seems a very odd flow to me, and certainly it's an abuse of the use of scasubckt which is part of the flow for subtrate extraction in Quantus (or was, I can't remember whether it's still used). If you really are going to use this approach, your included file would need to have:

subckt parasiticRC VDD s1 s2 s3 ,,,

at the top and:

ends parasiticRC

at the bottom. You'd have to be very careful to get the order of the ports in the subckt to match the b1, b2, b3 pins in order for the scasubckt instance as the connections are pass-by-order.

As I said, this is a very strange approach. If you were including parasitics from a parasitic extraction tool, you'd normally use either an extracted view representation from that tool (and with Quantus you could use SmartView although you'd need to be using an IC618/ICADVM20.1 version or extracted view if using an older IC version), or generate DSPF which can then easily be included with the "DSPF files" on the Setup->Simulation Files setup in ADE.

Andrew 

I joined your duplicate posts together to avoid confusion.

Where is this parasitic data coming from? This seems a very odd flow to me, and certainly it's an abuse of the use of scasubckt which is part of the flow for subtrate extraction in Quantus (or was, I can't remember whether it's still used). If you really are going to use this approach, your included file would need to have:

subckt parasiticRC VDD s1 s2 s3 ,,,

at the top and:

ends parasiticRC

at the bottom. You'd have to be very careful to get the order of the ports in the subckt to match the b1, b2, b3 pins in order for the scasubckt instance as the connections are pass-by-order.

As I said, this is a very strange approach. If you were including parasitics from a parasitic extraction tool, you'd normally use either an extracted view representation from that tool (and with Quantus you could use SmartView although you'd need to be using an IC618/ICADVM20.1 version or extracted view if using an older IC version), or generate DSPF which can then easily be included with the "DSPF files" on the Setup->Simulation Files setup in ADE.

Andrew 

Dear fireonthesee88,

fireonthesee88 said:

My goal is to include post-layout parasitic capacitance and resistance to the original ideal circuit. The parasitic cap/res can be in hundreds, so it is time consuming to instantiate each of them in the schematic.

If I might add to Andrew's comments that I hope will add some insight into the "problem" you would like to address.

I think it is a far more difficult task that I think you will soon appreciate if you happen to read my two basic comments.

1. Basically, when you try to include the parasitic resistances into your schematic, you need to change the topology of your circuit. An extracted  view of a layout with both parasitic resistances and capacitances "fragments" each schematic node to insert parasitic resistances and capacitances between the beginning and end of the net as well as potentially values between the net and any neighboring layout features. As such, if you have a schematic view based netlist with N nets, your netlist based on its extracted view contains M nets where M >> N. Hence, it is not possible to simply add a file of parasitic resistances and capacitances (as a file as you described in your post) to a Virtuoso schematic and create a Virtuoso schematic that now represents the topology of the extracted view based netlist.

2. The second complication is a result of most modern device models. Usually, a PDK calls a macromodel of an MOS device that includes estimates of its parasitics - which are pure guesses - in order to provide a better match to what its performance might provide when a layout of cell using the device all provide. When a netlist using the schematic is created, the PDK substitutes the macromodel for the required MOS device. However, when a netlist is composed from an extracted view, the PDK substitutes the "base" device model (i.e., NOT a macromodel) since the extracted view will innately include the "actual" layout parasitics and there is no need to estimate the parasitics. Now the complication for your specific need....if you add the layout based parasitics to a Virtuoso schematic (even if you manually break all the schematic nets to include the "fractured" nets in the layout based extracted view), your netlist will now include BOTH the estimated parasitics of the MOS macromodel AND the actual layout based parasitics. Hence, you are effectively "double counting" parasitics. The performance of the annotated schematic view based netlist will now not accurately represent the extracted view based netlist in a circuit simulation - which was your goal.

In lieu of your proposed methodology to better understand the impact of layout parasitics on circuit performance using a schematic representation containing all the layout parasitics, I would suggest using a layout tool that can assess the parasitics on traces that your knowledge and intuition suggest will be very sensitive, As an example of a valuable tool that I have used for this, which has features that far exceed this capability is Paragon X. It is described by its manufacturer Diakopto at URL:

https://diakopto.com/products

I hope this provides some added thoughts toward your posted desire fireonthesee88!

Shawn

Hi Andrew, thank you so much for your timely reply. I tried out the format you suggested about subckt definition, it works very well -  that is exactly what I wanted to do.

As to the flow, indeed it is abnormal and very specific to my task. I am using some stand-alone 3rd party extraction tool for parasitic capacitance extraction (no resistance), which does not have extracted view representation as Quantus does. The extracted parasitic capacitance is only btw/ schematic nodes (vs. fully distributed), thus the amount is not too huge. So this task is not typical "post-layout simulation", rather, it is more like sensitivity simulation to check impact on dominant parasitic capacitance.

Thanks,

Fireonthesee88

Hi Shawn,

Thank you for your insights. That is very helpful.

Luckily, my current task is a little simpler than a typical post-layout sim. My original post was probably confusing. Instead of adding parasitic R/C to schematic, I should have said parasitic capacitance only, in which case the schematic topology does not change, except adding capacitance btw/ existing nodes. The total number of parasitic caps are somewhat manageable. That is why I was going with the abnormal flow of the original post.

But thanks a lot again for your insight.

Best,

Fireonthesee88

Dear fireonthesee88,

fireonthesee88 said:

Instead of adding parasitic R/C to schematic, I should have said parasitic capacitance only, in which case the schematic topology does not change,

Thank you for this added information fireonthesee88! Great  - that certainly makes the task more manageable! Please do consider the second point I wrote in my initial response as I do not want you to overestimate the parasitic capacitance.

As a third alternative, do you know how to generate an extracted view that only contains parasitic capacitance elements? If you do, if you invoke the capacitance only extracted view to generate a netlist, it will NOT overcount the capacitances, It will also likely require a LOT less effort that trying to annotate all the parasitic capacitances to your Virtuoso schematic. In addition, you should be able to use all your schematic net names with the capacitance only extracted view when accessing its internal nodes as its topology and its net names match those of your netlist generated from the Virtuoso schematic.

For your information, in the design process I use, both a set of RC extracted view (parasitic resistors and capacitors) and a C only (extracted view parasitic capacitors only) are generated from the layout for use in netlist creation.

Thank you again, for the clarification and letting us know fireonthesee88!

Good luck with your simulations!

Shawn