Stats

  • Locked Locked
  • Replies 4
  • Subscribers 143
  • Views 14525
  • 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

Strange ddCreateLib() behaviour

ThomasThoe

Hi,

I have a question regarding ddCreatelib(). I want to automate a recurring workflow, where I get a new digital design in the form of a verilog file and a .gds and need to import the new version into a newly created library into schematics and layout files. For this, I want to use skill to create the library, attach it to the techfile and then continue on with ihdl and strmin to do the rest.

I am using Virtuoso 6.1.8 and get the following strange behaviour:

in ciw:

ddCreateLib("test" "./libs")

then in the shell:

ls -al libs/

I get:

drwxr-s---  2 user grp 4.0K Jul 15 12:37 .
drwxr-s--- 18 tuser grp 8.0K Jul 15 12:38 ..
-rw-r-----  1 user grp   67 Jul 15 12:34 .oalib
-rw-r-----  1 user grp 1.4K Jul 15 12:34 cdsinfo.tag

and in cds.lib:

DEFINE test ./libs

------------

This is not what I expected. I of course don't want my libs folder to be defined as a library and called TEST. I want the library to be created in the folder libs.

As a workaround, this works:

ddCreateLib("test" "./libs/test")

But this seems to not correspond to the documentation, where it states that t_libpath is the directory where the lib is created.

Does anybody have pointers on where I am doing something wrong ?

Thanks,

Thomas

Parents
  • Andrew Beckett

    Hi Thomas,

    This is not strange. If you read the text of the ddCreateLib documentation, it's clear that the directory specified is (in general) the path to the library directory itself, not the containing directory:

    If the library does not exist, ddCreateLib creates the corresponding directory and adds the DEFINE command to the library list file (it uses ddUpdateLibList’s search to find the cds.lib file and, if that file is not in the current working directory, it creates a new cds.lib file in the current working directory and adds the DEFINE statement to it as well as a SOFTINCLUDE statement to include the file found by ddUpdateLibList’s search). Finally, if successful, it returns the ID of the new library.

    If you do not include t_libPath, DDPI uses the current working directory and libName to make a path (cwd/libName). If you specify a leaf name (one without embedded separators), DDPI makes a path out of that name and the current working directory (cwd/libPath). If you specify “.” or “..”, DDPI does the same as for NULL.

    The cdsinfo.tag file keeps track of which design management system is managing a library. This file resides in the library directory. It contains one string, which is the name of the design management system.

    ddCreateLib calls back trigger functions registered on the triggers PreCreateLib and PostCreateLib. The PostCreateObj trigger is not called when a library is created with ddCreateLib.

    Regards,

    Andrew.

Reply
  • Andrew Beckett

    Hi Thomas,

    This is not strange. If you read the text of the ddCreateLib documentation, it's clear that the directory specified is (in general) the path to the library directory itself, not the containing directory:

    If the library does not exist, ddCreateLib creates the corresponding directory and adds the DEFINE command to the library list file (it uses ddUpdateLibList’s search to find the cds.lib file and, if that file is not in the current working directory, it creates a new cds.lib file in the current working directory and adds the DEFINE statement to it as well as a SOFTINCLUDE statement to include the file found by ddUpdateLibList’s search). Finally, if successful, it returns the ID of the new library.

    If you do not include t_libPath, DDPI uses the current working directory and libName to make a path (cwd/libName). If you specify a leaf name (one without embedded separators), DDPI makes a path out of that name and the current working directory (cwd/libPath). If you specify “.” or “..”, DDPI does the same as for NULL.

    The cdsinfo.tag file keeps track of which design management system is managing a library. This file resides in the library directory. It contains one string, which is the name of the design management system.

    ddCreateLib calls back trigger functions registered on the triggers PreCreateLib and PostCreateLib. The PostCreateObj trigger is not called when a library is created with ddCreateLib.

    Regards,

    Andrew.

Children
  • ThomasThoe
    in reply to Andrew Beckett

    Hm, ok. It is not clear to me yet, to be honest., sorry Slight smile This is what the documentation also states:

    t_libPath

    Absolute or relative directory name where the library is created. A relative path is interpreted relative to the current directory. If t_libPath is omitted, nil, or an empty string (" "), the library is created in the current working directory.

    Doesn't that say, it means the path where the library is created ? And if it is empty, so " ", then it creates it in the local directory ? It surely would create cwd/libname and not make my working dir a library ?

    I think I might be missing something obvious after my debugging session, maybe I need coffee. But I found this:

    https://support.cadence.com/apex/ArticleAttachmentPortal?id=a1Od0000000nXcmEAE&pageName=ArticleContent

    When I look at the code there, the second argument is set to: "/home/user/libraries" - and not "/home/user/libraries/myLib".

  • Andrew Beckett
    in reply to ThomasThoe

    I don't think that article is correct (from some quick experiments). If the full path is given to the working directory, then it is the same as no path being defined (or as if "." was specified) which is highlighted in the text that I mentioned.

    I'll speak to our documentation team - I certainly think there is scope for this to be improved, but in general the path is not the path where the library is created - it's the path where the library exists.

    Andrew.

  • ThomasThoe
    in reply to Andrew Beckett

    Thanks Andrew, I updated the linked code from that solution to append the library name to the path. This now works fine. Thinking about it, this also makes a lot of sense since otherwise I would not easily be able to have the library name be different from the directory name. It might be a good idea for the documentation team to add a small example for usage of this function at the bottom of the description, avoiding confused users like myself in the future!

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.