1 / 35

IT-606 Embedded Systems (Software )

IT-606 Embedded Systems (Software ). S. Ramesh Kavi 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

afia
Download Presentation

IT-606 Embedded Systems (Software )

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


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

  2. Overview of PolisS. Ramesh

  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. 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. 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. 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. Design Methodology: POLIS View

  8. Functional Level • System behaviour • precisely captured using high level models (CFSMs) • Example: MPEG encoder algorithm, DCT algorithm • Analysis • Simulation and Formal Verification

  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

  10. Mapping • Critical step • mapping of behavior onto candidate architecture • partitioning and performance analysis • Manual partitioning • Analysis using Ptolemy tool

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

  12. POLIS Design Flow

  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

  14. 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

  15. VM ?coffee(x); x>a ?Tea (x); x>b !Mk_tea !Mk_coffee ?ready !change (x-a); ! Pour_coffee ?ready !change (x-b); ! Pour_Tea

  16. User ? tired ? tired ! Tea (z) ! Coffee(z) ? Pour_coffee ! collect ? Pour_Tea !Collect

  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 • one-place buffer • Receiver consumes the event

  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

  19. Interaction Example tea USER coffee Tired idle VM pour - coffee pour - tea Change

  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 • Time passes when control is with the scheduler

  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

  22. Next Step • Architecture Selection • Choice of processors, DSP, ASIC, • Library of processors and architectures available in POLIS • Partitioning of CFSMs • Manual Step

  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

  24. Synthesis (contd.) • Interfacing Synthesis • external world • HW-SW, SW-HW interface • All these steps are automatic with some user inputs

  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

  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

  27. 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

  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 • Create a service routine that emits the event

  29. HW-SW Interface

  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

  31. SW-HW interface

  32. 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.

  33. Systems Developed • Many systems • Automotive Applications • Dashboard product • Engine management unit

  34. POLIS • Free and can be downloaded • Web-address: • www-cad.eecs.berkeley.edu

More Related