it 606 ramesh l7

7/29/2019 IT 606 Ramesh L7

1/35

S. Ramesh / Kavi Arya/ Krithi Ramamritham 1

IT-606

Embedded Systems(Software)

S. Ramesh

Kavi Arya

Krithi Ramamritham

KReSIT/ IIT Bombay

7/29/2019 IT 606 Ramesh L7

2/35


Overview of Polis

S. Ramesh

7/29/2019 IT 606 Ramesh L7

3/35


POLIS

Research effort from Univ. of Cal., Berkeley

Alberto Sangiovanni-Vincentelli and hisstudents

One of the earliest tools for embedded systems

design Initial ideas in early 1990s

Main motivation from Magneti Marelli,

2nd largest European producer of automotiveelectronic subsystems

World-wide clients: Fiat, Mercedes Benz,Volkswagen, Renault, Rover

7/29/2019 IT 606 Ramesh L7

4/35


Design Challenges

difficulty of implementing informal

specifications from clients safety, drivability, efficient fuel consumption,

controlled emission

problem of chasing continuously changingspecification (car models evolve)

software design problem

debugging assembly code, hand-written real-time kernel

verification of timing properties, limited

resources

7/29/2019 IT 606 Ramesh L7

5/35


Design Challenges (contd.)

Poor design methodology

no simulation and extensive bread-boarding

hand-layout of HW

independent development of HW and SW andintegration at the last moment

new designs layered on top of old designs

lack of traceability

7/29/2019 IT 606 Ramesh L7

6/35


Model-Based approach

Polis is one of the earliest to suggest this

Polis Modeling Language: Codesign Finite

State Machine (CFSM) models

Focus on control dominated applications Embedded System Architecture

Micro-Processor/Micro controllers

DSP

Peripherals and Std. Components

SW and RTOS

7/29/2019 IT 606 Ramesh L7

7/35


7/29/2019 IT 606 Ramesh L7

8/35


Design Methodology: POLIS View

7/29/2019 IT 606 Ramesh L7

9/35


Functional Level System behaviour

precisely captured using high level models

(CFSMs)

Example: MPEG encoder algorithm, DCT

algorithm

Analysis

Simulation and Formal Verification

7/29/2019 IT 606 Ramesh L7

10/35


Architecture Selection

A class of physical components selected

32 bit or 16 bit microprocessor, RISC, CISC

DSP

Interconnection scheme May come from existing IP library or

models to be custom-designed

7/29/2019 IT 606 Ramesh L7

11/35


Mapping

Critical step

mapping of behavior onto candidate

architecture

partitioning and performance analysis Manual partitioning

Analysis using Ptolemy tool

7/29/2019 IT 606 Ramesh L7

12/35


Architectural Level Automatic synthesis of HW and SW

Interface synthesis

RTOS function integration

Scheduling and communication

Fast prototyping and back annotation

7/29/2019 IT 606 Ramesh L7

13/35


POLIS Design Flow

7/29/2019 IT 606 Ramesh L7

14/35


Input Translation

Input to POLIS

Esterel, Extended FSM (FSM with data)

Any language with underlying FSM model

Input is translated to Co-design Finite StateMachines (CFSMs)

All later steps deal only with CFSMs

7/29/2019 IT 606 Ramesh L7

15/35


CFSMs

Collection of Extended Finite State Machines

Extended Finite State Machines FSM + variables

Variables have finite range

Transition labels: b, e / A b - boolean expression over variables and signal

values

e - boolean expression over input signals A - Actions: assignment and signal emisson

Signal presence detected and values read

Atomic transitions

7/29/2019 IT 606 Ramesh L7

16/35


VM

7/29/2019 IT 606 Ramesh L7

17/35


User

7/29/2019 IT 606 Ramesh L7

18/35


Interacting Machines

The CFSMs interact with each other by

means of events Many similarities with Esterel communication

Sender generates an event (possibly with

values) Receiver senses the presence of events

Single sender and multiple receivers

Sender generates irrespective of receiver Multiple sends erase the old value

one-place buffer

Receiver consumes the event

7/29/2019 IT 606 Ramesh L7

19/35


CFSM Interaction

Many differences with Esterel

CFSMs are asynchronous

The receiver and sender not synchronized

They have distinct clocks Receiver and sender transitions take place at

different times

No assumption on the delay One may be in HW and the other in SW

7/29/2019 IT 606 Ramesh L7

20/35


Interaction Example

tea

coffeeTired

idle

pour - coffee

pour - tea

Change

7/29/2019 IT 606 Ramesh L7

21/35


Precise Execution Semantics CFSMs is the modeling language - has precise

semantics Scheduler-based execution

periodically read various inputs

determine runnable CFSMs (ones that can beexecuted)

schedule them in some order (user specifiable)

input status does not change when a CFSM executed

Atomic Transitions

control returns when no change in status

Time passes when control is with the scheduler

7/29/2019 IT 606 Ramesh L7

22/35


Verification of CFSMs Precise semantics enable analysis

Functional Verification Simulation

Formal Verification Property verification

State-space analysis

Timing Verification possible mapping information and time estimates of various

transitions easier to make as transitions are st.line code

System Co-simulation

use ofPtolemy tool

7/29/2019 IT 606 Ramesh L7

23/35


Next Step

Architecture Selection

Choice of processors, DSP, ASIC,

Library of processors and architectures

available in POLIS

Partitioning of CFSMs

Manual Step

7/29/2019 IT 606 Ramesh L7

24/35


Synthesis

HW synthesis

Translation of CFSMs to netlist

Standard synthesis tools

Synthesis to FPGAs possible SW synthesis

C - code from CFSMs

application specific RTOS scheduler, I/O driver

7/29/2019 IT 606 Ramesh L7

25/35


Synthesis (contd.)

Interfacing Synthesis external world

HW-SW, SW-HW interface

All these steps are automatic with some

user inputs

7/29/2019 IT 606 Ramesh L7

26/35


Interface Synthesis

Involves translating CFSM communication

across different implementation domains Need to be done with care - signals may get

lost

Appropriate protocol required acrossdifferent domains

SW - SW communication

RTOS handles this

HW - HW and HW - Env.

Simple using a set of wires

7/29/2019 IT 606 Ramesh L7

27/35


Interface Synthesis

Envn. - SW and HW - SW:

Request - Acknowledge protocol

Events received by the RTOS

Polling/Interrupt

Envn. - HW, SW - Envn., SW - HW:

Uses an edge detector to translate a pulse(lasting more than one cycle) to the one cycle

per event HW protocol

7/29/2019 IT 606 Ramesh L7

28/35


SW to SW For every event, RTOS maintains

global value, local flags

Local flags indicate to each SW-CFSM, that

the event is present

Then the SW-CFSM fetches the value from

the global one

Flag reset once the value is accessed Atomicity problem

Use two copies of flags: active and frozen

During the reaction use frozen flags

HW W

7/29/2019 IT 606 Ramesh L7

29/35


HW to SW Events can be polled or drive an interrupt

For polled event: allocate I/O port bits for status, value and

acknowledge

generate the polling task that acks and emitsall the occurred events

For events driving an interrupt

Allocate I/O port bits for value

Allocate an interrupt vector

Create a service routine that emits the event

7/29/2019 IT 606 Ramesh L7

30/35


HW-SW Interface

7/29/2019 IT 606 Ramesh L7

31/35


SW to HW

Allocate I/O port bits for value and status Write value to I/O port

Create a pulse on the status flag

7/29/2019 IT 606 Ramesh L7

32/35


SW-HW interface

7/29/2019 IT 606 Ramesh L7

33/35


RTOS Event Handler: Between SW-CFSMs and

across different domains Polling tasks, interrupt service routines, data

structures for each SW-CFSM port allocation

etc.

Scheduler: Schedule different SW-CFSMs

Different scheduling algorithms:

Round-robin, priority-based, preemptive or not

RMA, EDF etc.

7/29/2019 IT 606 Ramesh L7

34/35


Systems Developed

Many systems

Automotive Applications

Dashboard product

Engine management unit

7/29/2019 IT 606 Ramesh L7

35/35

POLIS

Free and can be downloaded

Web-address:

www-cad.eecs.berkeley.edu

it 606 ramesh l7

Documents