Defining platform-based design

In our framework, the RTOS is responsible for the scheduling of the available computing resources and of the communication between them and the memory subsystem. Note that in several embedded system applications, the available computing resources consist of a single microprocessor. In others, such as wireless handsets, the combination of a RISC microprocessor or controller and DSP has been used widely in 2G, 2.5G and 3G, and beyond. In set-top boxes, a RISC for control and a media processor have also been used. In general, we can imagine a multiple core architecture platform where the RTOS schedules software processes across different computing engines.

There is a battle that is taking place in this domain to establish a standard RTOS for embedded applications. For example, traditional embedded software vendors are now competing with Microsoft, which is trying to enter this domain by offering Windows CE, a stripped down version of the API of its Windows operating system. In our opinion, if the conceptual framework we offer here is accepted, the precise definition of the hardware platform and of the API should allow one to synthesize automatically and in an optimal way most of the software layer, a radical departure from the standard models borrowed from the PC world.

3.4. System Platform-Stack

The basic idea of system platform-stack is captured in Figure 4. The vertex of the two cones represents the combination of the API, or programmers' model, and the architecture platform. A system designer maps the application into the abstract representation that ""includes"" a family of architectures that can be chosen to optimize cost, efficiency, energy consumption and flexibility. The mapping of the application into the actual architecture in the family specified by the programmers' model or API can be carried out, at least in part, automatically if a set of appropriate software tools -- software synthesis, RTOS synthesis, device-driver synthesis -- is available. It is clear that the synthesis tools have to be aware of the architecture features as well as of the API. This set of tools makes use of the software layer to go from the API platform to the architecture platform.

Figure 4 -- System Platform Stack

The system platform-stack is the combination of two platforms and the tools that map one abstraction into the other. We recall that the platform-stack can be seen as a ""single"" layer obtained by gluing together the top platform and the bottom platform, whereby the upper view is the API platform and the lower view is the collection of components that comprise the architecture platform.

In the design space, there is an obvious trade-off between the level of abstraction of the programmers' model and the number and diversity of the platform instances covered. The more abstract the programmers' model, the richer is the set of platform instances, but the more difficult it is to choose the ""optimal"" architecture platform instance and map automatically into it. Hence, we envision a number of system platform-stacks that will be handled with somewhat different abstractions and tools. For example, traditional platforms that include a small number of standard components such as microprocessors and DSPs have an API that is simpler to handle than that for reconfigurable architectures.

There are also mixed-level platforms (such as C and assembler, or RTOS and direct register read/write). They may be non-ideal from the viewpoint of abstraction, but they are still used and should be mentioned. In the absence of good mapping tools, they may be the only option. Another way of viewing them is their ability of mixing blocks designed using various platform layers in the same design.

Generalizing our thinking process, we view design as primarily a process of providing abstraction views. That is, an ""API"" platform is a pre-defined layer of abstraction above some more complex device or system that can be used to design at a higher level. Suppose our low level machine is a microcontroller with some peripheral devices and some programmable logic. A high-level language compiler, a small RTOS and a logic synthesis tool for the programmable logic, along with models of the fixed peripherals, might provide the link between the API platform and this machine architecture.

Following this model, we see that a structural view of the design is abstracted into the ""API"" model that provides the basis for the design process that rests upon this layer of abstraction. To choose the right architecture platform we need to export at the API level an ""execution"" model of the architecture platform that estimates the performance of the lower level architecture platform.

This model may include size, power consumption and timing; these are variables that are associated to the lower level abstraction (from the implementation platform) and that cannot be computed at the API level. On the other hand, we can pass constraints from higher levels of abstraction down to lower levels to continue the refinement process satisfying the original design constraints. Together with constraints and estimates, we may also use cost functions to select among feasible solutions.

In summary, the system platform-stack is a comprehensive model that includes the view of platforms from both the application and the implementation point of views. It is the vertex of the two cones in Figure 4. Note that the system platform effectively decouples the application development process (the upper triangle) from the architecture implementation process (the lower triangle). Note also that, once we use the abstract definition of ""API"" as described above, we may obtain extreme cases such as traditional PC platforms on one side and full hardware implementation on the other.

Of course, the programmer model for a full custom hardware solution is trivial since there is a one-to-one map between functions to be implemented and physical blocks that implement them. In this latter case, platform-based design amount to adding to traditional design methodologies some higher level of abstractions. Re-usability is of course almost non-existent. Figure 5 shows how different design styles can be framed in a disciplined platform-based design approach. In this figure, we also show the mapping of an application onto the appropriate platform and the export of performance parameters from the lower level platforms to the API.

Figure 5 -- Design Styles for Architecture Implementation in Platform-Based Design (Source: R. Newton).

3.5. Silicon Implementation Platform Stack

The platform stack from architecture to actual physical implementation is called the silicon implementation platform (SIP) Stack. It takes all of the components of the architecture platform and maps them to a physical implementation. In this case, we can identify a set of abstractions that are related by mapping methods in the same vein that we followed above. In addition, we can also export to the physical implementation problem the view of platform stack to include the combination of two platforms and of the intermediate levels of abstraction with the transformations and tools needed to go from one abstraction to the next.

The top-level view of the SIP stack is the platform architecture view, as shown in Figure 6.

Figure 6 --Silicon Implementation Stack

The view from beneath the architecture platform is a netlist of abstract views of computational blocks and interconnect structures. The next platform, or subsequent level of abstraction towards implementation, can vary somewhat based on the underlying technologies that are abstracted. For example, the layout of the blocks and of the interconnections among blocks affects all the performance parameters such as size, timing and power consumption. The constraints from the architecture platform that were generated based on implementation layer abstractions are used to determine whether a particular layout of the architecture platform instance can be used.

In some cases a floorplan view would be used to export upward the parameters related to various components, including interconnect. In this case, the floorplan is itself a platform in our conceptual framework. In other cases, including those which result from creation of new implementation platforms and silicon implementation methodologies as part of our GSRC research, the silicon implementation platform stack can be a single multi-faceted layer, as shown in Figure 4. Similarly, the floor-plan platform can be directly incorporated as part of the architecture platform. More research remains to be done on this topic.

The concept of implementation platform is strongly related to the concept of regular design and design re-use. Based on extensive reuse, floorplan platforms represent blocks and associated interconnection patterns that are selected from a library of pre-designed components. These components may be described at the detailed physical level or at a higher level of abstraction where new abstractions are used to represent the details of the manufacturing process and isolation from the complex manufacturing interface.

More generally, the architecture components can be mapped to regular blocks of logic that are synthesized into geometrically and physically regular, often programmable and/or reconfigurable fabrics. Importantly, these fabrics that lie in the SIP stack incorporate accurate abstractions from the manufacturing interface. In addition, the myriad of components and instances which lie in the SIP stack are based on regular structures that facilitate correct-by-assembly design, ease of verification, construction of reliable components from widely fluctuating parameters, and manufacture of high-yielding reliable silicon ICs.

It should be noted that this design process from system conception to implementation could also stop at other platform abstractions where the actual implementation is fully instantiated. Any design style (or at least the most meaningful design styles) can be restructured and reorganized to fit within a platform-based concept. It can span all the way from a customized solution to a fully programmable standard part.

Of course, in the case we do not leverage re-use and flexibility via novel regular structures, there is no difference from traditional design flows. The important point here is that this approach does capture re-use and flexibility, but it is itself flexible enough to mix and match design styles to accommodate a wide spectrum of applications and implementation platforms.

The final stack on the path to implementation and manufacture is the mask set and the recipes for manufacturing. The technology files are the characterization of the manufacturing interface platform used to generate the most accurate performance and cost parameters, as shown in Figure 7.

Figure 7 --Manufacturing Interface Platform Stack (Source: L. Pileggi).

In the SIP stack, the abstract views exported above and below are fairly well understood since they have been part of the ASIC design flow in use for years. For deep sub-micron technologies, though, the accuracy of these approximations is in discussion since the actual layout of the wire-transistor pattern affects the performance parameters in such a substantial way that the decomposition into logic synthesis and detailed layout creates timing closure problems.

In addition, what were considered physical second-order effects (such as crosstalk and power distribution) a few years ago are now very important for the performance of the design. These must handled via regular design structures that facilitate correct-by-construction assembly and accurate abstraction to the higher platform layers. Clearly, estimation, characterization, cost functions and constraint passing are all essential components in the design flow when we consider the final implementation of the architecture platform instance.

The manufacturing interface, once a process taken for granted, is now a critical step in controlling and predicting cost, performance and reliability. Models of the manufacturing realities must be accurately abstracted to the implementation platform, which requires new instantiations of geometrical regularity. This lowest layer of regularity provides a foundation for subsequent layers of implementation regularity.

3.6. Network Platforms

The platform-based design paradigm can be extended to levels of abstraction higher than the API platform. In particular, it can be applied to the design of large-scale distributed systems such as communication networks.

To implement communication networks, the functionality is mapped onto a network platform (NP) that consists of a set of processing and storage elements (nodes) and physical media (channels) carrying the synchronization and data messages exchanged by nodes. Nodes and channels are the architecture resources in the NP library and are identified by parameters like processing power and storage size (nodes) and bandwidth, delay, and error rate.

The task of choosing an NP requires selecting from the NP library an appropriate set of resources and a network topology that defines how channels connect nodes. A broad range of options of physical channels - such as cable, wireless link, fiber -- and network topologies, such as mesh, star and ring, are usually available. Therefore, the design space to explore is quite large.

Moreover, choosing an NP is especially challenging for distributed networks due to the inherently lossy nature of the physical channels that connect nodes at distant locations. In these cases, when reliable communication is required, it is necessary to introduce additional resources (such as request/acknowledgment protocols) to overcome the effects of noise and interference.

Introducing protocols requires adding processing power and memory units at the communicating nodes. As a result, the protocol components often dominate the implementation cost function and the design effort. Therefore, in selecting an NP, it is essential to balance the cost of all the different components and tradeoff between the use of complex protocols and that of more reliable, and more expensive, channels.

Channels can be defined at different levels of abstraction. Physical channels, such as coaxial cables or optical fibers, merely transport bits. More abstract ""logical"" channels, such as ATM virtual circuits, that consist of a physical channel and a set of protocol functions, may provide more sophisticated communication services such as in-order and reliable packet delivery.

Communication is usually described in terms of a stack of layers, where each layer defines an abstraction level and, hence, a network platform. The description of an NP is usually given in terms of a set of interface function primitives that the applications running on it can use. This set of primitives defines the network API (NAPI) platform and allows hiding of many lower layer details. Primitives typically present in an NAPI platform include confirmed/unconfirmed data push, data request, reliable/unreliable send/receive, and broadcast/multicast send.

For example, consider the multicast-send primitive. It is a useful abstraction and is invoked when the application requires one node to address a group of nodes having a common attribute. The underlying software layer translates the symbolic address identifying the destination nodes and automatically sends a copy of the packet to all the destinations relieving the application programmer from the task to call multiple one-destination send.

4. Conclusions

The main motivation that has prompted us to develop these concepts was design re-use and regularity to the fullest extent due to the economics of building future electronics systems. We defined a platform stack as a stack of layers of abstraction:

• The upper layer is the abstraction of the design below so that an application could be developed on the abstraction without referring to the underlying layers.
• The lower layer is the set of rules that allow one to classify a set of components as part of the platform.

However, because of the definition of platforms and platform stacks we use, it is possible and desirable to extend the platform concept to cover all steps of design from conception to implementation (see Figure 8). The tools and methods used to map the upper and lower layers of a platform-stack are the glue that keeps the platforms together. Hence, we can imagine a platform stack that spans several levels of abstraction of a design. To be able to choose efficiently the instances of the platform, we need to deal with the constraint propagation process in the top down aspect of the design, while we need an annotation mechanism that can be associated to the top levels of abstraction to capture lower level details. These mechanisms are an essential part of platform-based design.

Figure 8 -- Composition of Platform Stacks

At the architecture platform level, flexibility is an essential property. We expect that programmable components will take the lion's share of the computing power of a platform, so that electronic design will be increasingly dependent on software. The leading platforms today such as Philips Nexperia for multi-media and TI OMAP for cellular phones are all based on programmable components: a micro-processor (MIPS) with a VLIW processor for Nexperia and a micro-processor (ARM) with a DSP for OMAP.

However, there is a strong interest in developing an approach that can take into considerations re-configurable processors and logic, an intermediate platform between a fixed processor one and an ASIC. In addition, approaches such as the chip-in-a-day process are of great interest when performance and power efficiency are sought. In this case, the use of abstraction layers is limited to lower level libraries and the tools that generate lower level layers automatically from higher ones are of great interest. The concern of mask making and NRE costs is offset by gains in design ""quality"". The investigation and choice of the most appropriate level of abstractions and of the tools that support this design method represents a core part of the GSRC research.

5. Acknowledgements

This paper is the result of many interactions with colleagues. Alberto Ferrari contributed to the first conceptualization of the system-platform stack. Henry Chang and his coauthors were among the first to conceptualize architecture platforms. Felice Balarin and his coauthors were the first to articulate the design process as a sequence of function, architecture and mapping steps. Grant Martin was instrumental in developing the concepts and mapping them in the world of embedded software.

Ted Vucurevich supported the ideas and found terrific ways of exposing the basic principles. Richard Newton contributed to the overarching principle, as did the entire GSRC team. Among the GSRC investigators, Larry Pileggi contributed to the articulation of the Silicon Implementation Platform and helped correct inconsistencies. Wojcieh Maly insisted in pointing out the importance of hardware solutions and of estimation for physical manufacturing processes. Marco Sgroi contributed the notion of Network Platforms.

Gary Baldwyn gave insightful comments and provided much appreciated support. Randy Bryant and Kurt Keutzer provided feedback and useful editorial comments. Luciano Lavagno exposed some early inconsistencies. Jan Rabaey was an important sounding board and provided most helpful comments especially with respect to the PicoRadio design work together with strong support for the effort. Richard Goering offered the space for publication of this document at the EEdesign web site and provided useful editorial comments.

The overall effort can be seen as a summary and a manifesto for the GSRC Research program directed by Richard Newton and sponsored by DARPA and the SIA. The entire effort of the program is be summarized in Figure 9.

Figure 9 - The Overall Methodology (Source: R. Newton)

6. References

Felice Balarin, Massimiliano Chiodo, Paolo Giusto, Harry Hsieh, Attila Jurecska, Luciano Lavagno, Claudio Passerone, Alberto Sangiovanni-Vincentelli, Ellen Sentovich, Kei Suzuki, and Bassam Tabbara, Hardware-Software Co-Design of Embedded Systems: The POLIS Approach, Kluwer Academic Publishers, Boston/Dordrecht/London, 1997.

A. Ferrari, A. Sangiovanni-Vincentelli, System Design: Traditional Concepts and New Paradigms, The Proceedings of the International Conference on Computer Design, ICCD '99, Austin, TX, USA, pp 1-12, Oct. 1999. (Key-note Address)

G. Martin, H. Chang, et al, Surviving the SOC Revolution: A Guide to Platform Based Design, Kluwer Academic Publishers, Sept. 1999.

K. Keutzer, S. Malik, A. R. Newton, J. M. Rabaey, and A. Sangiovanni-Vincentelli, System Level Design: Orthogonalization of Concerns and Platform-Based Design, invited paper, IEEE Transactions on Computer-Aided Design, Vol. 19, No. 12, December 2000.