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.
We are currently having a discussion, where we try to decide, what data we should manage.
For sure any primary data e.g hand-edited-schematics, or RTL code should be managed.
What do you do with generated data, e.g. a verilog netlist or an extraced cellview.
That generates dependencies between different views of the same object that one should track....
I am wondering, what the best approach is.
Does anyone have a suggestion or best practice advice?
Hi Nena,We had a similar discussion a while back. We decided to manage any Cadence view as a starting point. That way, we don't have to regenerate the view(s).We also do not include any check-in/check-out calls in our customizations. That has the draw back that the user is responsible to obtain write permissions to the cell view before he does something.It took takes some getting used to that, but it working out as far as I know.For any other generated data we let the users decide what they manage and not. Some of our projects do manage some generated netlists, some don't. I would be interested as well to hear what other's are doing.Regards,Britta
Here're my 2 cents.There's probably no right or wrong answer here. What you choose to DM depends a lot on your flow, and that's a function of how the tools in your flow behave. If your flow insists that netlists be generated every time right before they are used, DM the netlist might actually cause problems (think of AMS's netlists in cellviews and TMPDIR usage). On the other hand, not DM'ing netlists can leave you in a situation where the more recently generated netlists do not match an older version of schematic you just checked out, and if the tools in your flow just check for time stamp, you can very well be working on netlists which don't match your design.DM and archiving are related, but are really different. As our moderators said in their interviews, DM is so important for multi-site designs. If you look at DM as something that is active and current, versus archiving which is static, you will consider the management of secondary or generated files as important. The fact that you can generate these secondary files does not mean that your flow will always generate them as needed. Best regards,Teng-Kiat LeeProduct Engineering, Central Architecture and Technology
This post from firstname.lastname@example.org was inadvertenly deleted:Here're my 2 cents.There's probably no right or wrong answer here. What you choose to DMdepends a lot on your flow, and that's a function of how the tools inyour flow behave. If your flow insists that netlists be generated everytime right before they are used, DM the netlist might actually causeproblems (think of AMS's netlists in cellviews and TMPDIR usage). On theother hand, not DM'ing netlists can leave you in a situation where themore recently generated netlists do not match an older version ofschematic you just checked out, and if the tools in your flow just checkfor time stamp, you can very well be working on netlists which don'tmatch your design.DM and archiving are related, but are really different. As ourmoderators said in their interviews, DM is so! important for multi-sitedesigns. If you look at DM as something that is active and current,versus archiving which is static, you will consider the management ofsecondary or generated files as important. The fact that you cangenerate these secondary files does not mean that your flow will alwaysgenerate them as needed.Best regards,Teng-Kiat LeeProduct Engineering, Central Architecture and Technology
As disk has gotten less expensive, I have seen the trend to save more generated data. If the DM system in use can help ensure all the source data is aligned with the generated data, this can save a lot of time when unwinding changes to find the last time something worked.Chris Goldstein
I'd certainly agree with all of the above. But I wanted to add one more thought. I believe that when you talk about "the data", you have to consider what that really means. Things move so fast and process are more complex than ever. Where I see people spending effort is not just in getting a configuration of data, but rather in determining how they got to that state.You have to have a way to store both the data and some of the key driving knowledge, such as intent. Otherwise, you may never know why some changes were made, by whom and when. Sure, your circuit designer and layout designer can ping-pong changes back and forth, but it's the additional layer of knowledge that makes that collaboration more valuable. And that gets magnified over time (how long do you need to keep old designs around?) and complexity.Just something to think about.Rick