Parent child database on Open Access

Hi,

Does someone have a clue how to access the
parent child database on Open Access?

On CDBA there was a simple way to get the information
if a specific cell was placed in one or more libraries,
just grep the pc.db file of your cell views

e.g.
grep 'searched_cell' */*/*/pc.db

the result was than something like that
CELL/schematic/pc.db:searched_lib searched_cell symbol

Is there a way to get this kind of information for OA also,
the pc.db file or any equivalent does not exist in OA.

Thanks Bernd

 

Hi Bernd,

That's precisely why pc.db contents are undocumented!

In OA, the parent-child information is part of the main database - whereas in
CDBA it was separated to allow tools which need to access this kind of
hierarchy information to access it without having to load the whole database.

Since in OA you don't have to load everything from a cellView at once (that's
my understanding), there's not really much need to have it separate any more.

If you're using the documented SKILL pcdb API, for example:

pcId=pcdbOpen("master" "mux2" "schematic "r")
genId=pcdbGetInstMasterGen(pcId)
imId=pcdbNextInstMaster(genId)
pcdbInstMasterCell(imId) => "Inv"

Then it works fine in both CDBA and OA.

That's why APIs are good, direct data access is bad.

Regards,

Andrew.

 

Hi Andrew,

I don't share your opinion.
If you just want to know in which
cell views in a set of libraries you have
placed a specific cell as instance,
then you do a simple UNIX grep on the cell views pc.db files
in your libraries directory.

With the SKILL API you have to use nested foreach loops
to access the parent child database for all cell views of
your libraries.
If I have to use foreach loops, then I don't see the sense in
specific pcdb functions.
I can also get this kind of information I want by scanning
every cell view in all my libraries for a specific instance master.

That is pretty uncomfortable, isn't it?

Also the pcdb function are documented very spare in cdsdoc
I still don't get it to work the way I want.

Bernd

 

Hi Bernd,

Well, it may have been convenient, but was undocumented, and just as well, as
it works differently in OA. OA is designed by the Open Access consortium, not
Cadence alone.

So, you could always become a member of the OA consortium and campaign for
them to add this to the OA database. I think that's very unlikely to happen
though!

If it's not part of the database, we can't really add it, can we? In CDBA,
pc.db was part of the database, effectively.

I don't understand your argument that foreach loops mean that specific pcdb
functions make no sense.

APIs are always a good thing - they hide implementation details, so that
things can be changed underneath without affecting applications.

I've also used the ccpExpand API in the past for collecting this kind of
information. Here's some code to illustrate that:

/* abNewLibraryRefs.il

Author A.D.Beckett
Group Custom IC (UK), Cadence Design Systems Ltd.
Language SKILL
Date Jan 12, 1999
Modified Feb 19, 2003
By A.D.Beckett

Uses the new ccpExpand facilities to expand library data,
either using the pc.db files (parent child databases),
or using config files to find all the cellViews or libraries
used. This is quicker than opening databases, and also supports
configurations.

Each of the four functions can be used externally.

***************************************************

SCCS Info: @(#) abNewLibraryRefs.il 02/19/03.09:56:33 1.2

*/

/****************************************************************
* *
* (abNewCellViewRefs libName cellName viewName @optional *
* (expandMode 'CCP_EXPAND_COMANAGED)) *
* *
* Expand the specified cellView, returning a list of lists of *
* cellView information. The expandMode is the keyword to pass *
* to ccpExpand.* functions to say what files to include. The *
* default should be adequate for most cases. The expansion will *
* follow through the complete design hierarchy, into other *
* libraries, since it uses the pc.db and config information. *
* *
****************************************************************/

(procedure (abNewCellViewRefs libName cellName viewName @optional
(expandMode 'CCP_EXPAND_COMANAGED))
(let (spec expanded cellViews cellViewInfo obj)
(setq obj (ddGetObj libName cellName viewName))
(setq spec (gdmCreateSpecFromDDID obj))
(setq expanded
(cond
((ddGetObj libName cellName viewName "pc.db")
(ccpExpandDesign spec expandMode))
((ddGetObj libName cellName viewName "expand.cfg")
(ccpExpandConfig spec expandMode))
(t
(setq specList (gdmCreateSpecList))
(gdmAddSpecToSpecList spec specList)
(ccpExpand specList expandMode))
))
(gdmResetSpecList expanded)
(while (setq spec (gdmNextFromSpecList expanded))
(when (and
(setq cellViewInfo (gdmInspectSpec spec "LibraryUnix"))
(equal (cadddr cellViewInfo) "master.tag"))
(rplacd (cddr cellViewInfo) nil)
(setq cellViews (cons cellViewInfo cellViews))
)
)
cellViews
))

/**********************************************************************
* *
* (abNewLibraryRefs libName @optional sorted) *
* *
* Get all cellViews in a library, invoke abNewCellViewRefs on them, *
* and then collate the information into a list of lists. The *
* optional argument is a flag to indicate that the information should *
* be sorted. *
* *
**********************************************************************/

(procedure (abNewLibraryRefs libName @optional sorted)
(let (libObj cellViews cellViewTable)
(unless
(setq libObj (ddGetObj libName))
(error "Could not open library %s\n" libName)
)
/* create a table - easy way of removing duplicates */
(setq cellViewTable (makeTable 'cellViewTable))
/* visit all cells */
(foreach cell (getq libObj cells)
/* visit all cellViews */
(foreach view (getq cell views)
/* get all the references, even through other libs */
(setq cellViews
(abNewCellViewRefs
libName (getq cell name) (getq view name)))
/* record any cellViews used in the table */
(foreach cellView cellViews
(setarray cellViewTable cellView t))
))
/* pull out everything from the table */
(setq cellViews nil)
(foreach cellView cellViewTable
(setq cellViews (cons cellView cellViews)))
/* if sorted has been supplied and set to non-nil, sort the
list before returning it */
(when sorted
(setq cellViews
(sort cellViews
/* comparison function - sorts strings in lists */
(lambda (a b)
(while (and
(car a) (car b)
(equal (car a) (car b)))
(setq a (cdr a))
(setq b (cdr b)))
(and (car a) (car b)
(alphalessp (car a) (car b)))
))
))
cellViews
))

/*************************************************************************
* *
* (abNewLibrariesUsed libName) *
* *
* Process the library, expand the design hierarchies and configurations, *
* and find out all the libraries referenced, directly or indirectly. *
* *
*************************************************************************/

(procedure (abNewLibrariesUsed libName)
(let (libs)
(foreach cellView (abNewLibraryRefs libName)
(unless (member (car cellView) libs)
(setq libs (cons (car cellView) libs))))
libs
))

/****************************************************************************
* *
* (abNewLibrariesUsedByCellView libName cellName viewName) *
* *
* Process the cellView, expanding the hierarchy, and find out all libraries *
* referenced, directly or indirectly. *
* *
****************************************************************************/

(procedure (abNewLibrariesUsedByCellView libName cellName viewName)
(let (libs)
(foreach cellView (abNewCellViewRefs libName cellName viewName)
(unless (member (car cellView) libs)
(setq libs (cons (car cellView) libs))))
libs
))

Regards,

Andrew.

 

We are bringing structural verilog code into dfII with ncvlog -use5x
which creates view with a relative symbolic link (verilog.v) to the
verilog code. The verilog code that the link points to could change at
any time so we are concerned about this static pc.db getting out of
sync with the verilog code. That is, the pc.db might not represent the
hierarchy of the verilog code over time. Is it true to say that this
concern will totally go away in OA?

 

I don't think OA affects this. The views created with use5x are not CDBA views
or OA views - they are verilog textual views. They happen to have pc.db files
created for the benefit of the hierarchy editor and other tools that need to
extract the hierarchy information. In this case the pc.db is a DFII thing,
rather than a CDBA thing. Yes, it is part of CDBA, but it can be used in
non-CDBA views too.

Regards,

Andrew.