• Skip to main content
  • Skip to search
  • Skip to footer
Cadence Home
  • This search text may be transcribed, used, stored, or accessed by our third-party service providers per our Cookie Policy and Privacy Policy.

  1. Community Forums
  2. Custom IC SKILL
  3. Understanding list returned by geGetHierMemInst

Stats

  • Locked Locked
  • Replies 6
  • Subscribers 149
  • Views 15012
  • Members are here 0
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Understanding list returned by geGetHierMemInst

PatrikOsgnach
PatrikOsgnach over 9 years ago

Hello,

I am working on a task which involves keeping track of the history of descents into a hierarchy, but now I am a bit puzzled by the behaviour of geGetHierMemInst.

As an example, let's begin at the top cell. As expected, if I call geGetHierMemInst((getCurrentWindow)) I get nil.

The top cell has an instance named "A". If I descend into it and call (getCurrentWindow)~>cellView~>instances~>name I get all the names of instances contained in the cellView of instance "A", which is what I expect. Also, (caar geGetHierMemInst((getCurrentWindow)))~>name returns "A", as expected.

Now, what I find odd is that, if I call (caar geGetHierMemInst((getCurrentWindow)))~>cellView~>instances~>name I get a result that, not only is different from what (getCurrentWindow)~>cellView~>instances~>name returns, but it is equal to the names of all instances contained in the top cell.

What am I missing?

To be more clear about what I need to do, let's assume that I am at level 3 of this hierarchy A->"B"->"C" (A is a top cell and "B" and "C" are instance names down the hierarchy). If I select a wire in instance "C" that is connected to a pin, I want to know how this pin is connected at the level of instance "B". To do this at level "C", I use geGetHierMemInst to get to "B" and I look at all instances contained in "B" until I find an instance named "C". The I explore how wires are connected to the symbol of "C" contained in the cell view of instance "B"

Thank you.

Patrik

  • Cancel
Parents
  • Andrew Beckett
    Andrew Beckett over 9 years ago

    Hi Patrik,

    This is not surprising. If you call getCurrentWindow()~>cellView, this is the same as what geGetWindowCellView() returns - i.e. the cellView id of what is in the current window (not the top cellView, that would be geGetTopLevelCellView()) - these functions all take an optional window id, BTW.

    If you call caar(geGetHierMemInst(hiGetCurrentWindow())) then this is going to return the instance id of the instance you've descended into. If you then retrieve the ~>cellView attribute, it will get the cellView in which that instance is placed - not the cellView of the view you've switched into. Since the instance is placed in the top level, caar(geGetHierMemInst(hiGetCurrentWindow()))~>cellView will return the top level cellView Id. You could use the ~>master instead but this would tell you the cellView ID of the symbol (if it's a schematic hierarchy). You'd have to use some kind of view-switching approach to find the master cellView, or easier would just be to use the ~>cellView attribute of the next instance in the hierarchical chain (or if at the leaf, use geGetWindowCellView() or geGetEditCellView()). That way you don't have to worry about view switching (and it would work if you had a config or had switched down via some non-default route).

    Put another way - looking at a particular entry in the list returned will tell you about the instance. To find out the view you've switched into after that you need to look at the ~>cellView attribute of the subsequent instance in the list to see what that's contained within. If there are no further instances in the hierarchical chain, then it's the current cellView you want.

    Hope that's clear (ish!)

    Regards,

    Andrew

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
Reply
  • Andrew Beckett
    Andrew Beckett over 9 years ago

    Hi Patrik,

    This is not surprising. If you call getCurrentWindow()~>cellView, this is the same as what geGetWindowCellView() returns - i.e. the cellView id of what is in the current window (not the top cellView, that would be geGetTopLevelCellView()) - these functions all take an optional window id, BTW.

    If you call caar(geGetHierMemInst(hiGetCurrentWindow())) then this is going to return the instance id of the instance you've descended into. If you then retrieve the ~>cellView attribute, it will get the cellView in which that instance is placed - not the cellView of the view you've switched into. Since the instance is placed in the top level, caar(geGetHierMemInst(hiGetCurrentWindow()))~>cellView will return the top level cellView Id. You could use the ~>master instead but this would tell you the cellView ID of the symbol (if it's a schematic hierarchy). You'd have to use some kind of view-switching approach to find the master cellView, or easier would just be to use the ~>cellView attribute of the next instance in the hierarchical chain (or if at the leaf, use geGetWindowCellView() or geGetEditCellView()). That way you don't have to worry about view switching (and it would work if you had a config or had switched down via some non-default route).

    Put another way - looking at a particular entry in the list returned will tell you about the instance. To find out the view you've switched into after that you need to look at the ~>cellView attribute of the subsequent instance in the list to see what that's contained within. If there are no further instances in the hierarchical chain, then it's the current cellView you want.

    Hope that's clear (ish!)

    Regards,

    Andrew

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
Children
No Data

Community Guidelines

The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.

© 2025 Cadence Design Systems, Inc. All Rights Reserved.

  • Terms of Use
  • Privacy
  • Cookie Policy
  • US Trademarks
  • Do Not Sell or Share My Personal Information