Defining platform-based SoC design
01 June 2007
Design problems have pushed IC and system companies away from full-custom design methods towards designs that can be assembled quickly from pre-designed and pre-characterised components
This has translated into a high-priority on design reuse, correct assembly of components, fast and efficient compilation from specifications to implementations, correct-by-construction methodologies and fast/accurate verification.
Although the concept of platform-based design has been around for years, there has been no real consensus on the definition of what it means.
There are basically two tenets of a platform-based design methodology. The first is the identification of design as a ‘meeting-in-the-middle process’ where successive refinements of specifications meet with abstractions of potential implementations. The second is 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 at the present layer of abstraction.
From this it is possible to generally define a platform as an abstraction layer in the design flow that facilitates a number of possible refinements into a subsequent abstraction layer. Several types of platform can be defined: architecture platforms, API (application programme interface) platforms, system platform-stacks, the silicon implementation platform stacks, and network platforms.
Architecture platforms
ICs used for embedded systems will most likely be developed as an instance of a particular 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 optimising design time. Every element of the family can be obtained quickly by personalising an appropriate set of parameters that control the micro-architecture. For example, the family may be characterised by the same programmable processor and the same interconnection scheme, but the peripherals and the memories may be selected from a pre-designed library of components, depending on the application.
The less constrained the platform, the more freedom a designer has in selecting an instance and the more potential there is for optimisation, if time permits. However, more constraints mean stronger standards and easier addition of components to the library that defines the architecture platform (as with PC platforms). The basic concept is similar to the cell-based design layout, where regularity and the reuse of library elements speeds design time at the expense of optimality.
The higher the granularity of the library, the more leverage there is in shortening the design time. Given that the elements of a library are reused, there is a strong incentive to optimise them. It also makes sense to offer a variation of cells with the same functionality but with implementations that differ in performance, area and power dissipation.
API platform
The concept of an architecture platform alone is not enough to achieve the appropriate level of application software reuse. The architecture platform has to be abstracted at a level where the application software ‘sees’ a high-level interface to the hardware called the API (application program interface) or programmers’ model.
A software layer that wraps the essential parts of the architecture platform is used to perform this abstraction. These are the programmable cores and the memory subsystem via an RTOS, the I/O subsystem via the device drivers and 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.
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 reused for every platform instance.
The system platform stack is a comprehensive model that includes the view of platforms from both the application and the implementation points of view. It combines platforms and the tools that map one abstraction into the other. 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.
A system designer will map the application into the abstract representation that ‘includes’ a family of architectures that can be chosen to optimise cost, efficiency, energy consumption and flexibility. This can be carried out, at least in part, automatically if an appropriate set of software tools for software synthesis, RTOS synthesis, devicedriver synthesis is available.
Silicon implementation
The silicon implementation platform (SIP) stack is the stack from architecture to actual physical implementation. It takes the components of the architecture platform and maps them to a physical implementation. It identifies a set of abstractions that are related by mapping methods. In addition, it exports to the physical implementation the view of platform stack that includes 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 (see figure 2).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 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.
The final stack on the path to implementation and manufacture is the mask set and the recipes for manufacturing. For deep sub-micron technologies this is particularly important 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, former physical second-order effects such as crosstalk and power distribution are also very important for the performance of the design. These must be handled via regular design structures that facilitate correct-byconstruction assembly and accurate abstraction to the higher platform layers. Clearly, estimation, characterisation, cost functions and constraint passing are all essential components in the design flow when considering the final implementation of the architecture platform instance. The manufacturing interface, once taken for granted, is now a critical step in controlling and predicting cost, performance and reliability. Models 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.
The motivation to develop a platform-based approach to design is reuse and regularity. The components of a platform are in general partially or completely pre-designed and the upper layer is used to decouple the ‘application’ from the implementation of the platform. The platform concept can be extended to cover all steps of design from conception to implementation. The tools and methods, which map the upper and lower layers of a platform-stack, are the glue that keeps the platforms together. A platform stack could spans several levels of abstraction of a design. To be able to choose efficiently the instances of the platform, the constraint propagation process in the topdown aspect of the design needs to be dealt with, while an annotation mechanism that can be associated to the top levels of abstraction to capture lower level details is also needed.
MASSIMO VANZI is CEO, Accent
Contact Details and Archive...
Related Articles...
Most Viewed Articles...