Inherited connections and explicit pins

Hi,
I have studied the inhconnflow.pdf for a while to find some arguments
in a discussion regarding why using inherited connections and not
explicit power pins. In the manual for the 5.1.42 version I read that
Cadence recomends using schematic pins with netSet property on them.
This feature is built into the place pin dialog and is basically not
the problem. There is a statement that such a pin with a netSet can
show up in the schematic, but does not need to be placed in the
symbol. When I do check and save I still get a warning that the pin
myGnd is not present in the symbol for my block. I checked the rules
dialog for the checking and there seems to be no option to turn off
warning for explicit netSet pins. I find it annoying to have a warning
where no warning is needed, but I would not turn off the warning
globally, as I might have the case that I have placed a signal pin
that I have actually forgot to put in the symbol and hence have a non-
functioning schematic without knowing it.

Anyone know something more on this topic?

 

I pretty much arrived at the same conclusion that you did. I couldn't
find a way to shut off the warnings for those pins without disabling
pin warnings globally which I found unacceptable.

-Dan

 

There is a statement that such a pin with a netSet can

I think this statement you are mentioning is kind of weird. Why would one draw a pin in the
schematic and not in the symbol, when in such a case the schematic pin would be totally useless?

Based on my understanding, there are three ways to proceed :

- use explicit power/ground pin in both the schematic and symbol. The power pins have to be
connected on the higher lever.

- use net expressions (on wires, no terminal) in the schematic, no power/ground terminals in the
symbol. The connection on higher levels are implicit and overridden by adding netSet properties on
the instances.

- use inherited terminals (ie, explicit terminal with net expression) on both the schematic and
the symbol. In that case, the power/ground pins are present but they don't need to be explicitely
connected at higher levels. They can be connected either by explicit connection or by adding a
netSet property.


I personnaly use the last option and find it satisfying. I however noticed that sometimes explicit
connection of a wire to an inherited terminal fails, and I have to add a netSet as well. I have
never digged further.


From a semantic point of view, it seems that you are mixing the concepts of "net expression" and
"netSet" which are two related but different things. The net expression is the specific syntax
([@GND:%:gnd!]) which defines an inherited connection. The netSet is the type of property that is
used to override inherited connections.


Stéphane

 

I spent many months trying to make Inherited Connections work from a
Layout perspective, with no luck. After speaking with Cadence many
times, their final answer is use Inherited Connections only for
Simulations purposes (it will speed up simulations) and if you are
doing place and route type Layout. I believe if you are using
Inherited Connections in a very basic manner, such that you are not
renaming nets as you travel through hierarchy you probably can still
use it, but if you want to pass different pwr/gnd names down through
the hiearchy forget about it. The 2 big issues are using VXL to place
devices and with LVS verification. When VXL is run it opens the
specified schematic standalone, so it doesn't know what net names are
being passed down from above hiearchy, so it will generate the
incorrect pin names. And with LVS it will export the schematic at the
specified level, not knowing what nets are being passed from above, so
you'll run into pins name problems.

 

I would hope that somebody from Cadence will step up and do some
explanation because I find this experience in contradiction to what I
read in the manual. I will keep this in mind during further work.

 

would it? I thought you would be enforcing a pin in the layout and
hence have a clear interface from one block of layout to the next. I
am not so experienced in VXL and layout so I was antisipating an
additional help for the helpless....

Damn, why didn't I think of that? A pin that you can connect if you
like to, but if you rather like it the netSet way, then just attach
those netSet properties. Would have killed the discussion at the
beginning. We were discussing the explicit vs. netSet way of hooking
inherited connections to the next-upper level. It does perhaps look
weird to have power and ground pins that are not explicit connected?
How does old designers gut-feeling react to seeing unconnected supply
pins during design reviews?

Semantically, I have two left hands with 10 thumbs.

But the concept of using schematic-only pins is not that stupid as you
are protecting the designer against information that would only hurt
him even if he knew how to deal with it.

 

OK, sorry everyone for me being slow in responding to this - I got rather held
up with other things, and hadn't had a chance to catchup with comp.cad.cadence.

The idea behind the "explicit pins" inherited connections methodology is to have
a pin on the schematic with a well defined name. So, you might create a
pin called "vdd" with a net expression (not a netSet; net expressions define
the inherited connection, whilst net sets override the default value of
a net expression at a higher level).

First of all, to make your life easier, there are a couple of options on the
inh conn tab of the Options->Editor form. These allow you to cause the
property name and default to be automatically defined from the pin name
or property name (for wires). Whilst you have the flexibility have the pin name,
property name, and default value all completely unrelated, this flexibility
can for many customers make inh conn harder to use. There are cdsenv
settings to control these defaults, and it's possible to customize how the
seeding is done (see the variable schPinNetExprGenFunc in the
Virtuoso Schematic Editor User Guide). This change happened in IC5141 USR3.

Once you've added a pin (for example, a pin "vdd" with a net expression, with
property name vdd, and default value vdd!), you'll want to make sure that
check-and-save doesn't complain about the pin mismatch because the pin
isn't on the symbol. This can be done by going to Check->Options. On this
form, if you turn off "Match Inherited Terminals", or if you specify (say)
"symbol" in the "For Views" field, it won't complain during check-and-save
that you have the pin in the schematic, but not in the symbol.

Next thing you might want to know about is that when doing a Design->Create
CellView->From CellView, then on the Edit Options form that appears, there's
a choice to Exclude Inherited Connections (again, there's a cdsenv setting
for this) so that it will filter out the vdd pin when generating a symbol.

OK, so far so good. Now to why you want to do this!

The benefit of having an explicit pin with a net expression, rather than just
a wire with a net expression (the implicit pin model) is that when you use
VirtuosoXL, you want to have a physical pin for the supply. Obviously in
layout, all pins have to be physical - you need to wire things up. With the
implicit model (i.e. a net expression on a wire, or a net expression at a lower
level of hierarchy), you end up with a pin created with a global name (the
default value of the net expression). This tends to cause trouble in some
external tools who don't like "!" in the name, as well as not being very clean;
the name ending in "!" suggests it is global, whereas as a pin, it's not really.

With the explicit pin on the schematic, you'll get a pin in the layout with the
name you gave it in the schematic. It's a well defined pin name, which can then
work with (say) DEF and so external place and route, physical verification
tools and so on will be happier with this.

From the schematic side, there's no disadvantage of having the pin there
over a net expression on a wire. You have the convenience of having a symbol
without the pin - so you can avoid the clutter on the placement of this block.
You can override the net expression several levels of hierarchy up (by adding
a netSet for vdd at some higher level). So you could have standard cells
without supply pins (for example) which get used by digital and analog designers
alike. The analog designers can use them and then set (at some higher level)
that they want vdd to be equal to their supply pin "avdd" (say). The digital
designers can set it to "dvdd", or leave it at default.

I hope this rather lengthy and delayed reply helps!

Regards,

Andrew.

 

I remember seeing a complete tutorial on inherited connections which is
available on sourcelink which covers the topic in fantastic detail.

 

Did the tutorial cover the inherited pins? I run through that tutorial
once, and it covered the inherited nets concept, but it was too early
for the inherited schematic pins to be an issue. Maybe I have to
recheck.

 

Indeed. I noticed the ignore net expression pins on the generate
symbol form, but I did not know about the setting to ignore it on the
symbol.

Having that inherited schematic pin as explicit pin on the symbol is
really not that bad when you get used to it. If you want to connect it
to a different source, please do so, otherwise it will be attached to
its default.

The only thing that I think is a bit annoying is the fact that
different net properties cannot have the same default net. Example is
a differential stage where the input transistors have their bulk
connected to a net with net property name m1vss (nmos in triple well
process) and default is vss! and the rest of the nmos transistors are
connected to a net with the property name of vss and default vss! This
is an error in 5.1.41_usr3 and force me to have another global power
supply called, say m1vss! If my circuit have many separate bulk
connections, the symbol would be pretty filled with net expression
pins as I would not like to ignore the bulk contacts.

The pick-up speed of the 6.x series of cadence seems to be a bit slow
among foundries, specially the smaller ones. Nice that 5.1 still get
some nice upgrades.

 

This is a consequence of how it's implemented. The default net defines the net
name in the cellView - and any other connections within the same cellView to
vss! are part of the same net which has the inherited connection. Consequently,
since this is a single net, you can't have more than one net expression
controlling it.

Note that there are checks (which can be applied at netlisting time) to
ensure that all net expressions are set somewhere (i.e. nothing remains at
its default) - which you can turn on. Can't remember the setting off the top
of my head, but I recall it being requested by the company you work for ;-)

Regards,

Andrew.

 

I noticed the actual location of the inherited-connections tutorial
wasn't in this thread so I post is merely so interested viewers could
obtain the tutorial for themselves.

http://sourcelink.cadence.com/docs/files/Tutorials/inheritedconnectiontutorial.html

I should also note I'm particularly interested in promoting this
specific-flow-topic tutorial since my old flow engineering team was
the original creator of this tutorial at my request before it was
rightly picked up by the wonderful training and educational services
group and vastly improved thereafter.

The point was (and is) to provide you (the Customer) with the complete
documented and supported flow, complete with special situations,
starting from schematic and working your way to layout, extraction,
and parasitic resimulation.

Scores of bugs were filed and fixed before this flow could be released
so that you wouldn't have to run into them yourselves.

As always, so everyone benefits from every action,
John Gianni