Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

[SOLVED] very weird calibre view parasitic simulation

Status
Not open for further replies.

starsunmoon

Junior Member level 1
Joined
Apr 12, 2008
Messages
17
Helped
0
Reputation
0
Reaction score
0
Trophy points
1,281
Activity points
1,403
Hello everyone,

After passing DRC/LVS, I did a parasitic-extracted calibre-view simulation on a top level analog circuit block, and results were mostly off : a few sub blocks were correct but most sub blocks gave weird values (a couple hundred millivolts near power rails). However, switching back to schematic simulation still gave correct results.

So instead of using a top calibre view for the top level block, I kept the top block in the schematic view and converted all its sub blocks into calibre views one-by-one. Re-simulated, and results were as correct as schematic simulations.

Even weird, I generated a top calibre view again for the top level block, except this time with parasitic switches off (so no parasitic was generated). Then re-simulate the parasitic-free top-level calibre view, and results were as wrong as my previous top calibre view results with parasitics.

Wondering if someone knows any reason or suggestions.
Very appreciated !
 

Try to check if the "Output looped resistance to RC netlist" is switched on. (PEX Options -> Netlist)
 

Check the netlist and compare the pins in the subckt definition:
- are all pins there?
- are they in the correct order?
- are there missing globals (substrate in particular)
 

Just weird, the problem is.

I am using calibre v2010.1_22.19, and there is no switch called "Output looped resistance to RC netlist" so seems not applicable here.
Those checking items are very important, so in this case I double checked the hierarchy of some of the failed sub blocks, and could not find anything abnormal.

Though, great to have some kind hints from sdedov and dgnani, again very appreciated.
 

Another item on the checklist for subckt pins is probably:
- assuming you are using them, are inherited pins in the extracted subckt definition?

In my experience pins and the ground name are the most common failure modes when the postlayout netlist behaves nothing like the schematic.

Other things to consider:
- using the version of PEX used to generate the extraction rules OR PDK recommended version
- extracting w/o parasitics very often generates a broken netlist, it is better extracting with CC only (no R) and see if that fails as well

I will keep this running in the background but it would really help if you could give us extra details:
- which process are you using? below 90nm parasitics and extracted second order effects can completely throw off an analog design (e.g. current mirrors can fail!)
- type of design? again if the extraction is correct things that can go wrong depend on what's in your design
 
Last edited:
If your simulation without parasitics is weird, then your devices are not being generated properly. In the calibre view, query the properties of one of your devices. Does it look right to you? Also, in the calibre view generation window, make sure that in the Reset Properties field, that you have your multiplicity set to 1.

For example, if your multiplicty factors are mult and NF, then the Reset Properties should say:
mult=1 NF=1 (I think that's the syntax anyways)

Hope this helps.
 
Very good point 9patch, using a calibre-view output adds an extra layers of things that can go wrong, namely the map to library devices.

It might be helpful for debugging to try a simple netlist output for the simulator you are using or -if you know how to handle it- DSPF
 
Indeed. All very good points ! I am using a mixed 110nm to 150 nm process.

The Calibre tool seems a little fragile as I fixed the reset property several months ago. So that is not an issue. Cadence is kind of over-smart sometimes, causing unnecessary problems though might not be the reason this time.

Will let you know after I do a detailed check on netlist as suggested above - unfortunately will be only on a few sub cells. Otherwise, it really is reverse-engineering an IP from calibre, except with a little advantage of knowing the circuits. Try to avoid that cause dont know how long will take to finish if ...
 

I'm late but couple remarks anyway:
As said above the problem could be in the pin order of subckt definition/call.
- if you are using Cadence schematic view to the netlist extraction for Calibre you should be so careful with the subcircuits CDF properties like pin order. Try to check if this property is the same in the CDF and symbol. Otherwise if you are using using other translator instead of auCdl for your simulator (like spectre, mmsim, etc) you can get other netlist and sim result, of course.

- check also you .simrc file. It should contain auCDL properties related to pin order check/translation. Sorry, dont remember exact names and value for it combinations, but i could check it if you are still interesting. Or you can read Cadence's "Translators manual".
 
Finally figured out.

The order of some transistors were wrong especially on the sub and source nodes. Weird enough, most of them were correct but some were wrong (even for an identical cell with multiple locations of usage), and happened on both nmos and pmos. So the tool basically was not all right which was a little scared - either the tool or the tool guy.
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top