IT606 Embedded Systems Software S Ramesh Kavi Arya

IT-606 Embedded Systems (Software) S. Ramesh Kavi Arya Krithi Ramamritham KRe. SIT/ IIT Bombay © S. Ramesh / Kavi Arya / Krithi Ramamritham 1

Overview of Polis S. Ramesh © S. Ramesh / Kavi Arya / Krithi Ramamritham 2

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 1990 s • Main motivation from Magneti Marelli, – 2 nd largest European producer of automotive electronic subsystems • World-wide clients: Fiat, Mercedes Benz, Volkswagen, Renault, Rover © S. Ramesh / Kavi Arya / Krithi Ramamritham 3

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, handwritten real-time kernel – verification of timing properties, © S. Ramesh / Kavi Arya / Krithi Ramamritham 4

Design Challenges (contd. ) • Poor design methodology – no simulation and extensive breadboarding – 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 © S. Ramesh / Kavi Arya / Krithi Ramamritham 5

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 © S. Ramesh / Kavi Arya / Krithi Ramamritham 6

© S. Ramesh / Kavi Arya / Krithi Ramamritham 7

Design Methodology: POLIS View © S. Ramesh / Kavi Arya / Krithi Ramamritham 8

Functional Level • System behaviour – precisely captured using high level models (CFSMs) – Example: MPEG encoder algorithm, DCT algorithm • Analysis – Simulation and Formal Verification © S. Ramesh / Kavi Arya / Krithi Ramamritham 9

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 © S. Ramesh / Kavi Arya / Krithi Ramamritham 10

Mapping • Critical step • mapping of behavior onto candidate architecture • partitioning and performance analysis • Manual partitioning • Analysis using Ptolemy tool © S. Ramesh / Kavi Arya / Krithi Ramamritham 11

Architectural Level • • • Automatic synthesis of HW and SW Interface synthesis RTOS function integration Scheduling and communication Fast prototyping and back annotation © S. Ramesh / Kavi Arya / Krithi Ramamritham 12

POLIS Design Flow © S. Ramesh / Kavi Arya / Krithi Ramamritham 13

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 © S. Ramesh / Kavi Arya / Krithi Ramamritham 14

CFSMs • Collection of 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 © S. Ramesh / Kavi Arya / Krithi Ramamritham 15

VM off ee dy !P ou r_c ); ? re a x-a ea dy ); e( ? r -b (x ou !P an g e a Te r_ !ch b x> ); (x a ng ha !c !M k te o c _ a ? c k_ f f o e e ff !M ( e e e ? T ; ) x a > x © S. Ramesh / Kavi Arya / Krithi Ramamritham 16

User ou ! c r_co oll ec ffee t ? P ? ed tir e e f f Co ) z ( a Te ) (z ! ? t ! ? d e ir Po ur ea ct lle o !C _T © S. Ramesh / Kavi Arya / Krithi Ramamritham 17

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 © S. Ramesh / Kavi Arya / Krithi Ramamritham 18

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 © S. Ramesh / Kavi Arya / Krithi Ramamritham 19

Interaction Example tea Tired U S E R coffee pour - tea V M idle Change © S. Ramesh / Kavi Arya / Krithi Ramamritham 20

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 © S. Ramesh / Kavi Arya / Krithi Ramamritham 21

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 © S. Ramesh / Kavi Arya / Krithi Ramamritham 22

Next Step • Architecture Selection – Choice of processors, DSP, ASIC, – Library of processors and architectures available in POLIS • Partitioning of CFSMs • Manual Step © S. Ramesh / Kavi Arya / Krithi Ramamritham 23

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 © S. Ramesh / Kavi Arya / Krithi Ramamritham 24

Synthesis (contd. ) • Interfacing Synthesis – external world – HW-SW, SW-HW interface • All these steps are automatic with some user inputs © S. Ramesh / Kavi Arya / Krithi Ramamritham 25

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 © S. Ramesh / Kavi Arya / Krithi Ramamritham 26

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 © S. Ramesh / Kavi Arya / Krithi Ramamritham 27

SW to SW • For every event, RTOS maintains – global value, local flags • Local flags indicate to each SWCFSM, 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 © S. Ramesh / Kavi Arya / Krithi Ramamritham 28

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 © S. Ramesh / Kavi Arya / Krithi Ramamritham 29

HW-SW Interface © S. Ramesh / Kavi Arya / Krithi Ramamritham 30

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 © S. Ramesh / Kavi Arya / Krithi Ramamritham 31

SW-HW interface © S. Ramesh / Kavi Arya / Krithi Ramamritham 32

RTOS • Event Handler: Between SWCFSMs and across different domains – Polling tasks, interrupt service routines, data structures for each SWCFSM port allocation etc. • Scheduler: Schedule different SWCFSMs – Different scheduling algorithms: • Round-robin, priority-based, preemptive or not © S. Ramesh / Kavi Arya / Krithi Ramamritham 33

Systems Developed • Many systems • Automotive Applications – Dashboard product – Engine management unit © S. Ramesh / Kavi Arya / Krithi Ramamritham 34

POLIS • Free and can be downloaded • Web-address: – www-cad. eecs. berkeley. edu © S. Ramesh / Kavi Arya / Krithi Ramamritham 35