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

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

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

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

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

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

8. 8 Design Methodology: POLIS View

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

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

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

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

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

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

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

16. © S. Ramesh / Kavi Arya / Krithi Ramamritham 16 VM ?coffee(x); x>a !Mk_coffee ?ready !change (x-a); ! Pour_coffee ?Tea (x); x>b !Mk_tea ?ready !change (x-b); ! Pour_Tea

17. © S. Ramesh / Kavi Arya / Krithi Ramamritham 17 User ? tired ! Coffee(z) ? Pour_coffee ! collect ? tired ! Tea (z) ? Pour_Tea !Collect

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

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

20. © S. Ramesh / Kavi Arya / Krithi Ramamritham 20 Interaction Example tea USERUSER coffee Tired idle pour - coffee pour - tea Change VMVM

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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