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
Presentations at the Electronic Design Process Symposium (EDPS) April 18, 2013 gave a realistic look at the promises and limitations of electronic system level (ESL) design. Speakers noted that ESL tools are used for the lower levels of the software stack, but typically not for applications development. There is no magic tool that will fully automate hardware/software partitioning. Even so, ESL technology can be of tremendous value if properly used.
Now in its 20th year, EDPS is a small but influential IEEE workshop that brings together movers and shakers in the electronic design methodology community. Cadence was a gold sponsor this year. ESL presenters and panelists were as follows, as shown left to right in the photo below. Gary Smith, chief analyst at Gary Smith EDA, moderated the panel that followed the presentations.
EDPS keynote speaker Ivo Bolsens, CTO of Xilinx, was not officially part of the ESL session - but his keynote was a great lead-in to it. Bolsens talked about the "all programmable SoC" and pointed to the Xilinx Zynq-7000 Extensible Processing Platform, noting that it has programmable logic, I/Os, DSPs, and CPUs. This platform, he said, provides "different levels of programmability so you can tailor the platform to the embedded apps you are targeting." He also talked about the Xilinx Vivado high-level synthesis tool and its role in hardware/software development. Bolsens' presentation slides are available here.
Is Hardware Driving Co-Development?
Frank Schirrmeister's talk was titled Embedded HW/SW Co-Development, It May Be Driven by the Hardware Stupid! "The interesting question is how relevant the hardware is to different pieces of software on the stack," he noted. His answer: software development has a strong hardware dependency at the driver, OS, and middleware layers, but not at the applications layer. Thus, hardware/software co-development takes place at the lower levels where the hardware dependency is strong.
With over 2 million apps in the apps stores, he noted, there is a huge number of software developers in the world. But these developers aren't using ESL tools and aren't generally aware of the underlying hardware. This is particularly true with HTML5, where software development requires only an OS simulator.
"We need to realize that a lot of software can be developed without hardware knowledge," Schirrmeister said. "Hardware/software co-development remains at the lower level - drivers, OS, middleware. No reason for despair - there are a significant number of users in that domain. Just be aware they aren't the Angry Birds developers."
Schirrmeister, who manages the Cadence System Development Suite, also talked about the importance of choosing the right hardware/software co-development platform for the task. He reviewed the advantages and limitations of virtual platforms, acceleration/emulation, RTL simulation, and FPGA-based prototyping (summarized in the chart below).
Guy Bois gave a detailed presentation about Space Codesign and its Space Studio ESL tool, which currently works with FPGAs and provides input for the Xilinx Vivado tool. Space Studio provides algorithm development, architecture design, function mapping and partitioning, performance analysis and evaluation, and co-synthesis of hardware and software.
More Abstraction Needed
Gregory Wright said he found the contents of the opening talks (Bolsens, Schirrmeister, Bois) "very scary." Why? "From the standpoint of trying to build these systems and cost pressures we're under, I'm worried. I'm fully supportive of moving towards software-driven implementation schemes. But I'm worried about addressing an increasingly narrow portion of the available pool of programmers." Many programmers these days, he noted, are not using C/C++, but that's what ESL tools target.
Wright said that "we love the Zynq, we're building products on it." But the SRAM is hard to use, and "we're not getting stuff out the door faster." What's needed, he said, is a higher level of abstraction on the hardware side, so we can get to an environment where software people are comfortable putting together the hardware blocks.
Michael McNamara introduced Adapt-IP, a new company that provides system-level design tools and techniques for deploying and configuring semiconductor IP. For each standard protocol or accelerator, the company provides a soft RTL model, firmware, a device driver, and a virtual platform model. IP is customized for the requirements of a particular project.
Gene Matter discussed the need for power and thermal modeling and simulation, and noted that the greatest potential savings are at the electronic system level. It's important to couple the thermal model and the power model with actual workloads, he said, and co-simulate with a high-level model. "We need a higher level of abstraction to start with, but you need to drive it all the way down and track the level of implementation," he said.
Presentation slides for the talks described above are available at the EDPS web site.
Panel Questions and Answers
An hour-long panel session following the presentations allowed audience members to closely question the presenters. Here are a few of the comments I found interesting.
Schirrmeister - With EDA in its current form, with the current engines, there is no way to address [applications] software developers. An HTML5 apps developer for Angry Birds just needs an OS simulator for that. EDA is still needed for the hardware underneath.
Audience member - HTML5 is not a panacea. It can't interact with a GPS, accelerometer, or hardware components needed to power a game. A lot of people are saying incorrectly that HTML5 will solve all our problems.
Question - Why is hardware/software partitioning still hidden behind a black box? Can we automate it?
McNamara - You need to have a domain expert in whatever area you're going into. They know from experience where the bottlenecks are and what system configuration is needed.
Gary Smith - There are two places where hardware/software partitioning happens. That's because we have yet to give the architect the power information he needs to make his decisions. So the SoC guy makes his own decisions, and that really throws off the architect. The architects I talk to say they'll spend a quarter of a million dollars on a set of tools if you can get me that information.
Ivo Bolsens (from audience) - I don't believe there is an ultimate tool that takes software and figures out where the boundaries between hardware and software should lay. But the big challenge for combining hardware and software is in the plumbing that's involved - it's a communications question. That's where the tools come in.
Matter - Another thing about hardware and software -- just because you have a performance enhanced system doesn't mean its energy enhanced. I've seen a lot of designs where they use techniques that are abhorrent for low power operation. Polling is death!
Schirrmeister- There are different ways of making hardware available early for software developers. The lower you get in the software stack the more hardware you need to see. Markets where [hardware/software co-development] is most applicable are mobile and consumer markets - anything loud, that makes pretty pictures, or is colorful.
Very nice explanation Electronic System Level (ESL) Design.this is really use ful to engeneering students.
Just to add to your information on Space Codesign, Richard, SpaceStudio** includes automated support for hardware/software partitioning in architectural exploration, where functions can be retargeted for hardware (as a co-processor or accelerator) or software implementation (as a software task running on a processor, which includes an OS or at least bare metal) using the same C/C++/SystemC model without recoding.
We're not at the point of having 'black box' hardware/software partitioning that rolls out an optimal allocation of hardware and software targets, the technology for automating the partitioning in a white box manual co-design approach (developed in research at Ecole Polytechnique de Montreal, where Guy Bois also serves as professor) is an important step towards that goal.
** n.b., the name of the electronics design software is SpaceStudio, no blank space between the two words! :)