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
In honor of
Halloween, here are some horror stories about low power bugs. These are
real bugs at real customers that would have led to real dead chips.
#1: It was a dark and stormy night… Ok, it was around lunch
time. But a customer had just spent three weeks coding a UPF file to
describe isolation between two power down domains. The customer’s
synthesis tool required that the UPF only implement either from isolation (from
a power domain) or to isolation (to a power domain), not both. So in
order to prevent redundant isolation between separate domains enabled by the
same power net, he had to specify specific nets between the domains, and
specify them as no_isolation. Only, and here’s the scary bit, he had made
a mistake, and had incorrectly identified a couple of pins that really went to
always on logic. So, when the block was powered off, the always on logic
would get nuked. *Shudder* Fortunately, one of my guys got static
checks operational in an hour or so (shameless plug – Conformal Low
Power). The static checks structurally proved that isolation was missing
between the power off block and the always on logic. The dead chip was
#2: The door creaked slowly open, revealing… Ok, he was in a
cubicle. But a customer was doing power shutoff on a processor based
design. The power controller was essentially a register bank. The
real time OS would get an interrupt from the power down timer, and would
execute the power down routine. The routine would hit the bit enabling
isolation, and would then hit the bit disabling power to the power down block.
All well and good, and pretty routine. The design was operational, and
had passed all the static checks – everything was perfectly isolated and looked
fine. But there was terror lurking – the processor’s secondary cache was
in the power down block. The processor could execute the code to turn the
power off, but would never get another instruction – ever! *Shiver*
Fortunately, one of my guys got low power simulations operational with a high
performance low power simulator (shameless plug – Incisive Design Team Simulator).
Since there wasn’t a significant overhead to the simulation, they ran a lot
more test cases. As a result, they caught the issue and moved the cache
to an always on block. The processor lived to execute another day.
#3: There was a sound, and he turned around slowly to see the maniac
raise his… Ok, it was his boss (hey, that is scary!) But a customer
had defined the power intent for a big chip, and had proven the netlist and
power intent was correct. This was a big device, requiring feedthroughs
across a power off domain. His implementation tool, however, didn’t
understand the power intent. So it didn’t understand the always on cells,
and so didn’t understand that they needed to be powered by special routes connected
to an always on supply. As a result, the feedthrough buffers in a power
down domain were powered like all the other cells in that domain – by a
switchable supply. *Eeeek* Fortunately, one of my guys got physical
netlist checks operational. These checks check that the always on power
pins specified in the LEF are actually powered by always on power rails
(shameless plug – Conformal Low Power). The always on nets remained
always on, and the chip made it.
So are you terrified
yet? As Count Floyd said on SCTV, “pretty scary, huh kids?” Again,
these are real stories – nothing made up here. My point with these
stories is not to scare you, but instead to point out the need for a complete
verification strategy that includes both static and dynamic checks, and to
continue to run these checks throughout the flow. There are some nasty
things that can happen when you do low power design, and these can quickly lead
to some very dead chips. I don’t know about you, but I find the thought
of that much scarier than goblins and monsters and kids in Sarah Palin masks.
Oh, and… BOO!