getting resolved path for a library definition

Discussion in 'Cadence' started by Rajeswaran M, Jul 10, 2006.

  1. Rajeswaran M

    Rajeswaran M Guest

    Is it possible to get the resolved path for a library definition present
    in a cds.lib which is not in the standard search path? Any standard
    skill or standalone libmanager utility.
     
    Rajeswaran M, Jul 10, 2006
    #1
  2. t_currentCdsLib = ddGetForcedLib( ) ;; getting the current cds.lib plus path

    ddSetForcedLib( t_newCdsLib ) ;; setting the desired one
    ddGetUpdatedLib( ) ;; maybe you have to do an update

    t_yourPathToLib = ddGetObj( t_yourLibName )~>readPath

    ddSetForcedLib( t_currentCdsLib ) ;; and setting back the old one
    ddGetUpdatedLib( )


    Bernd
     
    Bernd Fischer, Jul 10, 2006
    #2
  3. Rajeswaran M

    Rajeswaran M Guest

    Thanks Bernd. Looks like, need to use update/refresh library.
     
    Rajeswaran M, Jul 10, 2006
    #3
  4. Rajeswaran M

    John Gianni Guest

    As a(n?) hopefully helpful aside ... in addition to the library-path
    help provided by our good friend Bernd ... I've found there are still
    engineers who are not yet aware of the DFII 'cdsLibDebug' executable
    (created from my enhancement PCR 356393 filed 01-31-2001 influenced by
    the nice "nchelp -cdslib /path/to/your/cds.lib" use model).

    To see how cdsLibDebug helps you debug library paths, try this 1-minute
    test::
    % cd /path/to/where/you/normally/start/icfb
    % cdsLibDebug -cla

    Notice this tools/bin/cdsLibDebug command fully interprets the cds.lib
    file, even if that cds.lib file utilizes many other files, variables,
    and include options. The main intent is to provide the user with a
    clear picture of what libraries are available BEFORE the DFII software
    is invoked. As such, it can be incorporated into startup scripts if
    desired.

    As always, hope users find this hint useful,
    John Gianni
     
    John Gianni, Jul 14, 2006
    #4
  5. Rajeswaran M

    John Gianni Guest

    % cd /path/to/where/you/normally/start/icfb
    While we're on the topic of resolving library paths & variablees ...
    notice that the IC-5.0.33 and higher cdsLibDebug use model "properly"
    interprets the special-case $CDS_INST_DIR to find the root of the
    Cadence hierarchy based on the application invoked (and not on the
    value of a shell-environment variable, whether or not it exists).

    It may be interesting to note these other ways to check libraries:
    GRAPHICALLY:
    % cdsLibEditor
    Then, invoke "cdsLibEditor:View->Full Path"

    NON-GRAPHICALLY:
    % cat > checkPaths.il <<EOF
    foreach(lib ddGetLibList() printf("%-10s %s\n" (lib~>name)
    (lib~>readPath))) t
    EOF

    % dbAccess -load checkPaths.il

    Note: Of course, while $CDS_INST_DIR is well defined in any one
    software hierarchy, using CDS_INST_DIR as a shell-environment variable
    should be highly discouraged in multi-stream environments (i.e., almost
    all environments nowadays).

    Also note the recommended "cdsLibDebug -cla" option causes cdsLibDebug
    to obey CLA semantics instead of the default DDPI semantics. DDPI does
    its own parsing of cds.lib and there are some differences in behavior
    from CLA. (For example, DDPI does not understand ASSIGN statements,
    while both "nchelp" and "cdsLibDebug -cla" do understand ASSIGN
    statements in a cds.lib file.)

    For the overly curious, ddpi syntax output is something like that of
    running the public SKILL command ddUpdateLibList followed by
    ddDumpLibList.

    As always, hope this helps others,
    John Gianni
     
    John Gianni, Jul 14, 2006
    #5
Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.