| Notes on Platform-Based Design |
TABLE OF CONTENTS (this page is a work in progress!!!!)
| Introduction to Platform-Based Design? |
TUTORIAL OBJECTIVES
The objectives of this tutorial are as follows:
DEFINITION OF PLATFORM-BASED DESIGN
We define platform-based design as:
The goal is to facilitate development of future product generations that are extensions of original hardware and software investments, thereby allowing for dramatically reduced time to market, while decreasing development and production costs.
MOTIVATION, BENEFITS, AND APPROACH
Currently, there is a trend towards to development of applications that are not centered around a single device, but rather families of systems each tailored to specific customer needs. Often, these systems will operate with many other systems.
As systems become more complex, the relative cost of verifying and testing behavior will steadily increase unless new approaches are developed. In the electronics arena (the leader of many trends), this trend is prejuiding manufacturers towards components/subsystems that have guaranteed high-volume production (where the test and verification process can be amoritized more economically). Therefore, we would like to identify a common "hardware and software" denominator (which we will refer to as the "platform") that can be shared across multiple applications. Ideally, future evolutions of these applications will occur with only minimal extensions to functionality.
Challenge. The challenge that we face is providing system designers with the tools to design, evaluate and program these "platform architectures" with appropriate metrics for the "early" evaluation and verification of system performance. System designers must therefore have the capability to specify, manage, and verify the functionality of concurrent behaviors. Reuse is a must.
Both reuse and early error detection imply that the design activity must be defined rigourously so that all phases are clearly defined and appropriate checks are made. To be effective, a design methodology that addresses complex systems must start at high levels of abstraction. This requirement is at odds with current design practice where designers are familiar with working at levels of abstraction that are too close to the final implementation (e.g., requirements written in a way that ties the implementation to a particular technology). As a result, sharing design components (i.e., reuse) and early verification of designs before prototypes are built is nearly impossible.
Trade-Offs in Design Reuse
Design resuse is most effective in reducing development time and and cost when the components and subsystems to be shared are close to the final implementation. There is, of course, a cost to pay for this benefit since it is not alway desirable to share designs at this level. As the design specification becomes progressively more detailed, nominal variations in specification can result in different (albeit almost the same) implementations. If moving to a higher level of design abstraction eliminates these design differences, then the higher level of abstraction can be shared, with perhaps only a minimal amount of work needed to customize the design for the final implementation.
With this framework of development in mind, our long-term research and development goal is to create libraries of hardware and software components and subsystems that can be easily shared and used in new designs. Since the reuse of design abstractions varies with the fidelity of design description, it is important to have miltiple levels of functionality supported in such a library. For example:
These can be shared across product High levels of design abstraction can be shared across product lines and product versions. They have longevity.
These are close to the final implementation and can change with advances in technology.
It is important to start the design process at a high level of abstraction that can be implemented in a wide variety of ways. In this framework, the design and implementation process corresponds to a sequence of steps that remove choice from the formal model (i.e., the abstract representation of the design should contain all of the correct implementations in the sense that behavior of the implementation should be consistent with the abstract model behavior).
------------------------------------------------------------------------------ Role of UML and "Formal Models of Computation" ------------------------------------------------------------------------------
Today -- UML descriptions of component-based design of software systems.
Future -- Promote formal models and transformations in system design so that
verification and synthesis can be applied to the advantage in the methodology.
Verification is effective if complexity is handled through formal
models, abstraction and formalization (Sangiovanni-Vincentelli, 1996).
System-Level Design Methodologies
Currently, too many designers are familiar only with design methodologies that are tied to a technology implementation. To keep the complexity of future developments in check, an essential component of new design methodologies is "orthogonalization of design concerns" (i.e., the separation of various aspects of design that will allow for more efficient exploration of alternative solutions. Two pillars of this approach are:
Mapping Function to Architecture. The mapping of function to architecture is an essential step in the pathway from system conceptualization to implementation. This is where the functions to be implemented are assigned (or mapped) to components of the system architecture. The mapping process determines:
To avoid premature ties to technology and implementation, this mapping needs to take place at a high level of abstraction. Decisions on choice of hardware or software for implementation should occur after the mapping is complete. On the downside, in order to make precise estimates of performance and cost, it is necessary to complete the design (with all of the technology details filled in).
Notions of Function. Notions of function (i.e., system behavior) depend very much on the level of abstraction at with the design is entered. By making design decisions that tie a design to a specific technology (intentionally or not), we are eliminating alternatives from the space of potential design solutions. To avoid the pitfall of eliminating design solutions that may be never uncovered, design decisions should be explicit, and be documented. The description of function/behavior that the system has to implement should use a language that is as formal as possible. That is, formal descritions of system behavior are prefered to semi-formal languages (like UML) which, in turn, are preferred to informal textual descriptions of behavior. Unfortunately, some of these languages lack to semantic constructs to specify concurrency.
| Platform Design and Implementation |
Approaches to Product Family Design
With future systems expected to incorporate more frequently software that works in conjuction with hardware, these methodologies need to support the high-level technology-neutral description of system architectures, followed by co-design of the hardware and software subsystems/modules. For this approach to work, we require that the key components remain constant (within a certain degree of parameterization). Of course, the lower-level details of implementation may vary across the range of applications (e.g., a processor core can be a DSP, a microcontroller, or several of each).
Top-down. A company strategically manages and develops a family of products based on a product platform and its derivatives.
Bottom-Up. A company redesigns or realocates a group of distinct products to standardize components and to improve economies of scale.
The desired result is a methodology for designing modular products that involve identification of modules (from previous generations of products).
The question needs to be asked:
Isn't every design a potential design platform?
In fact, it would be wonderful if it was that easy. But, traditional ASIC design makes swapping out major IP blocks during development extremely difficult, if not impossible, because all of the interfaces to those blocks that are hard coded into the design.
HARDWARE PLATFORMS
Hardware designs are often characterized by over-design (which helps in the extension to future versions). Hardware platforms are designed through a trade-off in a complex space that involves the following factors: -- Determining the size of the constrained application space that can be supported. This represents the flexibility of the hardware platform. -- The size of the architecture space that satisfies constraints in the hardware platform definition. In turn, this defines the range of architecture instances that are possible.
Ideally, the design process starts with the determination of the set of constraints that define the hardware platform for a given application. The design process proceeds by adding missing information on components and communication, estimating performance and costs, and the mapping of functionality to components and communication mechanisms for high- and low-end design options.
Hardware platform design processes support neither top-down nor bottom-up methodologies. Rather, they are a "meet-me-in-the-middle" approach to design.
SOFTWARE PLATFORMS
To be useful, hardware platforms need to be abstracted to a level where applicatios of software see a high-level interface to the hardware. In practice, hardware modules will be wrapped by software interfaces (memory subsystems; I/O subystems via device drivers) that can interact with (programmable) software modules.
SYSTEM PLATFORMS
System platforms support the development of systems that will be implemented using combinations of hardware and software. Their design faces several vexing issues. On a conceptual level:
-- What does it mean to program a complex system efficiently? -- What is the appropriate level of specialization vial programming?
On a physical level, they need development tools to program specialized architectures.
In the design space, there is an obvious trade-off between the level of abstraction in the "programmers model of implementation" and the number and diversity of program instances covered. More specifically:
-- A more abstract programmers model allows for a richer and more diverse set of platform instances. -- But, this increases the "difficulty" in choosing the optimal platform instance and mapping to it automatically.
Hence, in practical terms system platforms supporting mixtures of HW/SW may have reconfigurable architectures defined by a rather small number of component options and customized interfaces that are easy to understand and program.
Techniques for Platform-Based Design
Frames of Reference (see Simpson et al., 2001)
SCALABLE PRODUCT PLATFORMS
If possible, identify parameters that will "stretch" or "shrink" the product faamily to satisfy different customer or market requirements. For example:
We now work step by step through the product platform concept exploration method (PPCEM), which facilitates the synthesis and exploration of a common product platform concept:
Step 1. Create Market Segmentation Grid.
Map overall design requirements into an appropriate market segmentation grid. Identify opportunities for reuse and leveraging:
------------------*-----------------------------------------------
High-end cost *
and performance. *
*
Mid range. *
*
Low-end cost *
and performance. *
*
------------------*-----------------------------------------------
* Market Market Market
* Segment A Segment B Segment C
------------------*-----------------------------------------------
Step 2. Classify Factors and Ranges. Identify:
-- Performance parameters of the system.
-- Design variables that can be freely specified by the designer.
-- Scaling variables: These are design variables around which a
product platform is leveraged either through a vertical
scaling (e.g., length of a component), horizontal scaling (e.g.,
a configurational parameter such as the number of passengers on
a plane), or combination of horizontal and vertical scalings.
Step 3. Build and Validate Metamodels
Build computationally inexpensive-to-run metamodels (e.g., design response surfaces) of computationally expensive computer analyses or simulation codes.
Step 4. Aggregate Product Platform Specifications
Using information from the market segmentation grid, and factors and ranges identified at step 2, aggregate the product platform specifications by identifying goals that will bring the mean performance on target and minumize variations.
This requires formulating a multi-objective mathematical programming problem .....
Step 5. Develop Product Platform
Applications
Example: Conceptual Design for a Family of Universal Motors ..... see Simpson et al., 2000. pg's
| Lessons Learned from Industry Platforms |
Experience 1. We estimate that each platform can lead to four or five products per year and, frequently, ten or more products over the lifetime of the platform. In fact, now that we have developed so much experience with platform-based design, we are able to assemble a digital consumer platform in less than a week using existing IP.
Experience 2. The first platform we developed using our current base of tools was the UPP (Universal Processor Phone) for mobile phones. This platform included the ST100 DSP megacell, modeled at the bus-cycle accurate level. We used our internally developed AVP (Architecture Validation Platform) to make sure our high-level abstraction was correct. Then we refined the model until we had a complete and fully synthesized hardware base for our platform.
Clearly, design platforms aren't just for mobile phones. We are using platform-based design techniques for a wide range of wireless and wireline devices and consumer products, including digital television, DVD players, and set-top boxes. In the past year, we have developed many platforms using a variety of processors (for example, the ARM7, ST20, ST40, DSP950, and MMDSP) and our platforms have become quite complex-a recent set-top box design employed five CPUs. We fully expect platforms to extend into an even wider range of applications in the coming months and years.
Separation of Communications from Block Functionality. Our design methodology helps to solve this problem by separating the communications interfaces from the functionality of the IP blocks. When designing a platform, we generate the appropriate hardware interfaces using the interface synthesis capabilities of CoWare N2C, as well as the software interfaces to the hardware (for instance, the memory maps for registers and the software drivers). This makes swapping out one piece of IP an easier process and also allows designers to evaluate the potential of one piece of IP in a design versus another.
| Research and Development |
Defining Blocks. To create a repeatable process for development of a platform, we did more than assemble a toolkit; we standardized our design flow into one that allows us to define blocks at different abstraction levels (see Figure 2). As we progress along in our design, we simulate with a mix of abstraction level, dynamically using the same C testbench for the high-level and low-level models, which helps to ensure design consistency and accuracy.
Currently, our platform-based design flow is based on CoWareC and includes the following:
- Untimed level (UT)
- Bus-cycle-accurate shell level (Bcash)
- Bus-cycle accurate (BCA)
- Register-transfer C level (RTC), which is similar to RTL in VHDL or Verilog.
At the highest level, untimed, we're evaluating the functionality of the design. A processor hasn't yet been selected. Functional simulation verifies the interaction of the hardware and software algorithms.
At the Bcash level, we can get a cycle-accurate shell to model against the software. Here we pick a processor and use performance modeling to evaluate the speed of the execution code on the ISS (instruction set simulator). We can also evaluate the effects of the bus traffic on the overall performance. For example, if something doesn't meet performance goals in software, we can target that module to hardware.
Next, we incrementally move hardware BCA models into RTC descriptions. We synthesize the software drivers and hardware interfaces to speed the process. Synthesized components can include address decoding, interrupt priority encoding, arbitration units, memory mapped registers, program and data memory and controllers, interrupt service routines, boot code, methods to access memory mapped registers, and more. The result is a plug-and-play method that enables the rapid creation of many derivatives.
We also perform an RTC to VHDL (or Verilog) conversion (using CoWare N2C), but only a limited set of RTC constructs are converted in the process. To counter this tendency, we developed RTC analyzer tools to identify potential problem areas in the VHDL code and to set general design rules for the conversions. This allows us to eliminate a number of problems without costly co-simulations, which are much more time consuming in VHDL than in RTC.
After the RTC-to-VHDL translation, the VHDL code is co-simulated with an existing HDL simulator (VSS, Leapfrog, Modelsim, IKOS) or the code is co-emulated with Celaro to verify the HDL behavior.
Customer Platforms. So far, we discussed platform-based design from the standpoint of a design platform creator. But, it's also important to understand how our customers use the platforms we create. What we give them is a base they can expand upon. Everything in the base has been thoroughly tested so that we are confident that the software development tools work and the hardware works.
Now it remains for the customer to differentiate the platform for a particular application by building on the platform and synthesizing the interfaces between the base platform hardware and other hardware and software elements that need to be added. Hardware- hardware interface synthesis allows extensible platforms to be created with very limited knowledge of the functional specification. Generating a detailed application-programming interface (API) is also important in order to map embedded software to the target processors. This API consists of header files giving a comprehensive and clear link to the platform's memory map, and makefiles to help the software developer compile his program to the target processor correctly.
Just a few years ago, system-level design was very new; the technology wasn't a standard part of our design strategy. We had a solution that we kludged together for co-simulation involving VHDL and functional C. We often ran into problems with mismatches between the software drivers and the silicon if they weren't properly verified beforehand. At that time, we used Seamless from Mentor Graphics (Wilsonville, OR) and Synopsys' (Mountain View, CA) Eaglei. However, these functions are now included in the CoWare N2C tool.
The productivity improvements gained from platform-based design have had a major impact on our company. We're able to start software designs much earlier in the design process. In addition, the process allows us to quickly verify that our silicon will be functionally and architecturally correct. Also, we're successfully reusing major components throughout the organization; our product groups are now organized by application and include a library group charged with the task to generate reusable IP. Finally, we are able to accommodate many projects progressing in parallel and because we can do more, we've hired more people.
This is not to say that our process is perfect. We still worry about big, complex middleware like Windows CE on a set-top box. Windows CE is so complex that it can take a half-hour just to boot in simulation. So, among the many things on our wish list, we include an emulator powerful enough to run the core at hardware speed. This is why ST is pushing so hard to get a standard SCE-API (sales configuration engine-application programming interface) from all the vendors to build a decent solution. However, the technology is maturing rapidly, and we fully expect that our platform-based design process will continue to change and improve significantly with time.
Product-Based Design Enhances Productivity.
There's a buzz in the industry around platform-based design (PBD). In recent articles and announcements from processor, operating-system, software, intellectual-property (IP) and tools vendors, PBD features prominently. As with most new or proposed design philosophies, it can be difficult to distinguish reality from hype. So it is worthwhile looking at what a PBD design methodology entails.
As the name suggests, this design philosophy allows the user to build and configure a system-on-chip (SoC) design around a stable core platform and connect using standard buses. This is not a new philosophy-system integrators have been doing this for years with VME racks. As processors become more complex, it is quicker and more accurate to buy expertly designed processor boards, allowing the design team to focus on the unique aspects of the design that create the most value and differentiation. These same factors are emerging for SoC design.
The new generation of processors used in SoC designs have increased in complexity to the extent that ensuring optimal design of the surrounding logic is key to achieving the maximum processor performance. To assist the design groups, processor vendors are now beginning to supply configurable designs that include memory and many common peripherals optimized for use with the processor core, and some standard connection ports onto which additional user-designed logic can be quickly added. For example, OKI Electric Industry Co. Ltd., a developer of high-end solution platforms, claims a substantial increase in designer productivity by using its microPlat design.
"Our customers have to spend a lot of time and resources optimizing the design around the processor to ensure maximum processor performance and functionality-even though this is not the most important part of their design. Now, we have created a complete, optimized processor subsystem to allow our customers to deploy instantly a highly optimized solution around which their embedded designs can be created with confidence," said Masasuke Kishi, general manager of OKI's silicon platform architecture department.
Remaining with the VME analogy, the emergence of hierarchical, efficient SoC bus standards (ARM's Amba, IBM's Core Connect) has encouraged processor vendors to adopt these as standard buses for their processor subsystems. In addition, many IP providers have begun to supply IP with processor interfaces conforming to these standards. For example, Mentor Graphics' IP business unit, Inventra, now supplies its USB design with an Amba advanced high-performance (AHB) interface.
The adoption of standard high-performance buses by IP vendors has been triggered by a third important factor in the emergence of platform-based design. The leading-edge commercial IP has reached new levels of design complexity. For instance, many of the new Bluetooth modules now being incorporated into SoC designs are processor-based designs in their own right.
The increased data-processing capabilities require efficient data-transfer mechanisms to ensure efficient system integration. As IP capabilities and complexity continue to rise, we can expect to see increased use of complex bus standards to facilitate rapid and efficient system integration.
PBD is not a methodology to achieve a complete SoC design. Instead, it allows the processor-centric part of the system to be created, configured and verified quickly. This allows the design team to focus on the creation of the differentiated, value-added parts of the design. The potential productivity gains available by adopting PBD do not result in a complete change in the EDA tool chain; however, there will be a noticeable change of emphasis.
Design capture is more akin to joining building blocks together rather than traditional schematic or language capture.
| References and Web Resources |
REFERENCES
WEB RESOURCES
Unified Modeling Language (UML)
GLOSSARY OF TERMS
Product Family. A group of related products that share common features, components and subsystems, but may be customized to satisfy a variety of market niches. A product family comprises:
-- A set of variables, features or components that remain constant from
product to product (i.e., this is the product platform), and
-- Other variables, features or components that vary from product to
product.
Product Platform. The set of parameters (common parameters), features or components that remain constant from product to product.
Scaling Variables. Design variables that vary from product to product and can "stretch" or "shrink" members of the product family.
Scale-based Product Family. Product family in which features change from product to product through different values of the scaling variables.
Developed in April 2001 by Mark Austin
Copyright © 2001, Mark Austin, University of Maryland