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.
Can anyone offer insight into how to enable individual users to customize their environments when working in multiple projects, each project having multiple users, and each project having its own setup files?
Is there a specific PATH order that setup files will be loaded in, such that person A can maintain their own setup files that will be loaded before the group/project setup files, and independent of person B's personal setup files so that there are no collisions?
Or if not, is this something that could be coded into the setup files, to look for personal setup files on startup, and append them to the group/project setup file content?
Probably worth reading the Cadence Application Infrastructure Guide, particularly the sections which talk about the Cadence Search File mechanism (also referred to as setup.loc) and the csfLookupConfig file. It depends to some extent which file you're talking about, but this manual covers most of it.
I will add a small note to what Andrew has mentioned above. You tagged your post with ".cdsenv" and ".cdsinit" so I will comment on these files. By default the search mechanism for these files does not follow the CSF - the "caiuser" document that Andrew mentions tells you how to create a csfLookupConfig file to include these files in the CSF lookup mechanism. You can set the CDS_LOAD_ENV environment variable to control how the .cdsenv files are found and loaded, and this can have the value "CSF" which would have the same effect, but this would not alter how .cdsinit files are found.
Hopefully the documentation covers what you need to know.
In reply to Andrew Beckett:
I will read up on that section.
This is related to a previous Post - "Open Layout View to spec'd Configuration" -
I am trying to support multiple users with different monitor configurations (and preferences of course) to personalize their desktops without colliding with multiple, existing project setup files....which are mostly default as far as window configurations, but otherwise distinct from project to project.
I can modify any given project's setup files for window layout to suit one user, but not more than one user. I am referring to the CIW, LSW, Lib Mgr and Layout viewer when I say window layout. For example, I can define the default Layout window size and location in the .cdsenv file, but that is a project-specific file. I can define the CIW size and location in the .cdsinit, but that is also a project-specific file.
In reply to jaleco:
thank you for the added info. I will definitely read up what I can find on this.
Thank you both once again.
I am using a project-specific csfLookupConfig file, which has the following statements in it:
I added INCLUDE statements for personal files -
The $HOME/.cdsenv appears to get loaded, as it defines the size and location of the newly opened layout views using a leWindowBBox() setting, and this seems to work.
However, the $HOME/.cdsinit file does NOT appear to be loaded, and this file defines the CIW with a hiResizeWindow() statement, and it is not taking effect.
You did say the csfLookupConfig file would not work for the .cdsinit file, but I am confused how the project setup is successfully using it?
That's not the way that the csfLookupConfig works. It controls whether a type of file is found using the CSF mechanism or not, and doesn't tell it locations where to find/read a file.
So if you have:
INCLUDE .cdsenvINCLUDE .cdsinit
it tells it that both of these files will look in the setup.loc locations for each file - that is not the default behaviour for these files (for historical reasons, because both files pre-date the CSF mechanism being introduced).
With .cdsenv, it will load all the files that it finds in setup.loc locations, with the top-most entry in the setup.loc winning over the lower level entries - so that the first is the most-specific.
With the .cdsinit, it loads the first file found only. If you want to load the others, you'd need to carry on the search yourself for other locations to load from, but you can encode that in some central .cdsinit yourself to have the logic where to look.
Got it, thanks Andrew, it is all working now.
Thank you so much for the clarification.
There's a cdsenv to control the LSW placement (this is for IC5141, I assume, since LSW is replaced by the Layer Palette now) for Layout XL:
layoutXL lswWindow string "((0 0) (0 0))"
If my memory is correct, users can also set the size using an Xdefault:
I've not tried this in a very long time though...