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
The move to electronic system level (ESL) technologies such as virtual prototyping is well underway - but what's the impact on the engineering organization? A recent panel discussion and an industry note published by analyst Gary Smith both suggested that new engineering roles are evolving, and several Cadence people who regularly work with customers agree.
I already wrote about the DesignCon panel discussion on the "designer of the future," so a very brief summary will suffice here. Panelists talked about who will be responsible for hardware/software partitioning. One suggested that experts in system target applications will do this task, while others spoke of engineers whose expertise spans both hardware and software. On the panel, Gary Smith suggested that a "new level" of designer is appearing below system architects and is focusing on high-level modeling as a "new area of engineering."
In a free Industry Note titled "ESL Behavioral Design," Smith expanded this concept further. He noted that there are relatively few system architects, but he observed that large companies are "putting a team of ESL designers as close to the system architect as possible, even physically close. Their job is to do the modeling of the proposed system and extensive what-if analysis to come up with the optimal design." It would be a mistake to call these people "software" developers, he said - what they're doing is modeling.
Smith also identified three types of virtual prototypes. The Architect's Workbench is used before hardware/software partitioning. After partitioning, the Silicon Virtual Prototype is used to optimize hardware, while the Software Virtual Prototype is used for early software development. Then design implementation proceeds with RTL code for the hardware and C/C++ for embedded software.
As noted in a recent EDA360 Insider blog post, this Industry Note is consistent with System Realization as described in the EDA360 vision.
View From the Field
So what's actually going on in the customer base? I asked Jason Andrews, architect (and blogger) at Cadence, whether he's seeing a new class of behavioral ESL designer. "Yes, there are new engineers emerging who work in C++ , who are not classic architects," he said. "They are also not C coders for embedded software or RTL coders for hardware."
Andrews likes the way Smith categorizes virtual prototypes. Many companies, Andrews noted, want to model hardware using SystemC to make sure it will meet performance and power requirements. But there's confusion about the different types of virtual prototypes and their requirements. Sometimes, he said, "we visit customers thinking they're going to talk about the software virtual prototype and they start talking about the silicon virtual prototype."
There's at least one thing that software and silicon virtual prototypes have in common. "Generally every company must form a new group with a focus on these tasks," Andrews said. "The ones doing ESL in a serious way have formed special groups for the silicon virtual prototype and software virtual prototype." Meanwhile, there is a "tremendous opportunity" for designers to step into the role of virtual prototype creator for either hardware or software. "Anybody with good programming skills and system understanding can jumpstart their career by moving into the virtual prototype area," Andrews said.
Across the Pond
A European perspective comes from Markus Winterholer, R&D engineer at Cadence Germany. A recent DATE panel on embedded software debugging, he noted, included a call for a new type of engineer "somewhat between a computer scientist and an EE." Winterholer noted, however, that a whole team of experts is needed to design complex systems. What's needed is a way to formalize and share the information that "used to be in the head of one architect." This leads to a tool that could be called the "Architect's Workbench" that provides the metadata and requirements of the system.
After partitioning, Winterholer noted, a TLM model (or Silicon Virtual Prototype) is used for architectural exploration, and ideally synthesized to RTL. Software Virtual Prototypes are used for early software development. "What is really new is that we have a continuous flow, and tool support starts earlier than it used to," he said.
Steve Brown, product marketing director at Cadence, observed that some early SystemC adopters have evolved an "ESL engineer" role. Sometimes this is for virtual prototypes, and sometimes this is for high-level synthesis, depending on which is adopted first. "Often these engineers are tasked out to different project teams from a central management structure," Brown said. "The primary motivators for the centralized function are to evolve the methodology and reuse IP from previous projects."
The next step is developing a stable methodology. "There are several gaps that must be filled, so right now companies are working on making their central team larger, and enabling more projects to adopt the new approaches," Brown said.
A new methodology, along with new tools, will be needed for System Realization - which is defined as the creation of complex hardware/software systems ready for applications deployment. It is only natural to expect that engineering organizations will change, and new roles will evolve. Just as the boundaries between "hardware" and "software" will grow fuzzier, the wall between "hardware engineers" and "software developers" will erode.
Engineers in the future will need both hardware and software knowledge and skills. Some will need system-level modeling skills. For those just starting out in their careers, or those who want to advance, it's a great opportunity.
Unlike virtual modeling as we think of it today, with SystemC TLM 2.0, teams are able to do more exploration. That was the noble goal of VHDL with its one entity, multiple architecture configuration and user defined signal types for abstraction of connectivity. But it didn't inherently have the ability to move logic into the channel description like TLM 2.0 has.
Does TLM 2 really allow for a lot more exploration if we are mostly implementing with predetermined buses?
That's right ... a new engineering class is step by step borning ... a mixed of a SW guy with HW and System sensibility ... I just hope its real value will be correctly considered and ... unfortunately ... I see the organization evolution trip still so long probably normal if we consider it is done step by step ;-)...