Get all other cells used in a given cell

Several ways of getting what is in the design. Not sure if you want a list of everything hierarchically - but a couple of approaches (at least) have been posted before, in this post and this other post.

There are quote detailed manuals which cover the database objects. If you run cdnshelp (if using IC6.1.X) or cdsdoc (if using IC5141), or use the Help menus from within the tools, there's a manual called the Virtuoso Design Environment SKILL Reference which has a chapter on Database Access. This lists the API, but also has a description of each object type and the associated attributes.

You can also start from a database object and do objId~>? to list the available attribute names, and objId~>?? to get the attribute names and values. So you can look up many things on the fly. You should also be aware of the cdsFinder UNIX command (which can also be launched by typing startFinder() in the CIW) which is a quick reference guide (each function is documented in greater depth in cdnshelp/cdsdoc).

Regards,

Andrew.

Thanks!  This was definitely helpful to me.  However, I'm still having some issues.

The recursion in principle is not really a problem, what I'm struggling with is to do this for just one level.  The goal at this point is given a cell with a schematic, get all the other cells that have schematics and whose symbols appear in the original schematic (i.e., if there's no schematic, then skip it)  Here's what I've figured out so far:

getCurrentWindow()->cellView returns an object of a type that corresponds to a cellview (call it CellViewType1 for now).  CellViewType1 has many useful properties, including "instanceMasters", which gets all the cell views referenced in the schematic (which are also of CellViewType1), "cell", which gets an object corresponding to the cell, and "cellViewType", which is useful for seeing if it is a schematic or symbol.

If I can start with an object of type CellViewType1, and get a list of objects of type CellViewType1, then it would seem that I could now do recursion--but there's one catch.  The new list of objects correspond to the symbol views, not the schematic views, so the instanceMasters property won't work.

Now the task becomes, given an object of type CellViewType1, to do the following:
1.  Figure out if there's a schematic for the cell above this cell view
2.  If so, get the CellViewType1 object that corresponds to that schematic

If I can do that, then I can move recursively.

However, if I start with a CellViewType1 object, and use the properties ->cell and ->views like so:
mycvt1obj->cell->views
then I do get a list of cellViews that are its siblings--but the type is different!  I call this CellViewType2, and it does not have the "instanceMasters" or "cellViewType" properties, so I can't figure out if any of them are a schematic or move recursively.

I also tried experimenting with ddGetObj to see what it returns, thinking that this could get me back to CellViewType1, but it actually gives me CellViewType2.

Here's what the ->?? looks like for the two types:

CellViewType1--
(db:0x0f73d012 cellView db:0x0f73d012 objType "cellView" prop (db:0x0f73d492 db:0x0f73d49a db:0x0f73d499 db:0x0f73d496 db:0x0f73d495 db:0x0f73d494 db:0x0f73d493) bBox ((-1.25 -0.3125) (1.8 0.6)) lib dd:0x109d4688 libName "CooperTestLib" cellName "BusCellInst" cell dd:0x10a01884 cellViewType "schematic" cellType "none" conns (db:0x0f73ec92 db:0x0f73ec95 db:0x0f73ec96) DBUPerUU 160.0 fileName "/home/cclauson/CooperTestLib/BusCellInst/schematic/sch.oa" createTime "Jan 28 16:00:41 2012" fileTimeStamp "Jan 28 16:01:26 2012" groupMembers nil groups nil instHeaders (db:0x0f73ed12 db:0x0f73ed13) instHeaderRefs nil instRefs nil instanceMasters (db:0x0f73ea12 db:0x0f73d292) instances (db:0x0f73d792 db:0x0f73d793) isParamCell nil layerHeaders (db:0x0f73ce92 db:0x0f73ce93 db:0x0f73ce94 db:0x0f73ce95) layerPurposePairs (db:0x0f73e992 db:0x0f73e993 db:0x0f73e994 db:0x0f73e995 db:0x0f73e996 db:0x0f73e997 db:0x0f73e998) lpps (db:0x0f73e992 db:0x0f73e993 db:0x0f73e994 db:0x0f73e995 db:0x0f73e996 db:0x0f73e997 db:0x0f73e998) memInsts ((db:0x0f73d792 0) (db:0x0f73d793 0)) mode "a" modifiedButNotSaved nil modifiedCounter 90 mosaics nil markers nil trackPatterns nil rowHeaders nil rows nil nets (db:0x0f73ce16 db:0x0f73ce17) shapes (db:0x0f73d612 db:0x0f73d613 db:0x0f73d614 db:0x0f73d615 db:0x0f73d616) signals (db:0x0f73ce16) sigNames ("gnd!") subMasters nil superMaster nil terminals nil userUnits "inch" viewName "schematic" view dd:0x10a0184c textDisplays nil assocTextDisplays nil needRefresh nil netCount 2 anyInstCount 2 termCount 0 clusters nil prBoundary nil snapBoundary nil viaHeaders nil viaMasters nil routes nil steiners nil blockages nil vias nil guides nil sitePattern nil areaBoundaries nil figGroups nil gCellPatterns nil)

CellViewType2--
(type ddViewType name "schematic" lastModify "Feb  6 14:11:24 2012" owner "cclauson" ownerAccess "rwx" group 100 groupAccess "rx" publicAccess "rx" isReadable t isWritable t prop (db:0x0f73ca12) lib dd:0x109d4688 cell dd:0x10a01884 files (dd:0x10a021ac dd:0x10a021ec dd:0x10a019a4))

Thanks in advance for any help.

Working from the "dd" objects is not going to help you particularly because it does not give you any indication of the hierarchy - that information is contained within the "db" objects (such as the "cellView" objType object you're dealing with above. There are three alternative ways you could traverse the design:

cvId=geGetEditCellView() ; gets the cellView in the current window using the proper API rather than using properties on the window
; look at every instance
foreach(instance cvId~>instances
  ...
  master=instance~>master
  ...
)

; look once at each master
foreach(master cvId~>instanceMasters
  ...
)

; look once at head instHeader
foreach(instHeader cv~>instHeaders
  master=instHeader~>master
  ...
)

The benefit of instances is that every single instance gets visited - which is useful if you need to do some kind of flattening type operation, or collect other instance-specific information. But if you only want to find out the cells that are instantiated, it's rather more expensive because you end up visiting every instance of the same cell over and over again. The other two approaches avoid that. The instanceMasters approach directly gives you the "master" (i.e. the thing that has been instantiated, typically the symbol in the case of a schematic), whereas the instHeaders gives you a database object which has access to both the master and the list of instances of that type. Take your pick.

What you are looking to do is some kind of view switching. So for example:

foreach(master cvId~>instanceMasters
  switchedMaster=dbOpenCellViewByType(master~>libName master~>cellName list("schematic" "cmos.sch"))
  when(switchedMaster
    printf("Found %s has view %s\n" master~>cellName switchedMaster~>viewName)
    ; do whatever you want
    ; might want to close it to ensure reference counts handled properly
    dbClose(switchedMaster)
  )
)

Notice that the dbOpenCellViewByType has a list of view names to try - this is analogous to a "switch view list" when netlisting, and allows you to specify a priority.

Note there is a mechanism to do this when you have a config - that's a bit more complicated - and you might want to take a look at Solution 11300048 for a more complete example (that handles either view switching or configs).

Regards,

Andrew.

Okay, I think I got this worked out.  Here's the solution I ended up using:

 procedure(getSchematicDBsInSchematicDBs(cvId)
    prog( (
        ;;local variables
        retlist
        newcvId
    )
    retlist = nil ;;initialize return list to empty list
    foreach(master cvId->instanceMasters ;;iterate through symbol cellviews referenced in this schematic
        ;;try to find a schematic cellview for this symbol cellview,
        ;;will return nil if none can be found (and, unfortunately, issue a warning in the CIW!)
        newcvId = dbOpenCellViewByType(master~>libName master~>cellName list("schematic"))
        if(newcvId ;;if didn't return nil
            retlist = cons(newcvId retlist) ;;append to beginning of return list
        )
    ) ;;end foreach
    return(retlist)
    ) ;;end prog
)

The only downside of this is that it issues warnings in the CIW.  If there was some way to avoid that it would be nice, but this works reasonably for now.

 Thanks for the help!

Hi,

You might be able to avoid warnings by using a call to ddGetObj instead to test if the cellview exists - it should just return nil if it does not and should not create any warning messages.

Hope this helps.

Regards,

Lawrence.

Or just add a call getWarn() after the dbOpenCellViewByType() to swallow the last warning. Warnings have a one warning buffer (unless the warning is explicity flushed by the function). In this case the getWarn() should work fine. That would then only involve a trivial change to your code.

BTW, if the view is always called "schematic", you don't need to do list("schematic") - you can just use "schematic". The list is just a way of allowing more than one possible view name for it to sequentially search.

Regards,

Andrew.