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
Not long ago embedded software engineers worked in isolation, with no standards, no common platforms, nothing reusable for future projects, and no collaboration with any other company. A collaborative ecosystem is starting to break through that isolation and greatly improve software productivity - and it needs your support, according to panelists at the recent ARM TechCon conference.
The panel was titled "The Future of Collaborative Embedded SW Development, From the Viewpoint of One Technology Chain Gang." No, nobody is breaking up rocks under the watchful eye of a deputy sheriff. The term "technology chain gang" comes from the realization that modern embedded software development requires components from a "technology chain" of collaborating companies, including processor, platform, operating system (OS), semiconductor intellectual property (IP), and tool providers.
As shown from left to right in the photo below, the panel included these participants:
Following are some excerpts from the panel discussion.
Q: Where is the ecosystem today for embedded software development?
Lapides: I think the community is sort of just getting by, just getting chips and boards and systems into the market and praying they will work. I don't see a software development and test methodology keeping pace with the way hardware is evolving.
Mitchell: I think in recent years we've made some progress, particularly in the ARM environment with embedded Linux. We still have some challenges ahead of us. I think standards in interfaces are super important, but we also don't want to forget about opportunities to differentiate.
Ready: When semiconductor guys try to differentiate their products through hardware, you get a natural proliferation of interfaces and a customization of Linux. That's so the vendors can go to market. The structure of the industry does lead to a lot of chaos and churn, and a lot of duplicated effort in the supply chain.
Goodacre: We're at a stage now where few companies are making money selling just software. Most software experts are in the hardware companies. There is no longer value in just creating software - the value is what you can do with it.
Q: Jim, does Cadence provide tools that will help with software development?
Ready: Cadence is primarily an EDA company. My job is to understand whether there is an opportunity for an EDA company to help with software. I think the single biggest thing we can do is to provide a place where the software guys can execute software before there's a chip, and execute on the best possible model of the SoC [system on chip] under development, such as an RTL model of the processor.
The problem is that trying to do that with Android is an enormous challenge. It's a huge amount of software and it takes a long time to execute, even in emulation. There's a lot of effort on bridging that gap.
Mitchell: It's really important to enable the software team early on with something that keeps them productive. It's also critical to come out with the highest quality software.
Q: John, what is your view of embedded software and the collaborative ecosystem?
Goodacre: I group software into three aspects. First, you have enablement software, which is non-differentiating software you need to get something going. Companies need to work together across the ecosystem to do that, and Linaro is a great example. Another class of the software is the tooling, including APIs and EDA. A third class is the software that enables the value proposition of the device. That's differentiating software you really want to focus on, but it really isn't valuable apart from the device.
Q: Is Google, with Android, part of a collaborative ecosystem for embedded applications?
Ready: Google defines what Android is. Any particular revision of Android may be targeted at some reference SoC, which leaves everybody else having to move up to that particular revision. If you have an SoC with a subsystem that does some neat things, perhaps some imaging, there may or may not be an interface in Android or a hardware abstraction. What you end up doing is ripping out a software subsystem, if there is one, and redesigning.
Q: How will QEMU and OpenCL impact embedded software development?
Lapides: QEMU has had a significant impact -- it has already been part of Android development kits. The problem with QEMU is that it is open source, unsupported, has GPL licensing, and is not a complete model of an ARM processor.
Mitchell: We think there is a strong benefit for QEMU - if you develop something in Android you can get down there and touch simulators. The challenge is that it's difficult to support a changeable platform, such as an SoC FPGA. That's where we see OpenCL coming in.
Goodacre: OpenCL is an assembler language for saying "I don't really care when you do it, but please do these things as fast as you can." But you have to say "I've got 256 of them" if you have 256 lanes in your architecture. To really take off like C code did, OpenCL is going to have to be more micro-architecturally abstract.
Q: How are we going to get to a better collaborative environment in the future?
Lapides: The high cost of silicon respins forced a significant collaboration between tool vendors, IP vendors, and customers. The software industry is different because there is no one big cost. But costs are adding up to the point where something has got to be done.
Mitchell: Things are actually getting better. Embedded software used to be all mine, all closed, and everything we're doing is to launch a single product. Now we're opening up a bit and trying to follow the PC model where there was a much more collaborative environment and a standard platform.
Ready: The best way to make software engineers more productive is to have them not write software in the first place. That's what happened with Linux in embedded systems - it was 50 million lines of source code you didn't have to write. Collaboration on common things, as brought forth via open source, is the source of productivity in software engineering.
Goodacre: We're not where we were 20 years ago. We're not just building one device that does one set of platform functions - we want to have devices all over the place. To do that we need to have a collaborative effort for enablement software. It's not differentiating and you're not going to make any money on it. So everybody has got to help with the platform. To use it effectively, please pay for the tools.
Related Blog Post:
Software-Driven SoC Development - The Next Big Step in IC Design?