1. Introduction
The complexity of electronic designs and the number of technologies that must be mastered to bring to market winning products have forced electronic companies to focus on their core competence. Product specification, intellectual property (IP) creation, design assembly and manufacturing are, for the most part, no longer taking place in the same organization. Indeed, the electronic industry has been disaggregating from a vertically oriented model into a horizontally oriented one for a few years and integration of the supply chai n has become a serious problem.
Time-to-market pressure, design complexity and cost of ownership for masks are driving the industry towards more disciplined design styles that favor design re-use and correct-the-first-time implementations. The quest for flexibility in embedded system design, coupled with the previous considerations, is pushing the electronic industry towards programmable solutions for a larger class of designs than ever before. Design methodology has become the focus, and it is clear that design infrastructures and tools must be developed in synchrony with design methodology.
Creation of an economically feasible electronic design flow requires a structured methodology that theoretically limits the space of exploration, yet still achieves superior results in the fixed time constraints of the design. This approach has been very powerful in design for both integrated circuits and computer programs. For computer programs, the use of high-level programming languages has replaced fo r the most part assembly languages, for integrated circuits, regular structures such as gate arrays and standard cells have replaced transistors as a basic building block. The methodology promoted in this paper can be seen as the result of a natural progression in the quest for higher level of abstractions, as shown in Figure 1.
Figure 1 -- A brief history of abstraction in design (Source: F. Schirrmeister).
The methodology described here is based on defining platforms at all of the key articulation points in the design flow. Each platform represents a layer in the design flow for which the underlying, subsequent design-flow steps are abstracted. By carefully defining the platform layers and developing new representations and associated transitions from one platform to the next, we believe that an economically feasible electronic system design flow can be realized.
The goal of this paper is to distill what has been d one over the years so that a unified view of design could be based on platforms -- that is, abstraction layers that hide the unnecessary details of lower level of abstractions. We have been promoting platform-based design for a number of years and we have seen several instances of this principle come to market in the form of chips, chip-sets, architectures and middle-ware including operating systems, compilers, device drivers and network communication protocols.
The platform-based design methodology we have focused on is the outgrowth of the system-on-chip (SoC) debate where the economics of chip manufacturing and design has been carefully studied.
1.1 Managing Costs
The overall goal of electronic system design is to balance production costs with development time and cost in view of performance, functionality and product-volume constraints.
Manufacturing cost depends mainly on the hardware components of the product. Minimizing production cost is the result of a balance bet ween competing criteria. If we think of an integrated circuit implementation, then the size of the chip is an important factor in determining production cost. Minimizing the size of the chip implies tailoring the hardware architecture to the functionality of the product. However, the cost of a state-of-the-art fabrication facility continues to rise: It is estimated that a new 0.18m high-volume manufacturing plant costs approximately $2-3 billion today.
NRE (Non-Recurrent Engineering costs) associated with the design and tooling of complex chips are growing rapidly. The International Technology Roadmap for Semiconductors predicts that while manufacturing complex SoC designs will be feasible at least down to 50nm minimum feature sizes, the production of practical masks and exposure systems will likely be a major bottleneck for the development of such chips. That is, the cost of masks will grow even more rapidly for these fine geometries, adding even more to the up-front NRE for a new design. A sing le mask set and probe card cost for a next-generation chip is over $1 million for a complex part, up from less than $100,00 a decade ago -- and this does not include the design cost. Furthermore, the cost of developing and implementing a comprehensive test for such complex designs will continue to represent an increasing fraction of a total design cost unless new approaches are developed.
Increasing mask and manufacturing setup costs are presently biasing the manufacturers towards parts that have guaranteed high-volume production from a single mask set. This translates to better response time and higher priorities at times when global manufacturing resources are in short supply.
Design costs are exponentially rising due to the increased complexity of the products, the challenges posed by physical effects for deep sub-micron and the limited human resources. Design productivity, according to Sematech, is falling behind exponentially with respect to the technology advances. Time-to-market constra ints are also growing at such a fast pace that even if costs were not an issue, it is becoming plainly impossible to develop complex parts within the constraints. An additional problem is the lack of skilled work force that could implement future Ics, considering the system aspects of the design and all of the second-order physical effects that will be of primary importance in deep sub micron.
1.2 A New Methodology
The design problems are presently pushing IC and system companies towards designs that can be assembled quickly from pre-designed and pre-characterized components versus full custom design methods. This translates to high-priority on design re-use, correct assembly of components, and fast, efficient compilation from specifications to implementations, correct-by-construction methodologies and fast/accurate verification. (The design time issue can be addressed not only by re-use but also by tools that provide automatic mapping. For example, if we had the ultimate silicon co mpiler, an architecture platform could be the entire set of micro-architectures the silicon compiler can map into.)
Our objective is a design methodology, platform-based design, that can trade-off various components of manufacturing, NRE and design costs while sacrificing as little as possible potential design performance. We define the methodology so that it applies to all levels of abstraction of the design, thereby providing an all-encompassing intellectual framework in which research and design practices can be embedded and justified.
In this paper, we define the motivations and principles for platform-based design. We believe that the popularity of this concept has led to confusion as to what this term means and implies. The goal here is to define what these characteristics are so that a common understanding can be built and a precise reference can be given to the electronic system and circuit design community.
Platform-based design has been generically associated to design styles that fav or software solutions over application specific hardware. The chip-in-a-day approach proposed by Bob Brodersen has been pitted against platform-based design as a more effective way of designing high-performance electronic systems. However, if the "formal" definition of platform-based design, as given here, is used, then one can see that design style extremes such as full custom and fully programmable styles can be embedded in the unifying framework offered here. In any case, we believe that the trend towards more software-based solutions is strong and is going to permeate electronic system design for many years to come.
2. Types of Platforms
The concept of platform has been around for years. However, there are many definitions of "platform." These depend on the domain of application.
In the IC domain, a platform is considered a flexible integrated circuit where customization for a particular application is achieved by progra mming one or more of the components of the chip. Programming may imply metal customization (gate arrays), electrical modification (FPGA personalization), or software to run on a microprocessor or a DSP.
For example, a platform needs to be a fixed micro-architecture to minimize mask-making costs, but flexible enough to warrant its use for a set of applications so that production volume will be high over an extended chip lifetime. Micro-controllers designed for automotive applications such as the Motorola Black Oak PowerPC are examples of this approach. The problem with this approach is the potential lack of optimization that may make performance too low and size too large.
An extension of this concept is a "family" of similar chips that differ for one or more components but that are based on the same microprocessor. For the case of the Black Oak, Motorola indeed developed a family of micro-controllers, such as Silver Oak and Green Oak, that differ for flash memory size and peripherals. The TI OMAP pla tform for wireless communication, the Phillips Nexperia platform, and the Xilinx Virtex platform are a few examples of this approach.
"We define platform-based design as the creation of a stable microprocessor-based architecture that can be rapidly extended, customized for a range of applications, and delivered to customers for quick deployment." Source: Jean-Marc Chateau, ST Microelectronics.
PC makers have been able to develop their products quickly and efficiently around a standard "platform" that emerged over the years. The architecture standards can be summarized in the following list:
- The x86 instruction set architecture (ISA) that makes it possible to re-use the operating system and the software application at the binary level3.
- A fully specified set of busses (ISA, USB, PCI) that make it possible to use the same expansion boards or IC's for different products4.
- Legacy support for the ISA interrupt controller that handles the basic interaction between software and ha rdware.
- A full specification of a set of I/O devices, such as keyboard, mouse, audio and video devices.
All PCs should satisfy this set of constraints. If we examine carefully the structure of a PC platform, we note that it is not the detailed hardware micro-architecture that is standardized, but rather an abstraction characterized by a set of constraints on the architecture. The platform is an abstraction of a "family" of micro-architectures. In this case, design time is certainly minimized since the essential components of the architecture are fixed and the degrees of freedom allow some optimization for performance and cost. For system companies, the definition of platform is very loose. This quote from an Ericsson press release is a good example: "Ericsson's Internet Services Platform is a new tool for helping CDMA operators and service providers deploy Mobile Internet applications rapidly, efficiently and cost-effectively."
3. Principles of Platform-Based Design
3.1. The Overarching Conceptual View
As we have seen, various forms of platform-based design have been used for many years. Our intention is to formally define the key principles of platform-based design that will serve as a framework for design technology research and practices.
The basic tenets of the platform-based design methodology we propose are:
- The identification of design as a "meeting-in-the-middle process," where successive refinements of specifications meet with abstractions of potential implementations.
- The identification of precisely defined layers where the refinement and abstraction process take place. The layers then support designs built upon them, isolating from lower-level details, but letting enough information transpire about lower levels of abstraction to allow design space exploration with a fairly accurate prediction of the properties of the final implementation. The information should be incorporated in appropriate parameters that annotate design choices a t the present layer of abstraction. These layers of abstraction are called platforms to stress their role in the design process and their solidity.
From a historical perspective, and the newly formed concepts stated above, we can state that the general definition of a platform is an abstraction layer in the design flow that facilitates a number of possible refinements into a subsequent abstraction layer in the design flow. The "mille feuilles" of Figure 2 is a rendition of the design process as a succession of abstraction layers. The analogy covers also the filling between consecutive layers. This filling corresponds to the set of methods and tools that allow one to map the design from one abstraction layer to the next.
Often the combination of two consecutive layers and their "filling" can be interpreted as a unique abstraction layer with an "upper" view, the top abstraction layer and a "lower" view, the bottom layer. We will see some examples of how to use this concept. 
Figure 2 -- Platforms, Mapping Tools and Platform Stacks
Every pair of platforms, along with the tools and methods that are used to map the upper layer of abstraction into the lower level, is a platform stack.
Note that we can allow a platform stack to include several sub-stacks if we wish to span a large number of abstractions. This will largely depend on the capabilities of the tools and the outcome of research programs such as the GSRC. We emphasize again that the upper view, the lower view, and the tools that map the two platforms are the important constituents of the platform stack. The larger the span, the more difficult it will be to map effectively the two, but the greater the potential for design optimization and exploration.
Importantly, most of this potential is unrealized due to the complex and sometimes unrealistic nat ure of the design and verification processes for a single-pass design flow. Our research is toward restricting the space of exploration as little as possible, but while enabling a reliable single-pass process.
Key to the application of the design principle is the careful definition of the platform layers. Platforms can be defined at several point of the design process. Some levels of abstractions are more important than others in the overall design trade-off space. In particular, the articulation point between system definition and implementation is a critical one for design quality and time. Indeed, the very notion of platform-based design originated at this point (see Ferrari and Sangiovanni-Vincentelli, 1999, Martin, Chang et al., 1999, Balarin et al., 1997, Keutzer et al., 2000).
In studying this articulation point, we have discovered that at this level there are indeed two distinct platforms that need to be defined together with the methods and tools necessary to link the two. The one that has b een studied the most is what we call the architecture platform.
3.2. (Micro-)Architecture Platforms
Integrated circuits used for embedded systems will most likely be developed as an instance of a particular (micro-) architecture platform. That is, rather than being assembled from a collection of independently developed blocks of silicon functionality, they will be derived from a specific "family" of micro-architectures, possibly oriented toward a particular class of problems, that can be extended or reduced by the system developer.
The elements of this family are a sort of "hardware" denominator that could be shared across multiple applications. Hence, the architecture platform concept as a family of micro-architectures that are closely related is mainly geared towards optimizing design time. Every element of the family can be obtained quickly by personalizing an appropriate set of parameters that control the micro-architecture. For example, the family may be characterized by the sam e programmable processor and the same interconnection scheme, but the peripherals and the memories of a particular implementation may be selected from a pre-designed library of components depending on the particular application.
Depending on the implementation platform that is chosen, each element of the family may still need to go through the standard manufacturing process including mask making. This approach then conjugates the need of saving design time with the optimization of the element of the family for the application at hand. Although it does not solve the mask cost issue directly, it should be noted that the mask cost problem is primarily due to generating multiple mask sets for multiple design spins, which is addressed by the architecture platform methodology.
The less constrained the platform, the more freedom a designer has in selecting an instance and the more potential there is for optimization, if time permits. However, more constraints mean stronger standards and easier addition of c omponents to the library that defines the architecture platform (as with PC platforms). Note that the basic concept is similar to the cell based design layout style, where regularity and the re-use of library elements allows faster design time at the expense of some optimality.
The trade-off between design time and design "quality" needs to be kept in mind. The economics of the design problem have to dictate the choice of design style. The higher the granularity of the library, the more leverage we have in shortening the design time. Given that the elements of the library are re-used, there is a strong incentive to optimize them. In fact, we argue that the "macro-cells" should be designed with great care and attention to area and performance. It makes also sense to offer a variation of cells with the same functionality but with implementations that differ in performance, area and power dissipation.
Architecture platforms are, in general, characterized by (but not limited to) the presence of programma ble components. That means that each of the platform instances that can be derived from the architecture platform maintains enough flexibility to support an application space that guarantees the production volumes required for economically viable manufacturing.
The library that defines the architecture platform may also contain re-configurable components. Reconfigurability comes in two flavors:
- Run-time reconfigurability, where FPGA blocks can be customized by the user without the need of changing mask set, thus saving both design cost and fabrication cost.
- Design-time reconfigurability, where the silicon is still application-specific; in this case, only design time is reduced.
3.2.1 Architecture Platform Instance
An architecture platform instance is derived from an architecture platform by choosing a set of components from the architecture platform library and/or by setting parameters of re-configurable components of the library.
The flexibility, or the capabilit y of supporting different applications, of a platform instance is guaranteed by programmable components. Programmability will ultimately be of various forms. One is software programmability to indicate the presence of a microprocessor, DSP or any other software programmable component. Another is hardware programmability to indicate the presence of reconfigurable logic blocks such as FPGAs, whereby logic function can be changed by software tools without requiring a custom set of masks.
Some of the new architecture and/or implementation platforms being offered on the market mix the two into a single chip. For example, Triscend, Altera and Xilinx are offering FPGA fabrics with embedded hard processors. Software programmability yields a more flexible solution, since modifying software is, in general, faster and cheaper than modifying FPGA personalities. On the other hand, logic functions mapped on FPGAs execute orders of magnitude faster and with much less power than the corresponding implementation as a sof tware program. Thus, the trade-off here is between flexibility and performance.
3.2.2 Architecture Platform Design Issues
Today the choice of an architecture platform is more an art than a science. Seen from the application domain, the constraints that determine the architecture platform are often given in terms of performance and size. For a particular application, we require that, to sustain a set of functions, a CPU should be able to run at least at a given speed and the memory system should be of at least a given number of bytes. Since each product is characterized by a different set of functions, the constraints identify different architecture platforms where applications that are more complex yield stronger architectural constraints.
Coming from the IC manufacturer space, production and design costs imply adding platform constraints and consequently reducing the number of choices. The intersection of the two sets of constraints defines the architecture platforms that can be use d for the final product. Note that, because of this process, we may have a platform instance that is over-designed for a given product; that is, the potential of the architecture is not fully utilized to implement the functionality of that product.
Over-design is very common for the PC platform. In several applications, the over-designed architecture has been a perfect vehicle to deliver new software products and extend the application space. We believe that some degree of over-design will be soon accepted in the embedded system community to improve design costs and time-to-market. Hence, the "design" of an architecture platform is the result of a trade-off in a complex space that includes:
- The size of the application space that can be supported by the architectures belonging to the architecture platform. This represents the flexibility of the platform.
- The size of the architecture space that satisfies the constraints embodied in the architecture platform definition. This represents the deg rees of freedom that architecture providers have in designing their hardware instances.
Once an architecture platform has been selected, then the design process consists of exploring the remaining design space with the constraints set by the platform. These constraints cannot only be on the components themselves but also on their communication mechanism. In fact, particular busses may be a fixed choice for the communication mechanism -- for example, the AMBA bus for the ARM microprocessor family. When we march towards implementation by selecting components that satisfy the architectural constraints defining a platform, we perform a successive refinement process where details are added in a disciplined way to produce an architecture platform instance.
Architecture platform-based design is neither a top-down nor a bottom-up design methodology. Rather, it is a "meet-in-the-middle" approach. In a pure top-down design process, application specification is the starting point for the design process . The sequence of design decisions drives the designer toward a solution that minimizes the cost of the architecture. The design process selects the most attractive solution as defined by a cost function.
In a bottom-up approach, a given architecture (instance of the architecture platform) is designed to support a set of different applications that are often vaguely defined and is, in general, largely based on designer intuition and marketing inputs. In general, IC companies traditionally followed this approach trying to maximize the number of applications, and hence the production volume, of their platform instances. The trend is towards defining platforms and platform instances in close collaboration with system companies, thus fully realizing the meet-in-the-middle approach.
Application developers work with an architecture platform by first choosing the architectural elements they believe are best for their purposes yielding a platform instance. Then, they must map the functionality of their appl ication onto the platform instance. The mapping process includes hardware/software partitioning.
While performing this step, the designers may decide to move a function from software implementation running on one of the programmable components to a hardware block. This hardware could be implemented anywhere from programmable logic to full custom, the representations of which would be abstracted from the implementation platform. Once the partitioning and the selection of the platform instance are finalized, the designer develops the final and optimized version of the application software.
Due to the market forces briefly outlined above, most of the implementation of system functionality is done in software. There is in fact a very strong trend in system-level design towards developing software away from hardware implementations. Indeed, market data indicate that more than 80% of system development efforts are now in software versus hardware. This implies that an effective platform has to offer a power ful design environment for software to cope with development costs.
In addition, one of the motivations toward standardization of the programmable components in platforms is software re-use. If the instruction set architecture (ISA) is kept constant, then software porting is much easier. However, this mechanism limits the degrees of freedom of system designers who may have to ignore very performing platforms in favor of older architectures to maintain software compatibility.
Thus, there are two main concerns for an effective platform-based design - the software development environment, and a set of tools that insulate the details of the architecture from application software. This brings us to the definition of an API platform.
3.3. API Platform
The concept of architecture platform by itself is not enough to achieve the level of application software re-use we require. The architecture platform has to be abstracted at a level where the application software "sees" a high-level interf ace to the hardware that we call Application Program Interface (API) or Programmers Model. A software layer is used to perform this abstraction (see Figure 3). This layer wraps the essential parts of the architecture platform:
- The programmable cores and the memory subsystem via a Real Time Operating System (RTOS).
- The I/O subsystem via the Device Drivers.
- The network connection via the network communication subsystem. (In some cases, the entire software layer, including the device drivers and the network communication subsystem, is called an RTOS).
Figure 3 -- Layered software structure (Source: A. Ferrari) In our conceptual framework, the programming language is the abstraction of the ISA, while the API is the abstraction of a multiplicity of computational resources (the concurrency model provided by the RTOS) and available peripherals, or device drivers. There are different efforts that try to standardize t he API or programmers Model.
In our framework, the API or programmers model is a unique abstract representation of the architecture platform via the software layer. With an API so defined, the application software can be re-used for every platform instance. Indeed the programmers model is a platform itself that we can call the API platform.
Click below to continue reading this article
