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.

Calibre LVS error "bad component subtype" with MIM capasitor changed

Status
Not open for further replies.

NOmalum

Newbie level 3
Joined
Nov 9, 2010
Messages
4
Helped
0
Reputation
0
Reaction score
0
Trophy points
1,281
Activity points
1,314
I've installed new PDK with same technology tsmc 0.13 um.
The only thing changed was MIM capacitor to lower density capacitor from "1.5fF_MIM" to "1.0fF_MIM".
When I copied the schematic and checked the Calibre LVS, the error came out is:

bad component subtype:
layout | source
------------------
MN(N2) | MN(ND)

But this is not occured with "1.5_MIM" capacitor PDK.
I don't know exactly what is causing this descrepancy.
And I changed the fule file for "1.0fF_MIM" cap when I checked it.
Does it mean that rule file causing some mismatch? and if it is how to fix it?
Thank you!
 

Pls change MIM cap type from ND to N2 in cdf.
 

Hi leo_o2
It was a NMOS transistor, which was causing an error.
I went to Tools->CDF->Edit and I found the NMOS transistor and I changed cdlmodel: from ND to N2. However, the error still exits :( !
Please, correct me if i am editing cdf wrong way!
 

Hi NOmalum

first of all make sure that this is not an actual error that escaped the previous version of the rules, if the layout pcell is actually a match for the schematic symbol then verify which netlist (layout or source) is not correct.

If it is the source, then change the CDF of the auCdl simulator, which is used by Calibre for LVS netlisting

If it is the layout netlist that uses the wrong subtype then you need to change the rules and modify the extraction rule accordingly

Let us know if you need more help
 

Hi NOmalum

first of all make sure that this is not an actual error that escaped the previous version of the rules, if the layout pcell is actually a match for the schematic symbol then verify which netlist (layout or source) is not correct.

If it is the source, then change the CDF of the auCdl simulator, which is used by Calibre for LVS netlisting

If it is the layout netlist that uses the wrong subtype then you need to change the rules and modify the extraction rule accordingly

Let us know if you need more help


Hi dgnani,

1. I checked with previous version, there is no error, sicne i've alreayd submitted for fabrication of last version.

2. I think the error is not coming from source, becasue the bad subtype is directing it to layout

3. So, if i had to change rule files how should I do it?

In rule file I found the DEVICE MN(ND) [.....] and DEVICE MN(N2) [...]. They are identical for PDK type of "1.5fF_MiM" and "1.0fF_MiM", no difference!

--
Thank you!
 

To be easy, you can replace ND to N2 in cdl file. It is a txt format file.
Then use new cdl file for lvs checking.
Something wrong in your cdf change.
 

Hi dgnani,

1. I checked with previous version, there is no error, sicne i've alreayd submitted for fabrication of last version.
ok
2. I think the error is not coming from source, becasue the bad subtype is directing it to layout
Calibre cannot know how the foundry messed up so look into the header of the LVS rules where usually TSMC lists all the device subtypes and see if the device type you are trying to use in the schematic is the one extracted in the layout or CDL netlist
3. So, if i had to change rule files how should I do it?

In rule file I found the DEVICE MN(ND) [.....] and DEVICE MN(N2) [...]. They are identical for PDK type of "1.5fF_MiM" and "1.0fF_MiM", no difference!
if it turns out to actually be an extraction issue, then simply change the name in the rules to match the CDL name

Leo_o2:
Doing the opposite change and changing the CDL netlist when the problem is in the layout extraction has the dangerous side effect that two different devices might be mapped to the same subtype, then your LVS check could not tell the difference...
--
Thank you!
 

But many times, these probblems were caused by inconsistent between pdk and lvs command file.
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top