Doctorate Dissertation needed for "StrongGroup"

Hi,

LVS caught an open that the online tool didn't. This is analog data
and had fets that are interdigitated, I am not sure that matters.
When I look at the mapping to the devices on the node in question I
see net046_StrongGroup4. If I take the StrongGroup4 mapping and
replace it with net046, the net is then open in the "Show Incomplete
Nets" form(if it was previously, I would of had a clean LVS run is why
I care ;-).

I wish to understand this better, so if someone could explain it to me
in detail or show me where to read up on this that would be great. My
assumption is the tool is using "StrongGroup" to try to keep track of
what is open or not.

Also, is there some script, workaround or idea to find or erase this
type of data error, if that is what it is, that would be really,
really appreciated.

Thank you in advance,
PolyPusher.

 

Hard to answer without seeing the data. Interdigitated FET means that
the device terminals (G D S B) have several pins each (D1 D2 ..). It
is important to have the right connectivity between these multiple
pins defined inside the PCell. "Strong" actually means that the pins,
lets say D1 and D2 have a solid metal connection inside the cell and
it's sufficient to only connect to one of them. There is also "Weak"
which usually means a poly connection between the gate pins (to avoid
these pins to be used as feedtrough) and "Must" which means the pin
needs to be connected.
In you case it seems that the "Strong" connect definition is wrong and
would need to be set as "Must". Still without actually seeing the data
it's hard to judge. Check the Skill of the PCell if these connectivity
types are defined correctly.

Regards,
Marc

 

* StrongGroup makes me thinks about the strong connect relationship between
pins. IE pins that you said to the extractor: they will be connected
inside the instance, you can assume that they are connected and drive
current by this way -- they may not be connected in the "abstract" layout
you are using, but you state that you'll switch to a true layout where they
are connected. (The other 2 relationships are "weak connect": they
are connected inside the instance, but you can't drive current that way,
the extractor checks that one of the pin and only one is connected; and
"must connect", they aren't connected inside the instance and the extractor
must ensure that they are outside).

* The other thing that StrongGroup makes me think about is "pseudoparallel
connections". Nets which are at the same voltage because of the way they
are driven, but they are not connected. See the corresponding sections in
doc/vxlhelp/vxlhelp.pdf, chapter "Preparing your design for routing".

If that doesn't help you, I'd need more information
1/ which version of the tools
2/ who named the net net046_StrongGroup4?
- VLS-XL layout generation (Generate From Source)
- VLS-XL extractor in interactive mode
- VLS-XL extractor in batch mode
- the LVS?
3/ did you try the VLS-XL extractor in batch mode
(Connectivity|Re-Extract Layout or Connectivity|Update|Extract Layout
depending on the version)
4/ to which instances and terminals are connected the nets net046 and
net046_StrongGroup4 and any information of this type that you find
relevant.
5/ Do you have pseudoparallel connections, do you have m factor placed
on hierarchical instances?

Yours,

 

Marc,

It seems to happen on Source an Drain only. Is there a piece of code
that you could give me that would tell
me what the defintions are(strong, must and weak)? Is there a way to
change the settings at the top cell rather than the master cell.

Thank you for your help.
PolyPusher

 

Marc,
We are using version 5.141 in Layout XL mode

1.The issue is coming up when we have pfets or nfets with GSD and when
we run Layout XL update components and nets, the "Strong_Group"
addition to the signals appear. (VLS-XL layout generation (Generate
From Source)

2.If I remove the "Strong_Group" from the connectivity model using
propagate nets(leHiPropagateNets)

3/ did you try the VLS-XL extractor in batch mode
This doesn't apply since these are pcells?

4/ to which instances and terminals are connected the nets net046 and
net046_StrongGroup4 and any information of this type that you find
relevant.

The are all drains of the pfet pcell. If the StrongGroup4 is
removed, then the net is in the Show Incomplete Nets list
as incomplete.

5/ Do you have pseudoparallel connections, do you have m factor
placed
on hierarchical instances?

I am not sure, would this apply to a pcell that is instantiated at the
topcell.

I wouldn't make a big deal of this, but are group is seeing this often
and it is
slowing us down as we have to go into debug with LVS.

Thank you,
Eric

 

Could you try with layoutXL envVar setPPcon set to nil?

The nets are internal to the Pcells?

Yours,

 

Could you try with layoutXL envVar setPPcon set to nil?
I set to nil as you suggested and performed an update components and
nets,
this didn't work.

This case is very straight forward. This issue is showing up on pfet
and nfet cmos pcells. The pcells have
a gate, source and drain. There are no opens at the pcell level.
When these pcells are used in the topview,
nets in the connectivity model are getting a suffix added to a subset
of nets, for example net051_StrongGroup_2.
This appears to happen durning layout XL.

If write a bit of skill and use it on this layout(hoping this will
help our communication gap)

cvLay=geGetEditCellView()
when(cvLay
foreach( instTerm cvLay~>instances~>instTerms
EFLayNet=instTerm~>net~>name
println(EFLayNet)
);if
);unless
);foreach
);when

I get for net046 that should be in the Show Incomplete Nets(LVS found
the open, incomplete nets didn't)
("net046_StrongGroup_4" "net0142" "net082")
("net046_StrongGroup_3" "net0142" "net082")
("net046_StrongGroup_2" "net0142" "net082")
("net046_StrongGroup_4" "net0106" "vcc")
("net046_StrongGroup_5" "net0106" "vcc")

The net is still "net046", the connectivity, the name "attached" to
the instance has this "StrongGroup" suffix appendage.
I did notice that for every device that has this "net046_StrongGroup*"
attached if I go back and attach "net046", incomplete nets catches the
open.

Thank you for your efforts on this issue,
Eric