© s. ramesh / kavi arya / krithi ramamritham 1 it-606 embedded systems (software ) s. ramesh kavi...

1© S. Ramesh / Kavi Arya / Krithi Ramamritham

IT-606Embedded Systems

(Software)

S. RameshKavi Arya

Krithi Ramamritham

KReSIT/ IIT Bombay


Overview of Polis

S. Ramesh


POLIS• Research effort from Univ. of Cal., Berkeley• Alberto Sangiovanni-Vincentelli and his

students• One of the earliest tools for embedded systems

design• Initial ideas in early 1990s• Main motivation from Magneti Marelli,

– 2nd largest European producer of automotive electronic subsystems

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


Design Challenges• difficulty of implementing informal

specifications from clients – safety, drivability, efficient fuel consumption,

controlled emission • problem of chasing continuously changing

specification (car models evolve)• software design problem

– debugging assembly code, hand-written real-time kernel

– verification of timing properties, limited resources


Design Challenges (contd.)• Poor design methodology

– no simulation and extensive bread-boarding– hand-layout of HW– independent development of HW and SW and

integration at the last moment– new designs layered on top of old designs– lack of traceability


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


Design Methodology: POLIS View


Functional Level• System behaviour

– precisely captured using high level models (CFSMs)

– Example: MPEG encoder algorithm, DCT algorithm

• Analysis– Simulation and Formal Verification


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


Mapping• Critical step• mapping of behavior onto candidate

architecture• partitioning and performance analysis• Manual partitioning• Analysis using Ptolemy tool


Architectural Level• Automatic synthesis of HW and SW• Interface synthesis• RTOS function integration• Scheduling and communication• Fast prototyping and back annotation


POLIS Design Flow


Input Translation• Input to POLIS

– Esterel, Extended FSM (FSM with data)– Any language with underlying FSM model

• Input is translated to Co-design Finite State Machines (CFSMs)

• All later steps deal only with CFSMs


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


VM

?coffee(x); x

>a

!Mk_coffee

?read

y

!chan

ge (x

-a);

! Pou

r_co

ffee

?Tea (x); x>b

!Mk_tea

?ready!change (x-b); ! Pour_Tea


User

? tired

! Coffee(z)

? Pou

r_coff

ee! c

ollec

t

? tired! Tea (z)

? Pour_Tea!Collect


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


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


Interaction Example

tea

USER

coffeeTiredidle

pour - coffee

pour - tea

Change

VM


Precise Execution Semantics• CFSMs is the modeling language - has precise

semantics• Scheduler-based execution

– periodically read various inputs– determine runnable CFSMs (ones that can be

executed)– 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


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 of Ptolemy tool


Next Step• Architecture Selection

– Choice of processors, DSP, ASIC,– Library of processors and architectures

available in POLIS• Partitioning of CFSMs• Manual Step


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


Synthesis (contd.)

• Interfacing Synthesis– external world– HW-SW, SW-HW interface

• All these steps are automatic with some user inputs


Interface Synthesis• Involves translating CFSM communication

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

lost• Appropriate protocol required across

different domains• SW - SW communication

– RTOS handles this• HW - HW and HW - Env.

– Simple using a set of wires


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


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 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 emits all 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


HW-SW Interface


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


SW-HW interface


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.


Systems Developed• Many systems• Automotive Applications

– Dashboard product– Engine management unit


POLIS• Free and can be downloaded• Web-address:

– www-cad.eecs.berkeley.edu

© s. ramesh / kavi arya / krithi ramamritham 1 it-606 embedded systems (software ) s. ramesh kavi...

Documents

ramesh slide

cfsms slide

tea slide

sw slide

rtos slide

scheduler slide

event slide

rover slide