Two platform types vie for SoC designs

By Bob Altizer, Larry Cooke, and Grant Martin, EEdesign
November 7, 2002 (8:19 p.m. EST)

The debate on platform-based design of systems-on-chip (SoCs) has moved on from existential proofs and arguments about the coarsest features of platforms. Now there's a more involved attempt to build a taxonomy or classification scheme as an aid to identifying and understanding the different types of platforms, and the design styles and methods associated with them.

We have been working with other members of the Figure 1 - Application and technology-driven p latforms

These terms have some correspondence with the definitions "implementation" and "architecture" platforms as discussed by the Gigascale Silicon Research Center (GSRC) for platform-based design. See the article by Alberto Sangiovanni-Vincentelli, posted to EE Design February 5, 2002.

The technology-driven SoC platform is a bottom-up approach to developing and using an SoC, triggered by events such as new design feature or process technology. For example, the extension of a computing core's instruction set, availability of new memory technology, or migration to new process technology (already seen in the move from 180 to 130 nanometers, and expected to repeat at the upcoming 90 and 65 nm nodes and beyond) all drive the development of new technology platforms.

In contrast, the application-driven SoC platform is driven top-down from specific application domains, where a company or design team adop ts a product family design approach. In the product line or product family approach, platforms are integrated and managed sets of common features, upon which derivative products incorporating specific sets of features tailored to that application domain -- the product family members -- can be built.

Here, platform change is often driven by application convergence or by standards evolution. An example of the former is the addition of significant wireless communications capability to a personal computing PDA-style application, and of the latter, the migration of wireless from 2nd Generation standards through 2.5G GPRS, to the long-anticipated 3rd Generation UMTS standards.

Platform drivers
Technology-driven platforms tend to be application agnostic, not specifically driven by particular applications, whereas application-driven platforms are agnostic with respect to specific technologies. However, in a technology-driven platform, applications with higher performance, and/or integration nee ds will be the first users of the technology node. For example, the first users of the 130 nm node tended to be microprocessors and high performance ASICs for wired networking. There were also FPGA vendors, who emphasized both high integration (to overcome the density issues of FPGA fabrics) and high performance (because network infrastructure is a key market area for them).

Similarly, application-driven platforms need to move to technology nodes, which offer a suitable, "good-enough" performance plateau, meeting basic functional, performance, economic, and reuse requirements. Wireless SoC platforms were not possible until the industry was offering enough integration capacity and performance, at the 350/250/180 nm process nodes, to make 2G and 2.5G standard baseband platforms possible. And the 180 nm node is not adequate for 3G, which will demand the 130 nm process plateau, or better, for its processing needs.

Methods and scope
Technology-driven platforms are based on traditional bottom -up design methods -- standard cell libraries, full and semi-custom block design, component-based design, and integration in a more ad-hoc style. The emphasis is on the components, whether newly designed or a library-based intellectual property block, and their integration. Application-driven platforms provide a real opportunity for the blossoming of system-level design methods and top-down approaches, as well as a context-driven, "middle-out" IP integration task (the context being the system context for the platform in the application domain).

As a result of being technology and performance-driven, the technology platform allows extensive customization and tweaking of components in order to optimize the overall product. In the application-driven approach, the strong standards emphasis means that product-level integration tries to use the SoC or core platform without modification, or by configuring it within its "field of use" range of flexibility, to save verification time, and implementation risk. This latter approach has been called "reuse without rework" -- certainly, reuse without re-verification.

The difference in emphasis further manifests itself in the platform scope. Designers of technology platforms want to throw in every "cool" component and library element that will appeal to the greatest possible range of customers over the widest range of applications. This may be based on an "everything but the kitchen sink" kind of IP repository, to maximize the likelihood that a technology platform will be useful to anyone.

Application-driven platforms seek a Zen-like minimalism, asking: What exact set of design and IP common features must be included in the platform to adequately cover the application domain scope, over the range of anticipated derivative products? Application orientation emphasizes the use of product family-wide economic scoping models and feature set management tools, complementing the more traditional design engineering approaches. It may be a radical change for those accustomed to one-at-a-time product development and traditional technology-driven methods.

Figure 2 - The product family approach

As a result of these different emphases, the platform product roadmap for a technology-driven platform is ad-hoc, or based on a set of general customer requirements. An application-driven platform has a much more formal, planned, and medium-to-long term roadmap of both derivative products to be based on the platform, and required platform evolution.

Derivative design
Continuing this theme, it is often the case that derivatives built on a technology-driven platform are not necessarily well-known a priori -- perhaps only initial reference applications are known, which drive the subsequent derivative products in an independent, unconnected manner. These ad hoc derivatives are designed using traditional library approaches, and emphasize underlying base hardware, albeit with some basic software espe cially for the processor sub-systems.

Figure 3 - Application-driven platforms and the product family "power tower"

Application-driven platforms start out as part of a product family, a well-defined set of related derivative products which can be designed simultaneously and in parallel. Each derivative augments the platform with specific interfaces and functional blocks unique to the particular product family member. Because application-driven platforms tend to pre-develop and pre-verify so much of the IP needed for a product domain, especially reusable hardware IP, the derivatives emphasize creation and modification of software more than hardware.

By contrast, technology-driven platforms generally evolve by market demand for future derivatives, with the addition of specific hardware or software blocks to its libraries, because derivative designs are usually considered proprietary by their developers.

Customers and markets
Since technology-driven platforms are not tied to specific applications, they can be marketed widely to a large group of potential customers, in the same way that processor subsystems marketed as IP products can be reused in many contexts. As a result of their generality, customers are only loosely involved in technology-driven platform creation, perhaps only specifying generic characteristics, features, and performance specifications. The general platform offerings of LSI Logic's RapidChip, and Xilinx's Vertex-II Pro are examples of technology-driven platforms.

To contrast, application-driven platforms often involve strong ties to particular customers and product lines, fostering deeper, more intimate relationships, both internal within an SoC company, and with specific external partners. TI's DSP platform relationships with key wireless handset companies such as Ericsson and Nokia are good examples of the latter, extending to the newer TI OMAP platforms as well. Such strong application produc t coupling and deep partner relationships also imply strong architectural coupling between the platform, its choice of IP, and the lead partner requirements. This is especially important in choice of processors, as legacy software issues have a huge impact on processor evolution.

Architectures
In technology-driven platforms, the library components and basic choices of implementation "fabrics" (as the GSRC uses the term-see white paper reference) tend to imply the overall design architectures. Of course, the incorporation of specific embedded processors, their associated on-chip buses, and related memories and peripherals, tends to bring lots of architectural "baggage" along with them, both the hardware mentioned and associated basic software development tools (such as compilers, debuggers, cross-assemblers). So even technology-driven platforms, which offer embedded processor subsystems, do tend to "nucleate" some specific architectural approaches.

However, because users wish to optimize the designs based on the platform, the IP blocks and subsystems offered with it need to be open, so that implementations can be optimized for performance, power, cost, or other constraints. Offering customization or configurability at relatively low risk in a technology platform is a difficult challenge.

Application-driven platforms with a configurable kernel architecture tend to have the limits of parameterization pre-defined as the platform's "field of use," and tend to treat all components as black boxes which cannot be easily modified. Time-to-market concerns are paramount, and lowering risk drives the "reuse without rework" mentality. To offer the right application interfaces, application platforms emphasize layered and self-contained APIs as the primary vehicle on which to build the derivative parts of the specific product.

Technology-driven platforms thus tend to be volatile, with new platforms popping up with each advance in process or fabric design. Although new process technologies d rive the evolution of application-driven platforms, they evolve in a more orderly process with a longer-term roadmap and considerable architectural stability from one generation to the next.

Conclusions
A number of reputable IC industry spokesmen have felt that "SoC Platform" is an overused term. Still, its use is growing because it reflects the broader support needed to implement full Systems-on-a-Chip within increasing constraints on time and resources. The problem is compounded by the wide variety of emerging products that have the term "platform" attached to them. By delineating the differences between technology-driven and application-driven platforms, we're beginning to clarify the different uses of the term "platform" when applied to SoC development.

While recent announcements of technology-driven platform products suggest they will be the dominant SoC platform in the future, most application-driven platforms will be less visible because they are either completely internal within a large company, or are part of less publicized partnerships between companies. Furthermore, an application-driven platform can be created from a technology-driven platform, just as an application-driven platform can become the next generation's technology-driven platform component. So both types will continue to coexist for the foreseeable future.

This article describes part of the ongoing effort by the VSIA Platform-Based Design (PBD) DWG to create a detailed taxonomy for SoC platforms. In future articles, we'll look at other attributes that are part of our emerging taxonomy, and consider whether the "middle-out" integration approach is a distinct type, or a subset of the technology and application-driven types.

Bob Altizer (bob.altizer@basysconsulting.com) is president and principal consultant of BASYS Consulting in Phoenix, AZ. His interests include systems architecture, platform and product line-based design, as well as business, systems, and software engineering processes. He is chair of the VSIA Platform-Based Design Development Working Group.

Larry Cooke (lhcooke@vsi.org) is an independent consultant, and vice president of Marketing for VSIA. He does engineering and marketing on EDA methodologies, complex IC component and systems design. While at Toshiba he helped found VSIA and chaired its on-chip bus DWG.

Grant Martin (gmartin@cadence.com) is a Fellow in the Labs of Cadence Design Systems. Prior to Cadence, Martin worked for Burroughs in Scotland for 6 years and Nortel/BNR in Canada for 10 years. Martin is a co-author of the book "Surviving the SOC Revolution: A Guide to Platform-Based Design," published by Kluwer Academic Publishers, in November 1999, and a co-author of the new book "System Design with SystemC," published by Kluwer in May 2002.