How well do the issues
and challenges raised in the recent EDA360 vision paper line up with customer experience? One
prominent EDA user who sees some close parallels is Philippe Magarshack,
central CAD and design solutions general manager at STMicroelectronics. In this
interview he discusses ST's key challenges with IP creation and SoC
integration, notes what he likes about the EDA360 vision, and talks about what
he'd like to see added.
Q: Philippe, what is
your role at STMicroelectronics?
A: I oversee the EDA strategy at STMicroelectronics, and I'm
also responsible for the internal development of cell libraries and physical
IP. I'm also responsible for delivering design solutions to ST development
groups. I'm directly involved with IP creation, but at the same time I develop
tools and methods for SoC designers, so I'm also supporting IP integration at
the top level.
Q: What design and
verification challenges concern you most when it comes to SoC development and
A: The EDA360 document describes three levels of
abstraction. Mostly we are focused on the first two, SoC Realization and
Silicon Realization. For SoC Realization, we have just gone to market with our
32 nm SoC design methodology, and the major challenge there has to do with the
size of the designs. That affects the complexity and management of hierarchical
data. Also due to the design size, we have a big challenge with functional
design and verification.
Another component, and one that I see clearly reflected in
the EDA360 paper, is the vast reuse of IP of many kinds. There is a wide
variety in the quality of IP in terms of the ability to integrate and configure
it at the SoC level.
In terms of Silicon Realization, certainly we see more and
more designs with low power solutions, including multiple power domains,
multiple voltages, dynamic frequency and voltage scaling, power switches, and
the like. This is not only for traditional low-power markets such as wireless,
but also for markets like consumer, peripherals, and networking chips. The
verification of these SoCs, and the verification of design intent, are very big
challenges moving forward.
Q: What challenges
are you seeing with IP creation?
A: Our challenge is that there is a constant demand for
tweaks for each new SoC. Say an SoC uses an HDMI part. The SoC designers will
ask for a slight change in the HDMI physical IP, and therefore we have to touch
the IP design, re-characterize it, and repackage it and deliver it to the SoC
We also see a constant need to port IP from one process node
to the next node. What should be a simple job of porting, verification and test
is actually, in most cases, a full redesign. The productivity is just not
there. That's a big challenge for IP creation.
Q: One thing the
EDA360 paper notes is that silicon providers are being asked to supply more and
more of the software stack. Are your customers, in fact, expecting that?
A: Definitely. This has been the name of the game in the
consumer space, where for a long time we have delivered reference designs
including software specs and demonstration applications. Customers will take it
from there and develop their own applications.
In the wireless market we had been in more of an ASIC
business model. A big part of the software was developed by our customers, and
we were just developing some low-level device drivers. That is no longer the
case. Our mobile customers now expect a complete software stack - and by the
way there are several operating systems now, Linux, Android and Symbian and
what have you.
For wireless and consumer platforms, we typically have more
head count in software development than we have in hardware development, even
though what we actually sell to our customer is the silicon.
Q: It sounds like
hardware/software integration would be a big concern for you. What's your
approach to this today?
A: Hardware/software integration is something we've had on
our minds for 10 years, and it's an area where ST has been helping to reshape
the industry through paradigm shifts. One was SystemC, and another was SystemC
TLM. But we see some resistance. When we shop around for soft IP, we don't
often find support for SystemC. The next standard we'll be asking for is
We have been able to provide a virtual prototype in house to
our software developers for some time, and hopefully also to our customers in
the future. So far we have made good progress in house with that paradigm. We
have SystemC models for a lot of IP and we can provide prototypes several
quarters ahead of silicon. As we move down in abstraction from SystemC to RTL
and RTL to gates, there is more detail at each level and therefore more chances
of disconnects between HW and SW. Therefore we have a hierarchical set of
verification tools that are a mix of software-based simulation models all the
way through hardware-based tools.
Q: One point made in
the EDA360 document is that EDA providers have focused on support for design
creation, but come up short when it comes to tools for integration. Do you want
to see more tool and methodology support for IP integration?
A: Definitely. There are areas where we could do more. For
example, equipping IP systematically with a self-verification environment would
be a really good step forward. But there needs to be more than that. IP blocks should be able to flag to the SoC integrator that they have been improperly
inserted in the SoC design. Today, the SoC designer eventually finds out the
hard way that some latency cycles were not accounted for in some system
transaction with a given IP block. This should pop up immediately during IP
The [EDA] focus has been on the IP creator. The absence of a
focus on the guy doing the IP porting is an issue for us. One focus for us
right now is to find productivity tools that enable smooth IP porting from one
process node to the next node, or to another process variant such as LP to GP.
Q: The EDA360 paper
raises the prospect of an IP "stack" that includes a verification environment,
design constraints, and driver software. Is this an attractive possibility?
A: It is absolutely very attractive. But the question I have
is that, with a device driver, you are assuming a particular SoC architecture
and address space. How much of that can be automated, and how much is specific
to the SoC? I do see some hope, given that the IP-XACT standard has information
for the register space, register addresses, and so forth. If there is a
standardized way to declare these, there is room for automation.
Q: Are there other
ideas in the EDA360 paper you find interesting?
A: What I like about it is that it centers on SoCs based on
different types of IP. SoCs can be designed productively only if we have a
strong abstraction paradigm and massive IP reuse. We need to know what is owned
by the IP provider and what is owned by the SoC architect. This is where there
has been some fuzziness in the past. If this document can help clarify that
handoff and responsibility issue, this would be a good step forward.
Q: Is there anything
you'd like to see added to the EDA360 vision?
A: One comment in general is that the paper doesn't speak to
the ecosystem or where we need standards or collaboration. It doesn't consider
the pre-existence of solutions and standards.
Major paradigm shifts in design methods have always been
enabled by widely adopted standards. This was the case of VHDL and Verilog
enabling logic synthesis and RTL simulation, then of SystemC and TLM enabling software
virtual prototyping. For the next paradigm in IP-based SoC design, a few
industry leaders need to select the "right" standards, define them, and drive
industry to adoption.
I'm therefore not clear on the timeframe in which some of
the concepts and solutions of EDA360 will become reality. What's the next step?
I'm sure that will become visible over time.
Q: Any parting
comments about the EDA360 paper?
A: I think it's a good initiative. It creates reactions,
both pro and con, and I think this is always good. Hopefully it will bring
about a community of users and EDA vendors who will consider their positions on
these problems and work together on the right standards as a follow-up to this