instPin is nil

V

vlsidesign

Guest
I am at a company that does Analog/RF designs.

I was trying to automatically move top level pins on top of their
instance pin, etc. and it seemed real useful to access 'instPin'
attribute. It seems in the layouts I am looking at that it is always
nil. So I end up accessing the instance's pin through
instTerm~>term~>pin instead instTerm~>instPin.

I am farely new at this, so was just wondering if there is something
odd about my layout not to be using instPin attribute (I am using XL),
or if I am mistaken or something. Just hoping to get a little feedback.
 
On Jan 9, 11:35 am, "vlsidesign" <ford...@gmail.com> wrote:
I am at a company that does Analog/RF designs.

I was trying to automatically move top level pins on top of their
instance pin, etc. and it seemed real useful to access 'instPin'
attribute. It seems in the layouts I am looking at that it is always
nil. So I end up accessing the instance's pin through
instTerm~>term~>pin instead instTerm~>instPin.

I am farely new at this, so was just wondering if there is something
odd about my layout not to be using instPin attribute (I am using XL),
or if I am mistaken or something. Just hoping to get a little feedback.
I never found out why instPin seems to be nil always in our company's
designs, but accessing the pin through the other way in my skill
program worked just fine.... huh... maybe with more time and deeper
understanding I'll find out.
 
vlsidesign wrote:
On Jan 9, 11:35 am, "vlsidesign" <ford...@gmail.com> wrote:
I am at a company that does Analog/RF designs.

I was trying to automatically move top level pins on top of their
instance pin, etc. and it seemed real useful to access 'instPin'
attribute. It seems in the layouts I am looking at that it is always
nil. So I end up accessing the instance's pin through
instTerm~>term~>pin instead instTerm~>instPin.

I am farely new at this, so was just wondering if there is something
odd about my layout not to be using instPin attribute (I am using XL),
or if I am mistaken or something. Just hoping to get a little feedback.

I never found out why instPin seems to be nil always in our company's
designs, but accessing the pin through the other way in my skill
program worked just fine.... huh... maybe with more time and deeper
understanding I'll find out.
As far as I know there is no property called 'instPin' either in the
instance's dbId or in instTerm's. If you access any property that is not
there in any of the db objects, It will just return a nil.

When I searched for instPin, I got few results with references to
OpenAccess, which I do not quite understand. If you are talking about
OpenAccess route-s, Ignore my comments above.

-
Suresh
 
On Feb 4, 1:27 am, Suresh Jeevanandam <sure...@DELETETHISti.com>
wrote:
vlsidesign wrote:
On Jan 9, 11:35 am, "vlsidesign" <ford...@gmail.com> wrote:
I am at a company that does Analog/RF designs.

I was trying to automatically move top level pins on top of their
instance pin, etc. and it seemed real useful to access 'instPin'
attribute. It seems in the layouts I am looking at that it is always
nil. So I end up accessing the instance's pin through
instTerm~>term~>pin instead instTerm~>instPin.
snip
When I searched for instPin, I got few results with references to
OpenAccess, which I do not quite understand. If you are talking about
OpenAccess route-s, Ignore my comments above.

-
Suresh
In the "CellView Information Model", for instance on page 185 of
dfhelp.pdf document (Cadence Design Framework II User Guide), you
should see the instPin.

I am working in VirtuosoXL, and have these top level Terminals/Pins
that are associated to a net. I am trying to access the instPin (lower
level pins -- pins in the instances) that is associated with the net.

The idea for my script was that I could have hundreds of top level
pins in my layouts, and then automate some of the pin placements
(rather than zooming in manually selecting a pin, zooming out, and
then zooming in and placing it, etc.).
 
vlsidesign wrote:
<snip>
In the "CellView Information Model", for instance on page 185 of
dfhelp.pdf document (Cadence Design Framework II User Guide), you
should see the instPin.
I think we are using different versions. I do not have that page itself.

I am working in VirtuosoXL, and have these top level Terminals/Pins
that are associated to a net. I am trying to access the instPin (lower
level pins -- pins in the instances) that is associated with the net.

The idea for my script was that I could have hundreds of top level
pins in my layouts, and then automate some of the pin placements
(rather than zooming in manually selecting a pin, zooming out, and
then zooming in and placing it, etc.).

I also had to do something similar, I used to first find the pin name by
instTerm->name, then search for this pin in inst~>master~>terminals, and
once terminal is found, find the pin by term~>pins and access the figId
of the pin, and then map this figId to toplevel with dbTransform* functions.

-
Suresh
 
On Feb 6, 12:54 am, Suresh Jeevanandam <sure...@DELETETHISti.com>
wrote:
vlsidesign wrote:

snip

In the "CellView Information Model", for instance on page 185 of
dfhelp.pdf document (Cadence Design Framework II User Guide), you
should see the instPin.

I think we are using different versions. I do not have that page itself.
I am looking at the pdf file, Version 5, Sept 2003

I am working in VirtuosoXL, and have these top level Terminals/Pins
that are associated to a net. I am trying to access the instPin (lower
level pins -- pins in the instances) that is associated with the net.

The idea for my script was that I could have hundreds of top level
pins in my layouts, and then automate some of the pin placements
(rather than zooming in manually selecting a pin, zooming out, and
then zooming in and placing it, etc.).

I also had to do something similar, I used to first find the pin name by
instTerm->name, then search for this pin in inst~>master~>terminals, and
once terminal is found, find the pin by term~>pins and access the figId
of the pin, and then map this figId to toplevel with dbTransform* functions.
I would have to check my code but basically I think we are probably
doing it about the same way, but I am just accessing the information
just a little differently. I like accessing the information of the top
level pins this way --
cellView~>net~>terminal because there could be more than one pin
associated with the terminal. I then access the pins on the instances
below from cellView~>net~>instTerm because there could be multiple
instTerms, and multiple instPins associated with each instTerm
(although I can't get instPin directly). I haven't really thought in
depth, but maybe the way that you access it, you too can get all that
information, our programs probably do about the same thing, just in a
little different way.

By the way, the diagram is also found in the back of the "Cadence
SKILL Functions Quick Reference" if you have access to one, it is the
very last page.
 
vlsidesign wrote:
On Feb 6, 12:54 am, Suresh Jeevanandam <sure...@DELETETHISti.com
wrote:
vlsidesign wrote:

snip

In the "CellView Information Model", for instance on page 185 of
dfhelp.pdf document (Cadence Design Framework II User Guide), you
should see the instPin.
I think we are using different versions. I do not have that page itself.

I am looking at the pdf file, Version 5, Sept 2003

I am working in VirtuosoXL, and have these top level Terminals/Pins
that are associated to a net. I am trying to access the instPin (lower
level pins -- pins in the instances) that is associated with the net.
The idea for my script was that I could have hundreds of top level
pins in my layouts, and then automate some of the pin placements
(rather than zooming in manually selecting a pin, zooming out, and
then zooming in and placing it, etc.).
I also had to do something similar, I used to first find the pin name by
instTerm->name, then search for this pin in inst~>master~>terminals, and
once terminal is found, find the pin by term~>pins and access the figId
of the pin, and then map this figId to toplevel with dbTransform* functions.

I would have to check my code but basically I think we are probably
doing it about the same way, but I am just accessing the information
just a little differently. I like accessing the information of the top
level pins this way --
cellView~>net~>terminal because there could be more than one pin
associated with the terminal. I then access the pins on the instances
below from cellView~>net~>instTerm because there could be multiple
instTerms, and multiple instPins associated with each instTerm
(although I can't get instPin directly). I haven't really thought in
depth, but maybe the way that you access it, you too can get all that
information, our programs probably do about the same thing, just in a
little different way.

By the way, the diagram is also found in the back of the "Cadence
SKILL Functions Quick Reference" if you have access to one, it is the
very last page.
I found it. instTerm~>instPins returns nil for me too.

-
Suresh
 

Welcome to EDABoard.com

Sponsor

Back
Top