Architecting embedded microsystems
This presentation is the property of its rightful owner.
Sponsored Links
1 / 22

Architecting Embedded Microsystems PowerPoint PPT Presentation


  • 68 Views
  • Uploaded on
  • Presentation posted in: General

Architecting Embedded Microsystems. Building smart, adaptive and efficient systems for networked applications Rajesh K. Gupta Department of Computer Science and Engg. University of California, San Diego http://www-cse.ucsd.edu/~gupta. Graphics Controller. Cellphone Baseband.

Download Presentation

Architecting Embedded Microsystems

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Architecting embedded microsystems

Architecting Embedded Microsystems

Building smart, adaptive and efficient systems for networked applications

Rajesh K. Gupta

Department of Computer Science and Engg.

University of California, San Diego

http://www-cse.ucsd.edu/~gupta


Semiconductor system chips

Graphics Controller

Cellphone Baseband

Semiconductor “System Chips”

  • Trend 1: Process technology migration to CMOS

    • relentless digitization of signals and systems

  • Trend 2: increasing use of “embedded intelligence”

    • variety of (multiple) compute engines available on-chip

  • Trend 3: Networking of embedded intelligence

    • multiple comm. front-ends, networking available on-chip

  • The consequence:

    • smart “spaces”, intelligent interfaces, sensor networks

    • Integrated circuit chips are driving capability increases with cost reductions.


Integrated circuit system design

“Real” Component

“Virtual” Component

Integrated Circuit & System Design

Board-on-chip does not work!

  • Silicon systems engineering: needs a framework for architectural design, subsystem tradeoffs


Soc challenges opportunities

SOC Challenges & Opportunities

  • Inferior CMOS components compared to discrete counterparts using bipolar, GaAs technologies

  • Power, size, bandwidth limitations for on-chip

  • Need an extremely tight control of chip, package parasitic effects on on-chip signals

  • And yet the system-level capabilities and performance due to

    • architectural design that is less sensitive to device/technology limitations

    • system optimizations that include the entire software, networking (and even communications) stack

  • The requires ability to carry out the architectural design and exploration for SOCs


Systems engineering for socs

Systems Engineering for SOCs

Example Problem: How to achieve high throughput in a SOC for wireless applications?

  • Can select a modem sub-system

    • that packs more bits/Hz, but it will tolerate less noise and be less robust so that link throughput may not improve

  • Can increase transmit power in RF subsystem

    • to improve robustness but this increases energy cost, reduces network capacity, and requires more expensive analog circuits (power amps)

  • Can reduce bits/frame

    • to tolerate higher bit error rates (BER) and provide more robustness, but this may increase overhead and queuing delays

  • Can increase precision in digital modem

    • to reduce noise, but this leads to wider on-chip busses and more power consumption

  • The design technology must support right sub-system option and parametric determination.


Platform based design

Platform Based Design

  • A platform is a realized design pattern

    • provides a well-defined abstraction of the underlying architecture for the application developer

    • a restriction on the implementation space, captures good solutions

    • uses components and their reuse within architectural constraints

  • IP design needs a framework consisting of

    • component libraries, composition glue, validation, synthesis

    • complete system simulations, composability and reuse

  • Key elements for composability

    • identification of useful models of computation

      • FSMD, DE, DF, CSP, ..

    • a flexible, extensible language platform for capture

    • Component Composition Framework (CCF)


Balboa component composition

System designer

Interpreted

Component

Integration, CIL

Split-Level

Interface/BIDL

Compiled

C++, SystemC

BALBOA Component Composition

  • A layered development and runtime environment

    • Functionality: describe & synthesize

    • Structure: capture & simulate

  • Use an interpreted language for

    • Architecture description

    • Component integration

  • Use compiled models for

    • behavioral description, simulation

  • Automatically link the two domains

    • through a “split-level” interface

  • Automatic code “wrapper” generation

    • for component reuse.

      Software architecture that enables

    • composition of structural and functional info.

    • type inference for polymorphic ports

    • modeling of the application and the platform


Definitions

Definitions

  • Component:

    • A unit of re-use with an interface and an implementation

  • Meta-information:

    • Information about the structure and characteristics of an object

  • Reification:

    • A data structure to capture the meta-information about the structure and the properties of the program

  • Reflection:

    • An architectural technique to allow a component to provide the meta- information to himself

  • Introspection:

    • The capability to query and modify the reified structures by a component itself or by the environment

5 ports

adder


Balboa language run time

Introspection

SLI/Type system extension

Reflection

BALBOA Language & Run-time

Language

Tools

Run-time structure

CIL

Interpreter

BIDL

BIDL

Compiler

Split Level

Interfaces

GCC

C++

Compiled

objects

GCC


Introspective interfaces for analysis

Introspective Interfaces for Analysis


Design example adaptive cache controller

Design Example: Adaptive Cache Controller


Cil script example

#load the AMRM component library

load ./libamrm.so

Entity mem_sys

Cache mem_sys.L1

Memory mem_sys.Mem

Queue mem_se.r_q

L1.upper_request link_to ms.r_q

Mem.request_in link_to ms.r_q

Tb add_stimuli 100 read 0x399

Tb add_tcl_callback ms.r_q.activity { simulator.do_something; }

simulator run 200

CIL Script Example


Design example cache controller

Number of C++ classes

Number of CIL lines

Number of BIDL line

IP vs Generated C++ code size ratio

7 C++

< 30

60

812/809

(1.01)

8 C++

with SystemC

< 40

84

1512/1002

(1.51)

7 C++

with SystemC

< 150

87

1437/880

(1.63)

Design Example: Cache Controller

Manipulate only the script!

Script size vs C++ ratio: 1 is to 10


Composition framework

Composition Framework

  • Dynamically adapt, control and debug complete system models

    • Using “script-like” interfaces and mixed compiled and interpreted programming components

    • Component introspection through the reflection enables IP reuse

  • Create “Virtual” System Architectures

    • Include application and system software in the model

  • Exploit full potential of SOC architectural platforms

    • by exploring runtime system services suitable for SOC applications

    • example: dynamic power management


Virtual system architectures

Co-simulation

libraries

HW wrapper

libraries

Simulator

libraries

Processor

libraries

Channel

libraries

Protocol

libraries

Virtual System Architectures

Extended

SystemC

Virtual Architecture

OS libraries

APIs

Custom OS

Generation

HW Wrapper

Generation

Communication

and System

Services

RTL Architecture

Device

Drivers

RTL Synthesis

and Compilation

Co-simulation

Wrapper Generation

Executable

Co-simulation

Model

Emulation platform

Cesario, et al, IEEE D&T 11/02


Os directed power management for socs

OS-directed Power Management for SOCs

  • Significant opportunities in power management lie with application-specific “knobs”

    • quality of service, timing criticality of various functions

  • Collaboration between applications and the OS in setting “energy use policy”

    • OS helps resolve conflicts and promote cooperation

  • The enable OS-directed dynamic power management, we need:

    • OS should incorporate application information in DPM policy

    • OS should expose power state and events to applications for these to adapt.


Power aware software architecture

Power Aware Software Architecture

  • PA-API (Power Aware API)

    • interfaces applications and OS making the power aware OS services available to the application writer.

  • PA-OSL (Power Aware Operating System Layer)

    • implements modified OS services and active components such as a DPM manager.

  • PA-HAL (Power Aware Hardware Abstraction Layer)

    • interfaces OS and Hardware making the power control knobs available to the OS programmer.


Current status

Current Status

  • API available from http://www.ics.uci.edu/~cpereira/pads

  • Implementation on eCOS RTOS and

    • Hardware platforms we are currently working with:

      • Linux-synthetic (emulation of eCos over Linux - debugging purposes only)

      • Compaq iPaq Pocket PC - StrongARM SA1110 based platform

      • Accelent IDP (Integrated Development Environment) - also StrongARM SA1110 based.

      • LRH Intel evaluation board 80200EVB - Intel Xscale2 based


Os directed dvs results

Task

Application

WCET (us)

Std Dev (us)

T1

MPEG2 (wg_gdo_1.mpg)

30700

3100

T2

MPEG2 (wg_cs_1.mpg)

26300

2100

T3

ADPCM

9300

3300

T4

FFT

15900

0

T5

FFT (gaussian distribution)

13600

800

OS-directed DVS Results


Using application level knob

Using Application-level “knob”

  • Example: Image Compression Algorithm

    • tradeoff image quality against energy available by varying the compression parameters such as BPP (bits per pixel)

    • The image compression algorithm is ran in a continuous loop with battery polling every 10 secs.

    • A simple power tradeoff policy is added to adapt the quality of the image against the battery voltage left.

    • Whenever the battery drops 30mV the application adjusts the image BPP by -0.5 starting at 1.5.

    • For a cut-off of 4020mV, the battery life is extended from 290 seconds to 340 seconds.


Summary computers with radios are leading to new spaces

Instrumented

wide-area spaces

Internet end-points

In-body, in-cell, in-vitro spaces

Personal area spaces

Summary: Computers with Radios are Leading to New “Spaces”

  • Generational shift in computing devices

    • lot more of everything: computing, networking, communications

    • lot less of power, energy, volume, weight, patience

    • Application is everything, the possibilities are limitless

  • System architectures are due for an overhaul

    • the architectures are (radically) changed/challenged

    • the programming context is changed

    • the system software contract is changed

      • new awareness: location, power, timing, reactivity, stability

power


Soc architectural design paradigms

The IP Basket

The Planned Community

“Organically grown”

The sacrificial altar

Engineered

Specialized

Ambitious (and never finished)

SOC Architectural Design Paradigms


  • Login