Commentary: Dirty secrets of derivative SoC design

Dirty secrets of derivative SoC design
By Bob Dahlberg, EEdesign
January 16, 2004 (7:08 p.m. EST)
URL: http://www.eetimes.com/story/OEG20040116S0052

With the development cost of systems-on-chip (SoCs) heading north of $10 million, it's easy to understand why IDMs and fabless semiconductor companies want to find ways to leverage their investment in product development. A popular strategy is to build customer or application-specific derivatives.

Many product teams have started to pursue a “derivative platform chip” design methodology. Some economies of scale can be achieved by reusing the software on these SoCs, and to some extent, reusing the “hard” silicon IP helps too. What doesn't scale, however, is the physical design of these derivative chips. From a physical design perspective, every SoC is a fresh new design.

Three dirty secrets hold back the physical design of such derivative chips: IP quality, designer interoperability, and design interoperability.

The first dirty secret is that third party IP is a mess; there is no better word to describe the state of silicon IP quality today. This should not be surprising, since many people believe all it takes to design IP is a workstation loaded with Synopsys's HSpice and Cadence Design Systems' Virtuoso. IP arrives with missing model views, pin names are not consistent across models, and version control is unwieldy. Every single design team I have spoken to has mentioned problems with IP quality.

The economic issue with poor IP quality is that it shows up late in the design cycle (during LVS/DRC), creating unexpected project slips. The quality problem was recognized years ago when Synopsys and Mentor created the Open More IP assessment score as an objective measure of IP quality.

In August 2003, the VSIA improved upon this effort and announced an “IP quality checklist.” But such a system is only as good as the integrity of the firm filling out the questionnaire, which to date has not been good enough. The Fabless Semiconductor Association formed an IP task force in 2002 to investigate and solve IP portability, but the task force's priority quickly shifted to IP quality. Seeing a business opportunity in providing designers some defense, startups will undoubtedly emerge to offer library checking and creation tools to flag these quality problems early in the design cycle and head off delays.

The second dirty secret is a lack of designer interoperability. Know-how is not transferable from chip to chip, and every SoC team has its critically essential people who solve the tricky physical design challenges. However, their solution to a nasty issue is usually captured in tool-specific scripts that aren't reusable by other engineers because the scripts weren't written to be reusable. The effort to make software and hardware reusable is generally 50% additional effort — an unacceptable cost for a physical design team under tapeout pressure.

You can't just take a designer in the middle of one project and throw him into another project. Most design projects are not structured in an organized manner. Generally, physical designers work out of their private directories; their information is not stored in standard places nor is it organized in standard ways. If a critical engineer leaves or gets sick, the project comes to a grinding halt while the new engineers ramp up.

Finding the critical information and then understanding it takes time. More and more, the complexity of physical design projects requires teams to adopt a large software project style, where all information is organized in a rational way using source control programs such as Perforce.

The third dirty secret is the lack of design interoperability. Most enterprise IP is captured as hard IP, which has the advantage of being configured to a known state. Timing, area, and power are all verified and therefore repeatable. But IP characteristics such as aspect ratio, routing blockages, and resources are fixed, leading to non-optimal SoC floorplans, which can affect overall SoC performance and cost.

The obvious alternative to improve design interoperability is soft IP, such as Synopsys' DesignWare. The technical and economic success of the soft IP approach speaks for itself; Synopsys' annual DesignWare revenue is approaching $100 million. However, DesignWare works because the design elements are small — less than 50K gates. Such low complexity doesn't put much stress on modern place and route tools. But already companies have timing-critical functions in larger IP blocks — more than a million gates — and they seek a solution.

What is needed is a way to reshape the IP to its context, or a way to specify the component parts — floorplan, timing constraints, and the place and route “recipe” — so the design is independent of its designers, the design tools, and the technology.

Register-transfer logic (RTL) combined with design constraints enabled logic designers to separate function and timing, so they could define designs in a technology-independent way. Similarly, a “physical designer's RTL” would be a compelling solution. It would enable physical designers to decompose a physical design into a floorplan, timing constraints, and a place and route recipe in an understandable and repeatable way.

What would it take to make a physical design RTL specification work? First of all, it would necessitate technology that allows a block to be optimized in the context of its surroundings (pin and feedthrough assignment). It would have to be able to manage timing constraints, and it would have to offer a high-level, technology-independent way to specify the floorplan. ReShape and other start-ups are working diligently to make such technology readily available. From a physical design perspective, every SoC does not have to be a fresh new design, and derivative chips can soon have it all: IP quality, designer interoperability, and design interoperability.

Bob Dahlberg is vice president of marketing and b usiness development at ReShape Inc.