Home > Community > Forums > Custom IC Design > Keeping Library colors in Library Manager

Email

* Required Fields

Recipients email * (separate multiple addresses with commas)

Your name *

Your email *

Message *

Contact Us

* Required Fields
First Name *

Last Name *

Email *

Company / Institution *

Comments: *

 Keeping Library colors in Library Manager 

Last post Wed, Jan 2 2013 12:52 PM by Andrew Beckett. 5 replies.
Started by GoRangers 05 Sep 2012 03:14 PM. Topic has 5 replies and 1083 views
Page 1 of 1 (6 items)
Sort Posts:
  • Wed, Sep 5 2012 3:14 PM

    • GoRangers
    • Not Ranked
    • Joined on Mon, Aug 27 2012
    • Posts 8
    • Points 130
    Keeping Library colors in Library Manager Reply

    Hi,

    I noticed IC6.1's new feature to allow you to "ASSIGN libname DISPLAY colorname".   It works, but you have to hand-hack the cds.lib.

     But I'm coding some library utilities which utilize the ccp functions, and I want to retain the colors whenever I copy/rename a library.  All the ASSIGN statements get orphaned whenever I move libraries around via ccp.   How do I keep the ASSIGN statements in lockstep with my ccp operations?    Do I actually have to open the cds.lib file as an ASCII and sed/grep everything with a series of system calls from Skill??  

     Surely someone has hit this before?   When your ASSIGN statements all get orphaned, that's pretty bad.

    thanks

     

    Filed under:
    • Post Points: 20
  • Wed, Jan 2 2013 5:18 AM

    Re: Keeping Library colors in Library Manager Reply

    There's no SKILL API to manipulate the ASSIGN statements in cds.lib - you have to update the cds.lib (using SKILL I/O functions) yourself. If you would like a SKILL API to do this kind of manipulation, you'll need to file an enhancement request with customer support.

    Regards,

    Andrew.

    • Post Points: 20
  • Wed, Jan 2 2013 9:50 AM

    • GoRangers
    • Not Ranked
    • Joined on Mon, Aug 27 2012
    • Posts 8
    • Points 130
    Re: Keeping Library colors in Library Manager Reply

    No kidding.  I filed a bug (not an enhancement) and it got binned.  An API should not be necessary--if you delete a library, the ASSIGNs should go with it.  If you copy or rename a library, the ASSIGNs should go with it.  The Skill I/O functions work, but as far as I'm concerned that is a bug that it is not default Virtuoso behavior.   Cadence should not be orphaning ASSIGNs in a way that is clearly wrong. 

    • Post Points: 20
  • Wed, Jan 2 2013 10:59 AM

    Re: Keeping Library colors in Library Manager Reply
    What was the SR number? I'll take a look. I agree with you - it should be managed as part of copying/renaming the library.

    The SKILL API would be a useful enh too, but not so necessary if it did the right thing.

    Thanks,

    Andrew
    • Post Points: 20
  • Wed, Jan 2 2013 11:45 AM

    • GoRangers
    • Not Ranked
    • Joined on Mon, Aug 27 2012
    • Posts 8
    • Points 130
    Re: Keeping Library colors in Library Manager Reply

    SR
    Closed

    CCR
    Inactive

     

    • Post Points: 20
  • Wed, Jan 2 2013 12:52 PM

    Re: Keeping Library colors in Library Manager Reply

    OK, I checked. Your request has not been "binned". There has been some healthy debate about the request in the CCR, and it's agreed that there should be user control over which attributes get transferred to any new library. Some people might want some (or all) of the attributes copied, some might not. For example, if you've got an attribute indicating a reference library as readonly, and you take a (writable) copy of it, having it marked as readonly might not be appropriate any more.

    Also, it's perfectly reasonable to have attributes for a non-existent library in the cds.lib, so that when the library gets created, it gets those attributes.

    I'm not saying that these are necessarily what most people would want, just to illustrate that it's more complicated than it might seem from a first glance. It would also require changes to various APIs (not SKILL APIs, but the APIs used at a lower level in the tools) to allow better (selective) propagation of such attributes. So this needs careful architecting.

    Since it's impractical to plan any bug or enhancement request that comes in straightaway (unless it's a production-halting bug) - after all, we've already planned out the work for the next release - the normal process is for it to be backlogged (marked "Inactive") until the next planning phase - at which point it can be considered alongside all the other requests, and prioritized. If it doesn't make it for that planning phase, it can be considered at the next planning phase, and so on.

    So the CCR is awaiting consideration for implementation when we next do a planning session.

    Regards,

    Andrew.

    • Post Points: 5
Page 1 of 1 (6 items)
Sort Posts:
Started by GoRangers at 05 Sep 2012 03:14 PM. Topic has 5 replies.