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
EDN recently featured a lengthy article entitled "SOCs: IP
is the new abstraction. Reusable IP, not system-level language, has become the
new level of abstraction."
The point of view is that SoC design now is such a large
undertaking that the best way to efficiently design one is to assemble IP from
various sources into a platform, differentiate with software, and swap in
different IP for derivative designs that target different requirements.
It all makes sense. However, where it goes wrong is in saying
that SystemC has not delivered the next level of abstraction after RTL. This IP
re-use and assembly vision does not work very efficiently unless the IP is
developed in SystemC transaction-level modeling (TLM). Designing blocks in RTL would work in this vision,
but it would be very inefficient, blunting many of the benefits. This is why
many corporate design re-use initiatives have stalled, because of the
significant amount of overhead required to re-use RTL.
RTL by its nature ("register transfer level") contains a
significant amount of implementation-specific information. The RTL
micro-architecture for a block going into a performance-driven application will
need to be changed for a cost-driven application that needs the smallest area
possible. And different process nodes bring different capabilities as well as
challenges -- as you move to smaller nodes you get performance and size benefits
that you can tweak your micro-architecture to take advantage of, but you will
need to trade that off with power. Of course there are different libraries for
a given process technology -- high-performance, low-power, etc. -- that you can use
but which also require different RTL micro-architectures.
Designing in SystemC enables designers to focus on
describing the functionality of the algorithm, and high-level synthesis (HLS) automates
the process of generating RTL specific to a particular application's goals and
process library. The implementation-specific details are captured in the HLS
constraints, so your functional verification can focus only on the functionality.
And once the functionality is verified, you can re-target without re-running
functional verification at that level. This makes IP re-use, and especially
derivatives of that IP, much more efficient. It also reduces some of the
overhead stated in the article associated with learning the ins and outs of
And the system-level verification that needs to be performed
is not feasible with RTL IP because it is too detailed, slowing down simulation
performance and making debug tedious. It is mentioned that virtual prototypes
are required for simulating the system software, but often the RTL IP
functionality diverges from the virtual prototype. Again, these are things that
can be solved by moving to a SystemC transaction-level modeling (TLM) use model.
You can start out with high-level virtual prototypes and refine those toward a
hardware architecture that can be synthesized by HLS, all within SystemC TLM.
TLM is essentially a higher-level abstraction of a
particular communications interface. This is wrapped around the block's
computation core. This provides a level of modularity between different bus
architectures -- you can use the same computation core with different
communications wrappers. This solves many of the assembly issues cited in the
article where SoC teams are required to write RTL glue logic to connect all
this inflexible IP.
Finally, when it comes to implementation, if you utilize HLS
that's connected to implementation, you don't have to do a lot of the manual
power and clock optimization techniques at RTL because that can be modeled in
HLS. With the specific constraints passed automatically to RTL synthesis, the
rest of the flow goes smoothly.
It's this last part that has really held back broader
adoption of SystemC TLM for this purpose. If HLS can't produce something that
will predictably close on your performance, power, and area goals, then you end
up having to try to fix or re-write the RTL. But now with HLS tools like
C-to-Silicon Compiler, which is tightly linked with Cadence's RTL Compiler
synthesis, this problem is addressed.
this is not a case of whether the new abstraction level is IP or SystemC. Both
are, and for IP to work as an abstraction level, SystemC is required. What you
use to get your job done is largely a function of your role. If you're in an
SoC design group there will be a lot of IP assembly and perhaps some SystemC.
But if you're in an IP design group or company, then SystemC will make your
business much more efficient.