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.
In previous projects I used multi-mode analysis
and CTE report mode (SOC52). I generate best and worst
case parasitc files for STA and also MIN and MAX
delay files (SDF). I used the following commands:
rcOut -worst -spf file_name_worst.spf
delayCal -sdf file_name_worst.sdf
rcOut -best -spf file_name_best.spf
delayCal -sdf file_name_best.sdf
But now I'm using SOC62 and multi-mode
multi-corner analysis and the above commands does
not work anymore. To generate parasitic files I'm
rcOut -rc_corner WORST -spf file_name_worst.spf
rcOut -rc_corner BEST -spf file_name_worst.spf
It seems be ok. Is this the right way to get
parasitic files in MMMC?
And how to get min/max delay files (sdf) in MMMC?
Usign the command delayCal, the resulting delay cells are
quite the same between MIN and MAX sdf files (less than 15%). I think there is no effect on
delay calculation when switching between hold and
I tried use write_sdf but looking at the file
header, the process, voltage and temperature
values indicates that both sdf files are for
typical case (which is the default opCond).
Can anyone help me?
Another interesting point:
Using command "setDelayCalMode -feDc" the
resulting delay cells are very different from
before when I used signalStorm. Now there are
a lot of difference between MIN and MAX delay
cells in the generated sdf files.
Why this difference? What is the recommended delay
My felling is that when in signalStorm mode, delay
calculation considers the opCond set by command
setOpCond. As in my case I did not use this
command, delay calculation are considering the
default opCond (typical) and only switching
between worst and best wire parasitic information
in RC extracted database. What do you think about it?
I attached two reports of the same path (setup),
one using -signalStorm and other using -feDc.
In the 5.2 releases, SOCE was only multi-mode, so the delay and extraction subsystemsdid not change.In 6.1 and 6.1, SOCE is also multi-corner. In the releases, you shoulduse write_sdf -view xyz to dump the SDF file of interest. Delays aresubject to both the mode effect and the corner effect - so the controlis at the view level.If the SDF header info is not correct - get a PCR filed.. this is mostly cosmetic. If the valuesdo not change that is a real problem - assuming your delay corners are substantially different.