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.
As part of EDA360 Cadence is learning how to play a more significant role in the SoC-to-System handoff. To date, Cadence has served the SoC market by enabling companies to design and verify faster, bigger, and better SoC devices that get used by their customers in systems. For a long time we have been hearing that a system is more than just a chip, and for a chip to be successful in the market a large amount of embedded software is required.
Lately, we have seen an uptick in the number of SoC companies interested in using Virtual Platforms to develop software before silicon or even RTL is available. Generally, they want to get a jump start on software development, improve software quality, and tune the architecture based on hw/sw interaction. It seems clear that a significant portion of the deliverable created by an SoC company is software.
At DAC this year I also sensed a change in the way engineers are talking about Virtual Platforms. Much of the past struggle related to the Missing Model Syndrome and the lack of resources companies were willing to commit to Virtual Platform creation has slowly been melting away and users are more interested in taking control of the situation and controlling their own destiny.
Another positive trend is seeing engineers touting the benefits of using Virtual Platforms such as the recent article co-authored by Everett Lumpkin. When I see an article co-authored by a user and a vendor I'm suspicious that the vendor does all the writing and the user just puts his name on it to add some credibility, but not this time. Check out Everett's LinkedIn profile.
Even with all of these positive developments, it's my opinion that the majority of the world is not using any kind of simulation for doing embedded software development. As an example, the talk at DAC 2010 by Iqbal Arshad was one of the most insightful talks that I can remember into the current state of embedded software and system design.
My first thoughts after watching the talk were related to the deliverables between the SoC company and Motorola during the Droid development. I could guess that the SoC provider may have provided many things to enable the system design and secure the design win. Certainly, a running operating system and device drivers was a required part of the delivery, but what about simulation?
Some possible deliverables might be:
In order for Virtual Platforms to become universal they must overcome the current status quo. I have 2 daughters that are homeschool debaters. Every year they debate a resolution that involves a proposed change to the status quo. For the 2010-11 year the resolution will be
Resolved: That the United States Federal Government should significantly reform its policy toward Russia.
You can already keep up with the latest Russia news at Blue Book Report. In Team Policy debate the affirmative team must present a plan and convince the judge that the plan is worthwhile and compelling enough to change the status quo.
Today, the status quo for the SoC-to-System handoff is a hardware board running an operating system with drivers and sample apps. In the case of the Droid example it could have been Zoom.
In a typical reference design everything is open source, from the hardware details to many different software projects that run on the hardware. By default, the hardware reference design serves as the starting point for system design. By adding more hardware peripherals, adding more drivers, and taking care of all the important details of the super thin package, antenna design, power management, sensors, manufacturing details, etc. the reference design can be transformed into a commercial product like the Droid. From the DAC talk I gathered that this transformation involved a lot of blood, sweat, and tears and my hat goes off to the entire team that made the Droid a reality; it's a very impressive accomplishment. I could also infer that the last mile was difficult. Issues with performance and power are difficult to track down and I'm sure the Law of Leaky Abstractions came into play. The various abstractions from the hardware all the way to the apps are great until something goes wrong, then Motorola engineers must unravel the stack to find the leak.
Taking a software stack that mostly works but has some hidden inefficiencies related to performance or power in a device driver can be difficult to find and fix. Iqbal explained that all of the device drivers that probably looked fine on the reference platform had to be rewritten.
Some bullets directly from the presentation (slide 31):
The presentation is a wonderful industry contribution to provide details on what it takes for any Virtual Platform approach to convince system companies to change the status quo.