The recent EDA360
vision paper describes System
Realization as the creation of integrated hardware/software platforms ready for
applications development. In this interview Michał Siwiński, group
director of front-end product management at Cadence, discusses key drivers,
required capabilities, and implications for System Realization.
Q: The EDA360 vision
paper talks about System Realization first, and then describes SoC Realization
and Silicon Realization. What is System Realization, and why do we need to move
A: EDA360 is a long-range vision for the future of
electronics design. The highest of the three elements of that vision - System
Realization - starts with the notion of application-driven, top-down
development. Given that today's electronics products are all about the
applications, as opposed to the underlying gadget's guts, a new approach to
design and automation is a must for end products to maximize the potential of
the apps, providing a better path to profitability.
Q: Why are
semiconductor companies becoming software providers? What problems are they
A: Most if not all semiconductor companies already provide
software, at least when it comes to bare-metal software such as drivers. In the
past the semiconductor vendors needed only to worry about the hardware, but
those days are over. With the system houses focusing on application
differentiation, there is a demand for the semiconductor companies to provide
application-ready platforms with hardware and software for a given vertical
Specifically, beyond the hardware, there is a growing push
for semiconductor companies to provide the lower levels of the software stack,
such as diagnostics, drivers, and perhaps even the operating system (OS) and
middleware. This in turn creates a
massive challenge. Traditionally disaggregated functions and cultures have to
come together for the semiconductor companies to be able to compete
effectively, and they must be aided by automation that enables a top-down
methodology connected to silicon.
Q: How can EDA
providers support software development and integration? Doesn't this require
A: The EDA industry has long been a partner for the
semiconductor industry, and some EDA providers have been funding research and
making investments in technology and people in order to provide system
development platforms. However, truly addressing
the problem will require collaboration and partnerships. It calls for a full
ecosystem comprised of EDA companies, embedded software and software
development enablement companies, IP providers, foundries, and enterprise
project management providers.
Q: People have been
talking about system-level design and ESL for years. What's different with the
EDA360 vision of System Realization?
A: There are several stark differences. The main one has to do with the top-down,
application-driven development model behind System Realization. Yes, the
industry has been talking about ESL for a while, but it was mostly in context
of an evolution of the current development process, without really making the
applications the primary driver. System Realization extends far into the future
and goes far beyond just raising abstraction levels. For example, we envision
systems in which software applications dynamically reconfigure hardware
resources on the fly, without depending on a CPU to prioritize resources.
Another key factor is a shift in where the lines get
drawn. System houses are now expecting
more software content from semiconductor providers as opposed to just the
hardware, and this demand has been intensified by the recent economic downturn.
The final difference for the EDA360 vision of System Realization is, well, us -
the end consumers. Our expectations on
what makes a good electronics product has shifted and the applications have
become the primary decision factor for many of us. This in turn has further
accelerated the need for addressing the System Realization challenge as
outlined in the EDA360 vision paper.
Q: What new tools or
capabilities are needed to support System Realization?
A: Five types of capabilities are needed. First, we need
early software development capabilities to get the application up and running
as soon as possible. Secondly, we need
application-driven system integration with system planning, what-if analysis,
and assembly of software and hardware components. A third requirement, application-driven
system verification, ensures the integrated system meets the product
Fourth, driver development kits will help automate the
custom hardware related development process.
Finally, application development SDKs [software development kits] will
abstract the details of the underlying hardware and software while preserving
knowledge of the basic functions required by different types of
applications. More about these five capabilities
is described in the EDA360 vision paper.
Moreover, to address System Realization these solutions need
to meet the following requirements -- be open and standards-based, be
integrated and connected, and provide high performance and reuse to enable an
efficient product development platform. While some initial steps have been
taken, these solutions will take time to develop and will require a
co-operative ecosystem of industry partners.
Q: How does virtual
prototyping technology need to improve to support System Realization?
A: In the vision paper we talked about the disaggregated
hardware-software development approach. One manifestation of that is the
fractured, unconnected set of solutions that have been attempted. Virtual prototyping today falls under that
category. The approach certainly has its benefits but it is not an end in
Moreover, to address System Realization two key elements are
needed. First, a connected design,
verification, and implementation flow from transaction-level modeling (TLM) all
the way down to the silicon is essential so that the higher level of
abstraction is not just another throw-away step. More importantly, the approach needs to be
driven top-down by the needs of the application as opposed to an abstraction of
the hardware. A lot more needs to be
done in this space.
Q: How does
verification need to change to support System Realization?
A: Given that over 60% of SoC development costs are related
to verification, and rising, a good set of metric-driven verification
capabilities with its formalisms have been developed on the hardware side. Extending this rigor across the software
boundary to assist the development of bare-metal software has already begun,
and going closer towards end applications is the next step. Such an extension will provide significant
benefits in ensuring more efficient hardware-software convergence for product
realization, with lots less recall risk or challenges in shipping offerings in
time for holiday shoppers to get them.
Q: What role do
analog/mixed signal design and board design play in System Realization?
A: Today, analog is still a separate component development
process, which gets integrated into the rest of the hardware at the tail end.
The notion of system development assumes that a chip is fundamentally a digital
chip. That's silly given the fact that such a large percentage of the chip is
Every SoC is a complex mixed-signal SoC. The same is true of
overall systems, so what can be done? We need to reconcile analog/mixed-signal
design with application-driven development up front. In the near future,
planning, modeling, and analysis tools will comprehend the totality of the end
product, including its analog and mixed-signal aspects. That will absolutely
have an impact in terms of faster convergence of devices, and an awareness of
the communication requirements for the mixed-signal nature of the device.
The board and mechanical aspects of the design also come
into the System Realization story. Cadence already provides solutions that
address the board portion of the mechanical design.
Q: The EDA industry
has focused its efforts on engineering teams. The EDA360 vision includes
project management. Why move up in the organization to assist project and business
A: The ability to track, predict and manage a project,
consistent with the macro-level business requirements, is of paramount
importance. Product complexity is
resulting in a pretty daunting lack of tractability and controllability at the
management level of a corporation, and is projected to surpass the 25% mark in
terms of total design costs at 22 nm. Information is coming in late and
fractured, without giving the management time to actually achieve
predictability goals, and this has to be addressed for sake of profitability as
part of System Realization.
We really need to revisit the whole notion of how a chip is
designed and how a product is developed, and help drive product development
from a high-level market requirement all the way to completion, using
geographically dispersed teams, various suppliers, and so forth. To enable a
faster convergence path, it will be important to comprehend notions of
enterprise planning and management, bring that into the customer engineering
groups, and connect to the automation that EDA is going to provide. Initial steps such as the Cadence-IBM
collaboration are already being taken, and much more needs to be done.
Q: How is the
recently announced Palladium XP, along with the Wind River partnership, a step towards System Realization?
A: Both of these deliverables are down payments towards
developing a broader set of solutions needed to enable application-driven
system development. The Cadence Verification Computing Platform, or Palladium
XP, is the first verification supercomputer addressing hardware/software
convergence. This helps ensure that
hardware and software are aligned and converging effectively, as opposed to
waiting for hardware and software to be developed independently of each other,
or having to delay product shipments because of the co-verification issues
across these traditionally separate domains.
The Wind River
partnership links the Wind River virtual
prototyping environment with Cadence's TLM-to-GDS flow, providing a complete
embedded system development solution.
This is accomplished by Wind River's
Simics environment being linked not only to Incisive Software Extensions
metric-driven verification technology, but also by providing a path from the
Simics models to silicon and co-verification with the Cadence Verification
Q: What will Cadence
show at DAC in connection with System Realization?
A: We will showcase some of the capabilities we recently
announced, as well as preview some of the work being done jointly with our
partners. The key idea is to start having a set of conversations with our
customers to understand how these deliverables, as well as capabilities
currently in research or conceptual stages, need to come together in order to
effectively address the growing set of System Realization challenges.
Gary – you’re absolutely right about the pivotal role that Electronic System Level (ESL) plays within EDA360. From a certain perspective an observation could be made that the EDA360 vision focuses more on System Realization / ESL per the core premise of application-driven top-down development to address the profitability gap. Hardware-software co-design to determine the best implementation has to be an element, and this needs to be increasingly done in context of the applications which would drive and configure that underlying lower level software and hardware. Steps such as an integrated TLM-to-GDS flow and verification computing platform are just some of the initial building blocks, and the direction has to be towards the end market / vertical applications dictating what happens. To that end, a top-down holistic view of System Realization is needed, and more importantly, should to be built.
Michal's response to a couple of questions in the middle are interesting because ESL and virtual prototyping ARE part of the EDA360 vision's ecosystem. Richard, you posed the question in a way typical of how EDA is in its present ruts: focus on one aspect or another of the design process, rather than the whole.
However, looking at the whole, I am troubled by EDA360's lack of emphasis where ESL would play its role, since it is the pivot from which lower levels of hardware and software implementation would proceed (to support the apps defined at higher levels, given the OS). Add to that, absence of hardware-software co-design (e.g., Space Codesign) which can help to determine the best implementation options as one or the other (again, to support the apps).