instance based viewNameList setting

Sorry.  Let me clarify my request. 

A certain cell has two views -- schematic and hspview. In schematic view there is an instance I4.  In hspview (for some reason) there is a different instance I5.  By default when I probe through this instance (I3) using

geAddInstProbe(cw() list("y0" "drawing") "/I1/I2/I3/I4")

instance probing works fine.  But when I try

geAddInstProbe(cw() list("y0" "drawing") "/I1/I2/I3/I5")

I get warning instance I5 does not exist, because DF2 chose the schematic path which has I4 but not I5.  If I override this by changing the viewNameList then this last probe works BUT the former one does NOT!

What is an intelligent way about this?

Thanks again

Fuad

Hi Fuad,

The probe does not drive the hierarchy expansion, it is the other way around. By the way, you can set up a Hierarchy Configuration (new 'config' view which opens the Hierarchy Editor) so that some paths descend one way while others can use a different expansion rule to expand another way, then if you open the "configured schematic" it will follow the config for how to expand the hierarchy. This still does not necessarily address the question that you posed; you would have to explore the hierarchy to determine which instances/paths were present before attempting to create a probe, but again the probe will not 'drive' the hierarchy expansion, that's already been determined by the config (or the viewNameList).

Hopefully this helps a little?

Regards,

Lawrence.

Hi Lawrence.

Nice to meet you in person!  I am relatively new to this community but I have seen many of your responses from before and I appreciate your replies all along the years!

Ironically just before I put the post I learned through a colleague about the Hierarchy Editor which I've never used before so I will be looking at that.  Thanks for the lead.  I did want to follow up with you about a couple of comments you mention.  First "you would have to explore the hierarchy to determine which instances/paths were present before attempting to create a probe". The instances and paths I am using are based on a SPICE netlist of the top schematics; so they are there and correct in so far as including right instance names and instances within.

The other comment "... hierarchy expansion, that's already been determined by the config (or the viewNameList))".  I have not tried the config yet, but my understanding is that the viewNameList is a global setup and not instance-based, unless I am mistaken; and hence the issue.

I do want to correct one intention of mine in above problem statement in that cell (X) of concern (with two view names) is instantiated TWICE and at the same level.  In one case the cell employes a schematic view; in the other it  employes an hspview.  The views, unfortunately have different instance names and architectures within themselves. When probing both instances of X at same time I run into this issue.  

Thanks again,

Fuad

Fuad,

There are two mechanisms for determining the hierarchy expansion as Lawrence mentioned - a global view name list (which you've found) which is used for non-configured schematics - and a config view set in the hierarchy editor. The configuration allows you to specify a global default view list, and then a per-cell, per-instance or per-occurrence view to use or view list. The "view to use" explicitly picks the view to use for that cell, instance or occurrence, and the inherited view list allows you to override the global view list (i.e. the preference order for which view to pick) for the hierarchy downwards from that cell, instance, or occurrence.

A bit of terminology - cell bindings means that this controls what is used each time that cell is used (unless overridden by an instance or occurrence binding). Instance bindings are to determine what is used for an instance within the containing cell, and an occurrence binding is for a specific hierarchical path (this means that Itop/Ileft/I1 can be bound to one thing and Itop/Iright/I1 can be bound to something else even though Ileft and iright are instances of the same cell).

The benefit of the hierarchy editor is that it means that the decisions about how the hierarchy is expanded is in a view separate from the schematics - so you can have multiple configurations expanding the views in different ways. You can even have hierarchical configs where the view to use for a cell/instance/occurrence is another config view controlling that portion of the hierarchy.

A very long time ago (last in the 9502 release, also known as 4.3.4) there used to be instance-based view switching which was controlled by properties on the instances. However, that was problematic because every time you wanted to change the expansion you needed to edit the schematic, plus it of course didn't allow for occurrence-based bindings. So for the last 27 years (since the 4.4 release in 1996) we have had this controlled by the config view created by the hierarchy editor. This is extremely widely used and is precisely what you want - you can achieve your needs. When you open the config view, you can open the associated schematic (the banner indicates it's under the control of the config) and any probing will follow the hierarchy expansion rules defined in the config.

Andrew

Hi Andrew:

seems like the hierarchy editor is the path to go.  A couple of questions on that.  What Cadence manuals deal and explain the details of the hierarchy editor; and most importantly can it be driven by skill commands (as opposed to GUI).  If yes, what skill functions are available (or manual describing them).

Thanks again

Fuad

Hi Fuad,

Just a quick (incomplete) response, Yes, the hierarchy can be controlled/driven through SKILL, the commands have the "hdb" prefix  but this will not be trivial, you'll need to know the correct sequence in which to set/change things.  Andrew probably has a code example or two but I do not - most people interact with the HED to control the configs.

Best regards,

Lawrence.

You could have found the Hierarchy Editor manual pretty easily - in any Virtuoso Help menu, in the box at the top, type "Hierarchy Editor".

If you want the PDFs, they are here:

• <ICinstDir>/doc/cdshiereditor/cdshiereditor.pdf
• <ICinstDir>/doc/skdfref/skdfref.pdf (chapter on Hierarchical Design Functions).

I'd start with using the UI to familiarise yourself with the functionality first, then you can use SKILL to create the views if needed (you'd use hdbOpen, the hdbSet* functions (in particular hdbSetObjBindRule) and then hdbSave and hdbClose.\

Andrew

Hi Andrew (and Lawrence):

This is fabulous.  Thank you much for providing the hint I needed to get this and similar problems resolved.  I was able to write some simple skill code to set instance view names at will and now instance probing works perfectly.  For the record here is my prototype:

config=hdbOpen(***);; place where to save config file
hdbSetTopCellViewName(***);; top level cell where to start from
hdbSetDefaultViewListString(***);; default lib and cell views
hdbSetDefaultLibListString(***)
hdbSetDefaultStopListString(***)
hdbSetObjBindRule(***);; now tell it this particular cell will have instance I1 using one view while instance I2 (with same master) uses another view
hdbSave(***);; save and close
hdbClose(***)

One can check one's work by looking at expand.cfg file and one can check the GUI tree for sanity.  Either GUI or hdb commands will do though latter is much easier to automate.

Till next time!

Regards,

Fuad