Silicon IP integration has become a major challenge for SoC
developers, and there's not much help today from EDA providers or third-party
IP vendors. That message came through loud and clear at a Management Day panel
at the recent Design Automation Conference, which featured five executives from
major semiconductor companies.
Day, sponsored by Cadence, involved a full day of paper sessions (one of
which I moderated) and one closing panel. This blog is a report of the closing
panel, moderated by Ron Wilson of EDN. The panelists included:
Much of the discussion gave me a sense of déjà vu. That's
because panelists echoed a key theme in the EDA360 vision paper, which states that
the EDA industry has focused primarily on design creation and has not served
the needs of SoC and system integrators. Anyone who doubts that contention had only
to attend this panel and hear what the design managers themselves had to say.
The Need for
The panel started with a discussion about the "resource
crunch," and both Madge (LSI) and Arabi (Qualcomm) talked about how their
companies are using platform-based design with IP reuse as a way of reducing
that crunch. Ron Wilson then asked, "increasingly, SoC development is not about
original design, it's about integration. It seems that when I talk to EDA
vendors I hear very little of that perception. Do we need a different set of
tools, or an emphasis on tools, to automate integration?"
Arabi, who had discussed this very issue during the previous
paper session, jumped right in. "Having tools that can quickly do integration
and verify that the integration is correct would be very useful," he said. He
noted that 80 percent of the blocks on his SoCs are externally-designed IP
blocks, and said that "in terms of design and verification, 60-70 percent of
the time is spent in integration."
A little later in the panel, Arabi noted that only a small
amount of the IP on an SoC platform changes when a new derivative chip is
designed. However, he said, "you have to go and repeat the same integration
task you did for the previous chip. That's why the SoC design effort is
dominated by integration work, which is unfortunately where we have the least
amount of automation. Because it is not an automated process you have to repeat
a good portion of what you have done."
"I think the EDA vendors would be disappointed to hear we
think they've done nothing for integration," Wagner (PMC-Sierra) said. He observed
that there have been attempts to support integration through the SPIRIT
Consortium IP-XACT standard,
but noted that it hasn't been well supported.
Jassowski said that Intel relies on internal IP development,
but even there, design teams have to be restrained from modifying the IP and
thereby destroying the value of reuse. "It's a constant struggle," he said.
What's Wrong With
I was a little surprised about how critical these design
managers were about third-party IP. I thought things had progressed further,
but apparently there are still a lot of challenges.
"If you can afford to design it internally, it's much
easier," Arabi said. "IP vendors do the minimum possible to sell their IP.
There is a good portion of the work that you have to do. Nothing is in place
when you go to talk to them. You have to requalify it, you have to look at the
schematics and everything, and whatever you ask for it's not there."
"Yes, IP reuse is the key to productivity. Unfortunately,
it's a bit of a mirage because IP, especially third-party IP, takes a large
amount of effort to verify and integrate," Wagner said. He said that
integrating hard IP can be especially problematic. "Manufacturability is a big
issue for us, and we don't believe third-party hard IP vendors put enough
effort into it," Wagner said.
"The end manufacturer or OEM doesn't want to hear where problems
came from, they want somebody to take ownership," Madge observed. "This is why
there is so much pressure to do development internally. The IP has to support
testability and be integratable. We have to take full ownership of the
solution. Collaboration is the key to the IP integration challenge."
The Gift That Keeps
At the panel's end, an audience member asked "if you could
have one tool as a gift, what would you take?" Answers:
Personally, I would be tempted to go with the Tesla, but to
solve the kinds of problems these managers are talking about, I think we need
some new ideas. The EDA360 paper talks about IP "stacks" with driver software
and a verification environment, integration-optimized IP, and open SoC
integration platforms. All ideas for solving the IP integration problem are
welcome. As Madge noted, it's going to take a collaborative effort.
Very interesting. We have seen very similar stats across the industry regarding current integration challanges. Not only is integration a bottleneck where you can spend 60%-70% of your Design/Verification time, but current design flows suffer from very poor 'integration reuse'. GUI hookup is not longer practical and many current scripting solutions (industry and in-house) don't scale and are too low level to match the current and future integration challanges. Integration productivity needs a real boost - not a 2x-3x gain but more like a 20x-30x.
Duolog has been working on 'Integration Automation' for several years and solves these exact problems with our Socrates Chip Integration platform. Socrates provides comprehensive integration automation, from IP port to chip pin as well as covering the HW/SW interface. A rules-based integration methodology raises the level of abstraction and promotes 'integration reuse'.
A key enabler in a chip integration platform is the ability to standardize IP - industry wide. While IP-XACT has been tagged to handle this , it is like SystemVerilog - it gives you language semantics, whereas there needs to be a methodology (similar to the UVM for SystemVerilog) developed that helps to standardize and aid reuse across the industry. Because this is missing, it is impossible to get IPs from multiple vendors and integrate them efficiently. IP-XACT also needs to be reawakened to align to the continuing growth in IP-Metadata.
We saw a very significant rise in the level of interest in Socrates during DAC, reflecting the realization of efficient integration as a rapidly growing need in the industry. A point well stated and elaborated within the EDA360 vision.
In order to enable a (mixed-signal) hard IP flow, you need to be able to provide customers with behavioral models of the IP (along with black box GDSII) so that you don't (as a vendor) give away the actual IP. A key part of that flow is being able to back-annotate the behavioral models.
As someone who worked on the Verilog-AMS committee trying to support that methodology I can say that it has not happened because the only proposal for the back-annotation part was mine, and it has been on hold for over a decade waiting for a promised alternative from a large EDA vendor (glad I didn't hold my breath).
As long as the EDA companies rather than the IP providers and users drive the tool standards I can't see this problem being fixed.
Richard, I would be interested if Ken Wagner of PMC Sierra will be able to elaborate further on his feelings over IP-XACT and EDA support for it. I would be the first to admit that on both the SoC user and EDA provider side, the Great Recession had stymied the investment needed to make it feasible in mechanisms for IP reuse in both RTL and ESL.
What is encouraging, for me, is that Cadence has rolled out its Open Integration Platform with IP-XACT support under EDA360 as one of the fruits of its SPIRIT Consortium efforts in setting up IEEE 1685. This adds to the options available to firms like PMC Sierra, in addition to what is available from Magillem, Duolog, Atrenta, Synopsys, Mentor Graphics, etc. Bon courage! :)