Cadence® system design and verification solutions, integrated under our System Development Suite, provide the simulation, acceleration, emulation, and management capabilities.
System Development Suite Related Products A-Z
Cadence® digital design and signoff solutions provide a fast path to design closure and better predictability, helping you meet your power, performance, and area (PPA) targets.
Full-Flow Digital Solution Related Products A-Z
Cadence® custom, analog, and RF design solutions can help you save time by automating many routine tasks, from block-level and mixed-signal simulation to routing and library characterization.
Overview Related Products A-Z
Driving efficiency and accuracy in advanced packaging, system planning, and multi-fabric interoperability, Cadence® package implementation products deliver the automation and accuracy.
Cadence® PCB design solutions enable shorter, more predictable design cycles with greater integration of component design and system-level simulation for a constraint-driven flow.
An open IP platform for you to customize your app-driven SoC design.
Comprehensive solutions and methodologies.
Helping you meet your broader business goals.
A global customer support infrastructure with around-the-clock help.
24/7 Support - Cadence Online Support
Locate the latest software updates, service request, technical documentation, solutions and more in your personalized environment.
Cadence offers various software services for download. This page describes our offerings, including the Allegro FREE Physical Viewer.
Get the most out of your investment in Cadence technologies through a wide range of training offerings.
This course combines our Allegro PCB Editor Basic Techniques, followed by Allegro PCB Editor Intermediate Techniques.
Virtuoso Analog Design Environment Verifier 16.7
Learn learn to perform requirements-driven analog verification using the Virtuoso ADE Verifier tool.
Exchange ideas, news, technical information, and best practices.
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.
It's not all about the technlogy. Here we exchange ideas on the Cadence Academic Network and other subjects of general interest.
Cadence is a leading provider of system design tools, software, IP, and services.
My enviornment uses the clio DM system. When I go to create a new library, Cadence asks for the cds.lib to checkout. A lot of times the managed file is locked and I cannot edit it. For this reason I create a non-managed "cds_custom.lib" that I include in my "cds.lib". If I specify a filename that is not "cds.lib" in the"Check out cds.lib" form that comes up, it fails to edit anything and I cannot create a library.
Is this a DM bug or Cadence bug?
If it is a Cadence bug, it seems trivial enough to change to allow any file name to be modified, as in my example a user may need to modify a referenced library file in the same path as the cds.lib.
I think the probelm is the way the environment was set up. The cds.lib should be for the user and not shared by the group. Usually the environment is set up so that the cds.lib sources another file that is managed. For example, the users cds.lib (unmanaged) sources a project_cds.lib (managed) that contains the libraries used for the project you are working in. If a library needs to be updated for the group then the project_cds.lib is edited and checked in and everyone is updated next time they start the tool.
In reply to TeeBro:
The problem with that methodology is a user must then know to create a cds.lib and then add "INCLUDE project_cds.lib"
In my methodoly, the average user just starts cadence in that path and everything just works. If they want to add custom libraries, the create custom.lib and "INCLUDE custom.lib" is already in the cds.lib.
In reply to acook:
Even in a non-design managed environment, when you add a new library, you don't have the choice to add the library definition into an included cds.lib-like file; it adds it into the cds.lib (or whatever file is "forced" with ddSetForcedLib, or via -cdslib on the command line - although I'd advise against doing this because there are almost certainly assumptions in some parts of the tool that the file is called cds.lib).
So I'm not quite sure why you decided on your methodology.
I'm pretty certain that many DM systems recommend that you do it the way that Thomas suggested. Having a quick scan through the SOS documentation, it doesn't seem to suggest that - mainly because they support managing the cds.lib. Historically though I've always done it by managing a project.lib type file - and then manually moving the library into the project.lib when you want it managed.
Usually there is a script that sets up a users directory structure including adding a template cds.lib file that already has the included "project" cds.lib definition. From there the user only has to add/create a custom library if needed. If the whole group needs the library it can then be added to the "project" cds.lib and checked in for everyone to checkout.
OK, thanks guys. I'll do something like:
test -f cds.lib && echo "cds.lib exists" || echo "INCLUDE project.lib" > cds.lib
Back to my original comment though, why only allow a "cds.lib" file to be appended in the create library form?
Because that's the way it is and has been for the last 16 years or so... there's never been enough demand to change it (as far as I know). By all means contact customer support and request that though...