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
My last few blog posts have included three corner-case conditions that led to bugs, one in software, one in hardware,
and one in real life. One of the reasons that corner-case conditions are missed
is that some engineers don't spend enough time really thinking about their
design and documenting its intended functionality. Writing specifications that
are orthogonal to the specific hardware or software implementation provides
deeper insight and often reveals difficult-to-verify conditions even before
they are implemented.
In the hardware world, assertions
are a popular and very valuable form of orthogonal specification of design
intent. When used diligently, they provide the basis for thorough verification
with testbench simulation, formal analysis and hardware acceleration. But, as
with any form of specification, just the act of writing assertions can reveal
inconsistencies, poorly-conceived design ideas and potential trouble spots for
verification. I recall an instructive example from my stint leading the
applications engineering team at 0-In Design Automation.
0-In's primary product space was
formal analysis, but we also supported assertions in simulation. As an
assertion-based verification (ABV) pioneer, our success on customer projects
was tied directly to the quality of their assertions. When the customer, with
help from my applications team, did a good job of specifying assertions, we
could find some really tricky corner-case bugs. But in this particular case, we
found a whole category of interesting bugs just by working with the customer to
I can't identify the company, but I
will say that it was a major networking/communications provider designing chips
quite large for the time. The engineers believed strongly in design
reuse, and regularly mixed and matched pieces from previous designs into the
RTL for their new projects. They often found a lot of bugs related to the
integration of these pieces because the original designers did not consider
future reuse and did not document their blocks with either written
specifications or assertions.
As my applications team started
working with this customer, they learned about the history of problems related
to design reuse. They decided to focus on helping the customer's engineers
write assertions to document the interfaces of the reused blocks. The
expectation was that simulation would reveal inconsistencies between the
assumptions made by connected blocks and that formal analysis would reveal
further bugs that didn't happen to be triggered in simulation. In fact, assertions
provided value even before the first simulation was run because they revealed a
lot of misunderstanding about what the interfaces were supposed to do.
The biggest issue I recall from the
customer project is disagreement over how request-acknowledge (req-ack)
interfaces should work. This is perhaps surprising; it's hard to imagine an
interface protocol simpler than a req-ack handshake. The block on one side
makes a request, the block on the other side acknowledges it, the first block
drops its request when it has been satisfied (for example, read data received)
and the second block drops its acknowledge. So what's not to understand? Well,
consider these questions:
I could go on in this vein for quite
a while; there are probably dozens of variations on the basic req-ack handshake.
In the case of this particular customer project, we found a total of seven
(!) req-ack variants being used just in the portion of the chip we were analyzing.
That was a sure sign of trouble, but even worse the engineers really didn't
understand the rules for the blocks they were reusing. Most of the req-ack
interfaces were between two blocks with different protocol assumptions and therefore buggy. The
process of trying to document these interfaces with assertions revealed many
problems that were fixed immediately; the customer later found additional bugs
with both simulation and formal.
This project, a fairly early one at
0-In, convinced me that ABV had intrinsic value. Writing assertions caused the
designers to think about their assumptions in a much more rigorous way. Going
into this project, we had no idea that something as "simple" as a req-ack
handshake had corner cases. So when I say "verify, verify and verify some more"
be sure to consider assertion specification as an essential part of the process
and not just a precursor to simulation and formal.
The truth is out there...sometimes
it's in a blog.
Nice Example Tom.
One of the greatest values of Assertions is that it helps designers to uncover bugs which have been existing in their proprietary IPs for some time. As these IPs start getting integrated with new designs, this aspect becomes a key selling point for Assertion Based verification since over the years the conventional verification techniques have not uncovered them.
-- Anu Bohra