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.
Get email delivery of the Cadence blog featured here
Design teams have used C/C++/SystemC reference models for many years and the trend is growing with SystemC synthesis. At the same time, many teams are adding power-aware structures to their designs and trying to simulate. So what happens when the models encounter unknowns propagated from shutdown blocks?
For the unprepared, the simulation fails. In most cases. the models were written before low-power simulations were conceived. They do not take into account the fact that their inputs can go to X at any time during the simulation run (as opposed to just a short while after time 0). We have seen many C-models crash when one or more of the inputs goes to X (this simulates the driving block being shut-down). If you have this configuration in your chip, you must isolate all inputs going to the C-model before shutting down any driving blocks that are connected to the model’s inputs.Another thing to avoid is shutting down the C-model. You must put it in an always-on domain. The Incisive simulator (IES-XL) often does not have access to the internals of the model so it cannot properly handle the low-power operations that are necessary to power down the model. All power-down functions must be done natively in the model if you need it to work properly in shut-down.A third thing to look for is any driving or receiving net that is connected to the model. Proper drive/load analysis cannot be done when originating or terminating in the model. For instance, for all model inputs, the CPF command to specify isolation must be of the form:
create_isolation_rule -name xxx -from <driving_power_domain>...
When written in this form, only the driver must be located, not the receiver, so isolation will be placed properly. Likewise, for all model outputs that need to be isolated, use the following form:
create_isolation_rule -name xxx -to <receiving_power_domain>...
This will remove the need to find drivers inside of the model.Finally, we are introducing a new capability that will allow users to have a SystemC module in their Verilog or VHDL testbench and still use the automatically generated low-power assertions. If you have a need for this capability, contact us at genIES@cadence.com today for an early look.