SoC Design Methods Evolve To Meet The Need For Speed

Imagine a scenario in which your design team has received the marketing department's requirements for a next-generation SoC design. But as often happens, before you can finish the lengthy design cycle, the marketers wave a red flag. The market for the end product on which the SoC is based has shifted and the device's functionality must be adapted.

Now you don't know how to respin the chip in time. Should you (a) jump off a bridge, (b) scream at marketing, or (c) consider a shift to a design methodology that not only accommodates SoC design needs from one project to the next, but also allows you to quickly modify a project late in the game, without a total redesign?

The correct answer, of course, is (c). That answer is embodied in a design methodology known as platform-based system-on-a-chip (SoC) design.

Platform-based SoC design is a way to remove a great deal of the risk associated with traditional SoC design methods. It offers numerous advantages, such as the ability to easily build-in differentiating features and to reuse proven design elements in derivatives of earlier designs. It's scalable enough to allow designers to plug multiple iterations of intellectual property (IP) into a design. Such methodologies also save time by virtue of the fact that designs start out by leveraging a pre-existing initial design using predefined and preverified IP cores, buses, and software.

Typically, designers will select a core platform—a processor subsystem with some integrated specialized IP and standard buses—onto which memory, complex peripherals, processor boot code, the operating system (OS), and applications will be automatically connected. Support tools will generate the design along with the development-tool environment required to create and verify the design.

Definitions of the methodology vary to some degree. Most practitioners, though, would agree that a platform-based SoC design is one in which architectures, IP, connectivity, and verification suites for an SoC are reused within a structured, repeatable design environment, with the goal of minimizing design-cycle time. The basic premise behind the need for a platform solution is that time-to-market outweighs maximum optimization.

"A platform-based methodology enables SoC designers to focus on the part of the design that differentiates their design from any other," explains John Wilson, business development manager for the Platforms Group of Mentor Graphics' SoC Verification Business Unit. The goal is the ability to generate derivatives of a basic design with quick feature upgrades without modifying the basic topology.

One of the main time-to-market advantages of platform-based SoC design is the ability to create virtual prototypes, which are also known as virtual platforms (Fig. 1). These let designers start embedded software development and integrate hardware and software before they gain access to the physical prototype. Typically, embedded software development and debugging starts after hardware development. With a virtual platform, hardware-software integration can occur earlier. Therefore, not only are those bugs found and resolved, but the designer can also discover and resolve issues related to communications between the hardware and software, the timing of this communication, and the servicing of interrupts.

As a result, design respins are at the front end of the design process, and not after the physical prototype is returned, notes Pete Hardee, director of product marketing at CoWare Inc. "The hardware teams have the ability to add hardware to the core platform, verify the hardware using the 'real' application, update the hardware based on the results of running the real application, and continue this cycle with high confidence in the product's completeness."

The time-to-market emphasis at the expense of design optimization means that some application classes for SoCs lend themselves more readily to a platform approach than do others. Most applications using platforms are in the telecom, wireless, and consumer multimedia domains. One reason is that these domains have the most pressing time-to-market requirements, with design cycles of less than six months. These domains also benefit from the critical mass of existing standards, such as Bluetooth and W-CDMA, that can be implemented as platform libraries and then reused throughout a large variety of designs.

Other mainstream applications are systems with a raft of potential features or applications for disparate markets. "For example, a 3G cell phone is ideal," Hardee says. "Different 3G phones with varying features might appeal to different markets—teens versus business executives, for example. Other potential uses include communications and Internet appliances."

After you have analyzed your needs and determined that a platform-based approach to SoC design is right for you and your team, you must confront certain issues and answer some questions before comfortably taking the plunge.

Right up front is the added cost of switching to a new methodology. If you decide the cost is too high, you could be forced to stop right there and stick with the traditional ASIC SoC approaches. The added cost comes not only from creating, acquiring, or licensing IP, but also from the expertise required to support and upgrade such technology.

The hardest thing about platform methodologies, remarks Jeff Jussel, director of global programs for Mentor's Consulting Division, is the overhead required for initial platform setup. "To do it properly, much has to be known about the target SoC applications, verification of those SoC designs within their system environments, the preferred design environment, and even the company organization and culture," Jussel explains.

An inherent challenge in the execution of platform SoC design is that it must be implemented with design re-use as a goal. Because an integration platform derives much of its productivity by focusing on a particular target application, it begins with a characterization of that target market. As a prerequisite, the design team must clearly see the application that it's after, so more resources may be consumed on the baseline design than elsewhere.

Additionally, one has to trade off flexibility and design effort against the benefits of an SoC device. In some cases, the close relationship as well as high dependence required with the silicon partner in an SoC device might limit customers' vendor choices.

"Often, designers suffer from the 'Not Invented Here Syndrome' that limits their capability to reuse work," says Sandeep Kumar of Texas Instruments Inc. Part of this stems from the designer's fear of using something not completely understood and being stuck with it if it doesn't perform to specification.

Successful platform SoC design requires a prior investment in designing and preverifying the hardware and software library portfolios, which are made available through the platform. Because characterization of these library elements typically goes all the way to silicon, this investment may become very significant. The return on investment must be calculated very carefully, as it will have to be distributed over a large number of derivative designs.

A designer must additionally consider that platforms and IP may be tuned for specific applications. Slightly different versions of an IP block or bus protocol might exist in the same platform for use in different applications. So instead of a one-size-fits-all platform, many discrete options are available for reuse tuned to specific applications.

Jussel maintains that most reused IP is actually more likely to have been created internally. Only a small fraction of reused IP will come from external sources, making the issues related to IP reuse more about standardization. "To be effective, all of the IP has to use the same development methodology, coding guidelines, deliverable formats, and so on. Such standards are rarely adopted universally within a company and may never be universal within the industry. So for a platform to work, a set of uniform design standards must first be developed and then be adopted by the design community," Jussel says.

The platform needs a mechanism for qualifying IP against these standards so legacy IP and IP brought in from third parties for a design will be guaranteed to work with the platform. Once general standards are in place, application-specific standards, architectures, and methods can be developed to exploit the platform-based environment.

In addition, designers need an easy way to mix and match IP for different designs. "Unfortunately, most IP isn't written for reuse," Hardee says. "When it's used again in a different design, the interfaces don't work right because they were optimized for the first design."

In traditional ASIC design, it's very hard to substitute major IP blocks because all of the interfaces to the IP blocks are hard-coded into the design. If central parts of the design, such as the processor, bus, or memory architecture, require any changes, then the entire design must be reworked. Intertwining an IP block's behavior with its interface in this manner means that to offer a strong yet flexible IP portfolio, semiconductor vendors are forced to maintain a large IP repository, including multiple variants of the same function for different buses. Add to this the fact that models of the IP blocks are frequently too low-level, and it's clear why the much-vaunted era of wide-scale IP reuse has yet to occur.

CoWare gets around this by helping its customers create IP libraries where the communication (interfaces) is separate from the behavior. Plus, the company provides Interface Synthesis, a capability that automates the time-consuming creation of software drivers and hardware glue logic and speeds SoC design, whether or not it's used in a platform-based design.

Frequently, the integration issue isn't really one of the IP itself, but of giving the functional blocks a sure way to communicate among themselves. In certain situations, it's possible to rely on SoC bus standards, such as ARM's AMBA or IBM's Core Connect, to handle the interconnection efficiently. Many times, however, this can cause delays and problems if the cores aren't designed for those buses.

"If I'm going to take a platform-based approach, I have to be able to define a 'socket'," says Grant Pierce, president and CEO of Sonics Inc. To date, the industry has lacked a complete socket specification to leverage as a de facto standard. (See "Leveraging Intellectual Property Gets Easier As Standards Make Headway," Electronic Design, June 26, 2000, p. 91.)

For Pierce, the purpose of the socket is to create an easy way to integrate new IP into the system. Sonics' Open Core Protocol (OCP) is intended to define a bus-independent, configurable interface between IP cores and on-chip communication subsystems.

Once a core is interfaced via the OCP, a complete description is defined for system integration, which the company claims enables core reuse and test reuse without rework. And, using the protocol effectively decouples core development from development of the SoC as a whole, making the processes independent of each other.

Another key piece of the company's solution is its SiliconBackplane µNetwork. This on-chip communication structure manages data, control, and test flows on the SoC.

Complete development of standards for IP and the ways in which cores interact would certainly help to complete the picture for platform SoC design. Beyond those mentioned here, further infrastructure issues need to be addressed (see "Platforms Promise Mainstream SoC Design," p. 80).

For example, there are the problems associated with verification. Rapidly creating large designs puts a greater strain on the verification process. Usually in conventional designs, the verification environment is created in parallel with the design. In a platform-based methodology, the design is created very quickly with design elements that may not be understood by the designers well enough to allow the quick creation of an appropriate verification test suite.

Ideally, each IP block should have a generic verification suite so as to not require that the user create custom verification for each block, Jussel says. Be-yond this, each SoC application supported by the platform must have a verification suite that checks the overall functional operation of the design. Then, the designer is left only with the problem of checking IP interoperability and operation of the SoC within the larger system.

One available verification solution is embodied in Quickturn Design Systems' Rapid Prototyping System (RPS). Quickturn RPS is a reconfigurable prototyping system containing individual logic blocks or IP cores. These are placed on small pc boards, called core-boards, which plug into the backplane of the RPS solution. The RPS solution can host up to 31 core boards, and each core board can hold IP in the form of a bonded-out core, actual silicon, or a soft model mapped to an FPGA (Fig. 2).

Platform-based design approaches aren't for everybody or for every SoC project. Designs targeted at applications where such requirements as scalability and future product upgradability aren't important—such as data interface designs—won't benefit. Nor will those designs that must be optimized down to the transistor level.

But if it's an approach that fits your needs, there's a bright future for platform SoC design. According to Sanjay Sawant, product line manager for rapid prototyping products at Quickturn, 80% of today's designers use block-based designs (with opportunistic design reuse), 10% employ custom logic (with no design reuse), and 10% use platform-based SoC methods.

During the next 18 to 20 months, Sawant expects to see 80% of designers moving toward platform-based SoC designs with the other 20% doing block-based designs. With this deepening acceptance of platform-based SoC methodologies, it's surely a technology to keep an eye on in the future.