Home > Community > Blogs > Industry Insights > stmicroelectronics user interview ip creation soc integration and eda360
Login with a Cadence account.
Not a member yet?
Create a permanent login account to make interactions with Cadence more conveniennt.

Register | Membership benefits
Get email delivery of the Industry Insights blog (individual posts).


* Required Fields

Recipients email * (separate multiple addresses with commas)

Your name *

Your email *

Message *

Contact Us

* Required Fields
First Name *

Last Name *

Email *

Company / Institution *

Comments: *

STMicroelectronics User Interview – IP Creation, SoC Integration, and EDA360

Comments(0)Filed under: Industry Insights, SoC, IP, ST Microelectronics, EDA360, Magarshack, ST

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 integration?

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 team.

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 IP-XACT.

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 insertion.

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 paper.

Richard Goering



Leave a Comment

E-mail (will not be published)
 I have read and agree to the Terms of use and Community Guidelines.
Community Guidelines
The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. 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. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.