System Level Design: Orthogonalization of Concerns and Platform-Based Design

1. System Level Design: Orthogonalization of Concerns and Platform-Based Design K. Keutzer, S. Malik, R. Newton, J. Rabaey, and A. Sangiovanni-Vincentelli Presented By: David Nguyen

2. The Cost of System Design • Manufacturing Costs • The material cost of producing the product • Non-Recurring Engineering (NRE) Costs • Designing the product • Ex. Engineers, Testing Equipment • Tooling purchases needed for manufacturing • Ex. Tools, masks

3. How to Make Money? • TotalCost = #Units*ManufacturingCosts + NRE. • Income = #Units * Cost/Unit • Success is Income > TotalCost by balancing • # Units Produced/Sold • Manufacturing Costs per Unit • Non-Recurring Engineering Costs • Price we sell at

4. Problem and Solutions? • Problem: Because of increased pressures (ex. time to market, complexity), making money is harder. How can we cope with this? • Solution: Platform Based Design – Determine a common “hardware denominator” which can be shared across multiple applications. • Reason: The NRE cost is amortized because of the increased number of units (as a result of its use in multiple applications).

5. System Design Methodology – Orthogonalization of Concerns • Orthogonalization of Concerns is the separation of the various aspects of design to allow more effective exploration of alternative solutions. • Function and Architecture • Communication and Computation • Functionality and Timing

6. Function Based Design • A function is an abstract view of the behavior of an aspect of the system. • “display the result” is a function. • “display the result on the LCD display” is NOT a function. • Functional specification should be defined formally and contain a formal underlying mathematical model – model of computation. • This allows us to handle verification via formalism, abstraction, and decomposition. • Formally defined system (with underlying model of computation) gives us the ability to synthesize the functionality.

7. Communication Based Design • Edwards Lee says we should be able to use many models of computation in one system. • The problem is how do we get all of these different components, with different models of computation, talking to each other? • Sol1: Design a communication standard which works for everything (Complex) • Sol2: Design a communication method in a case by case fashion. (Easier)

8. Micro-Architecture • Architecture – an interface specification that describes the functionality of an implementation, while being independent of the actual implementations • X86 instruction set architecture. • Micro-Architecture – defines how the architecture functionality is actually realized as a composition of modules and components, along with their associated software • Intel Pentium 4, AMD Athlon XP

9. Mapping • The functions of the system are assigned (mapped) to the components of the micro-architecture. • Only after this is done, do notions of cost and performance appear. (How fast can I perform my functions and how much will it cost me?) • The result is refined mapped micro-architecture that is guaranteed to meet design constraints or • A mapped micro-architecture that signals something cannot be guaranteed. In this case, we need to either change the micro-architecture used, or make changes in the function space.

10. Link to Implementation • Once the mapping of functions to micro-architecture is deemed as feasible, the micro-architecture is then implemented. • The hardware and software components can be a special purpose design, or already designed in a current library.

11. Platform Based Design • To reduce design costs, reuse is a must! • It is important to find common architectures that can support a variety of applications as well as the future evolution of a given application. • Implementing onto a platform should require little effort in comparison to a totally new implementation. • Platforms • Hardware • Software • System

12. Hardware Platforms • A family of micro-architectures that allow the substantial re-use of software • Hardware Platforms have two constraints • They must be able to support some degree of functionality (minimum speed and memory). • They must meet production and design costs • These two define an application space of supported functionality. • Advocates the “meet in the middle” design approach.

13. Software Platforms • To be useful, a hardware platform has to be abstracted at a level where the application software “sees” a high-level interface to the hardware (API). • With an API defined, the application software can be re-used for every platform instance. • Given the precise definition of the API and the hardware platform, the authors feel like they can synthesize most of the software layer.

14. System Platforms • Combination of the software and hardware platform. • ASV Cones • Vertex is the API • Application Instance is mapped to the API • A Family of micro-architectures implements the APIs with varying costs and performance • Tradeoff between level of abstraction and the diversity of the platform instances.

15. Examples • Philips VideoTop Digital Video Broadcast System • Magneti-Marelli Automotive Engine Control • Testing was done on 3 different CPUs, each with two different software partitions. • Estimations performed in VCC were accurate to about 11% • BWRC InterCom. • Implemented Voice-based protocol stack • Took about 1,200 lines of C-code • A “traditional” implementation with Strong-Arm would take about 30,000 lines (including the RTOS) David Nguyen

16. MESCAL Modern Embedded Systems, Compilers, Architectures, and Languages • The Goal of MESCAL is to develop methodologies, tools, and appropriate algorithms to support the efficient development of fully programmable, platform-based designs for specific application domains.

17. MESCAL Assumption • General purpose programmable solutions will not be likely to meet aggressive performance and power constraints and useful generality. • Domain-specific programmable solutions are required to deliver the benefit of programmability while still delivering acceptable performance. • Network/Video Processors vs. General Purpose processors.

18. Architecture: Specialized Functional Units • Dramatic Speedup in function execution. • MESCAL uses IMPACT EPIC (Explicitly Parallel Instruction Computing) architecture class for individual processing units. • They can better exploit instruction level parallelism (ILP) • This is a powerful mechanism to exploit fine-grained concurrency in a retargetable manner.

19. Architecture: Multiple Levels of Parallelism • Multiple Levels of Parallelism • Instruction Level Parallelism is exploited though an explicitly (EPIC) parallel architecture. • Thread/Process level parallelism through heterogeneous processing and networking.

20. Architecture: Template and Design Methodology • There exists design templates which allow for rapid prototyping of networks of processing elements. • The design methodology utilizes a classic measurement based feedback design loop.

21. Programmer’s Model • The goal of MESCAL Programmer’s Model is to present the programmer with an abstraction of the architecture while helping the compiler generate efficient code for the new architectural platform. • It combines a bottom up and top down approach.

22. MESCAL Compiler • The objective of the MESCAL compiler is to develop a highly optimized, retargetable compiler infrastructure that enables a set of interesting source applications to be efficiently mapped into a family of fully programmable architectures and micro-architectures. • We would like the compiler to automatically synthesize RTOS components, custom components to improve performance, scheduler, device drivers, memory management routines, and other hardware specific code from the machine description. David Nguyen