The Electronic Design Process Symposium is an annual workshop run by the IEEE Computer Society of Silicon Valley and the IEEE Council on Electronic Design Automation. I presented there because it’s devoid of product marketing pitches, and is two days of discussion on technical and process issues in SoC design. My slides are here:

http://www.eda.org/edps/Papers/4-3%20Kurt%20Shuler.pdf

My task for the presentation was to explain how IP reuse and the explosion in on-chip functionality has changed the best practices for SoC design. At Arteris, we make on-chip interconnect fabric IP that is used by companies creating leading edge SoCs, like Samsung, Freescale and HiSilicon. We have an inside view of the problems SoC designers face, and the corporate practices they use to tackle them.

Rather than speak about the software tools semi companies use to solve these problems (IP-XACT, Perforce, SVN, UVM, requirements traceability software, etc.) I thought it would be better to focus on four areas where the Arteris team has seen the best companies focus, and what these companies have learned. The lessons are indicative of the fact that the skillset required to make SoCs that sell is no longer “RTL coding”, but has become timely “SoC assembly.”

The four lesson learned are:

There are many software tools and methodologies to help with these, especially items #2 through #4. But the overriding point of my presentation is that creating SoCs “the right way” requires PEOPLE to change the way they do things.

#1. Internally-develop only your most important IP
The major problems here are that design teams rarely benchmark their IP versus commercial solutions or perform cost-benefit analyses of make vs. buy. Most importantly, managers fail to account for opportunity cost: The value of what a design team could be doing instead of the working on their current project.

Our industry used to see this a lot with CPU cores; most every company had their own CPU until ARM, MIPS and other IP companies proved that theirs brought more value than internally developed solutions. We are seeing this now with memory controller IP, where SoC design teams are transitioning from internally developed IP to solutions from Cadence, Synopsys, Uniquify and others. And we’ve seen a huge change in the last four years where most SoC makers have abandoned internally on-chip fabric development in favor of commercial fabric IP like Arteris FlexNoC.

#2. Create a corporate “IP library”
It’s amazing how many companies don’t know what IP they have, whether internally developed or commercial. Not knowing what you have makes it nearly impossible to implement company-wide methodologies or to use a SoC platform and derivatives development approach.

The best companies collect and document all their IP (including associated software!) and make the library searchable and accessible to all design teams in the company. That way, if one team wants to use an IP already being used by another team, they can ask questions of that team and then contact purchasing if they would like to evaluate or use the IP. This is especially important for companies that grow by acquisitions!

#3. Develop corporate design and verification methodologies
This has to do with accelerating the company’s “learning curve.” Doing more designs by more people using similar processes allows more learning to optimize and adapt methodologies. This also encourages optimal IP usage and more IP reuse.

#4. Use a platform and derivatives approach
This has become more common in the last 4 years, aided by the use of highly configurable SoC interconnect fabrics. Creating derivative chips based on common platform give companies the flexibility to target more markets at a lower cost, and to more quickly respond to market changes and competitor actions.

New competitors?
What stops people from doing best practices that at first look seems obvious?
The more experienced a team is, the harder it usually is for them to change or adopt new methods. This is because it is simpler in the short term to patch what isn’t working any longer, rather than solve the issue for the long term. It’s easier in the long term to continue doing things, “the way we do things around here.”

The problem is that there are new competitors to the fabless companies. And they have less legacy experience and are eager to adopt best practices and become world class right away. I’m not talking about the new companies in mainland China creating world-class SoCs; rather I’m talking about the fabless semi vendors’ best customers!

I spent some time explaining a simplified view of the semiconductor value chain (slide 11), highlighting companies like Google, Amazon, Microsoft, Apple and eBay that have hired their own chip design teams to either design custom chips, or to provide very specific requirements and even IP to incumbent fabless companies. A look at slide 12 shows how much more cash these companies have than their fabless semi suppliers. And a quick search of LinkedIn will show how extensively they have hired chip design talent from our industry.

My bottom line was that fabless companies need to implement these best practices if they want to remain the most efficient designers and producers of advanced SoCs. If incumbents stagnate and cannot adapt fast enough to meet their best customers’ needs, then those customers have the option to create chips themselves.
Please let me know what you think.

P.S. Many thanks to the organizers of this IEEE workshop:

• Aparna Dey (General Chair and Technical Marketing Director for Standards at Cadence),
• Naresh Sehgal (Session Chair for Pre-Silicon SW Development Platforms and SW Architecture Manager at Intel),
• Gary Smith (Session Chair for Top Semiconductor Design Flow Challenges Panel and founder of Gary Smith EDA),
• Herb Reiter (Session Chair for FINFET, 3D-IC, FD SOI and head of eda2asic consulting),
• Daniel Nenni (Session Chair for 2 tracks! IP Verification & Qualification and Integration, Designing, Standard. And Chief SemiWiki dude.)
• John Swan (Past general chair and Mother Hen making sure everything was running well. He runs Swan on Chips.)

lang: en_US