We think you have liked this presentation. If you wish to download it, please recommend it to your friends in any social system. Share buttons are a little bit lower. Thank you!
Presentation is loading. Please wait.
Published byJalynn Bickers
Modified over 2 years ago
© S. Ramesh / Kavi Arya / Krithi Ramamritham 1 IT-606 Embedded Systems (Software ) S. Ramesh Kavi Arya Krithi Ramamritham KReSIT/ IIT Bombay
© S. Ramesh / Kavi Arya / Krithi Ramamritham 2 Overview of Polis S. Ramesh
© 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
© 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
© 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
© 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
© S. Ramesh / Kavi Arya / Krithi Ramamritham 7
8 Design Methodology: POLIS View
© 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
© 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
© 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
© 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
© S. Ramesh / Kavi Arya / Krithi Ramamritham 13 POLIS Design Flow
© 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
© 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
© 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
© S. Ramesh / Kavi Arya / Krithi Ramamritham 17 User ? tired ! Coffee(z) ? Pour_coffee ! collect ? tired ! Tea (z) ? Pour_Tea !Collect
© 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
© 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
© S. Ramesh / Kavi Arya / Krithi Ramamritham 20 Interaction Example tea USERUSER coffee Tired idle pour - coffee pour - tea Change VMVM
© 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
© 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
© 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
© 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
© 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
© 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
© 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
© 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
© 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
© S. Ramesh / Kavi Arya / Krithi Ramamritham 30 HW-SW Interface
© 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
© S. Ramesh / Kavi Arya / Krithi Ramamritham 32 SW-HW interface
© 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.
© S. Ramesh / Kavi Arya / Krithi Ramamritham 34 Systems Developed Many systems Automotive Applications –Dashboard product –Engine management unit
© S. Ramesh / Kavi Arya / Krithi Ramamritham 35 POLIS Free and can be downloaded Web-address: –www-cad.eecs.berkeley.edu
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 13Slide 1 Chapter 13 Real-time Software Design.
Tornado and VxWorks. Copyright © Wind River Systems, Inc.2 Tornado-VxWorks Architecture The Real-Time, Multitasking OS Intertask Synchronization and Communication.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 1 Chapter 10 Architectural Design.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 15 Slide 1 Real-time Software Design.
Chapter 4 1 Threads Threads are a subdivision of processes Since there is less information associated with a thread than there is info associated with.
Executional Architecture Lecture Conceptual vs execution Conceptual Architecture Execution Architecture Component Connector Domain-level responsibilities.
1 Note content copyright © 2004 Ian Sommerville. NU-specific content copyright © 2004 M. E. Kabay. All rights reserved. Real-time Software Design IS301.
Architectural Design IS301 – Software Engineering Lecture # 14 – M. E. Kabay, PhD, CISSP Dept of Computer Information Systems Norwich University.
technische universität dortmund fakultät für informatik informatik 12 Communicating finite state machines Peter Marwedel TU Dortmund Informatik
1 © H. Kopetz 05/01/2014 Time-Triggered Architecture TU Wien Time-Triggered Protocols for Safety-Critical Applications Hermann Kopetz TU Wien March 21,
Silberschatz, Galvin and Gagne ©2010 Operating System Concepts Essentials – 8 th Edition Chapter 16: Windows 7.
Silberschatz, Galvin and Gagne ©2013 Operating System Concepts – 9 th Edition Chapter 2: Operating-System Structures.
1 Input/Output Chapter Principles of I/O hardware 5.2 Principles of I/O software 5.3 I/O software layers 5.4 Disks 5.5 Clocks Terminals.
Chapter 2: Operating-System Structures. 2.2 Chapter 2: Operating-System Structures Operating System Services User Operating System Interface System Calls.
Technische universität dortmund fakultät für informatik informatik 12 FSMs & message passing: SDL Peter Marwedel TU Dortmund, Informatik
1 Process Description and Control Chapter 2. 2 Process A program in execution An instance of a program running on a computer The entity that can be assigned.
1 CSE 380 Computer Operating Systems Instructor: Insup Lee University of Pennsylvania Fall 2003 Lecture Notes: Multiprocessors (updated version)
Database System Concepts, 6 th Ed. ©Silberschatz, Korth and Sudarshan See for conditions on re-usewww.db-book.com Chapter 26: Advanced.
DC-API: Unified API for Desktop Grid Systems Gábor Gombás MTA SZTAKI.
1 Operating-System Structures Operating System & its purpose Operating Systems lead to new Hardware Features System Components System Services System Calls.
1. OBJECTIVES: Defining the different types of buses Discussing bus arbitration and handshaking schemes Introducing I2C and PCI bus examples Interconnection.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
PCI Bus CENG Spring Dr. Yuriy ALYEKSYEYENKOV 2 The PCI (Peripheral Component Interconnect) bus was developed as a low-cost, processor-independent.
1 Computer Systems & Architecture Lesson 3 5. Designing the Architecture.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 11Slide 1 Chapter 11 Distributed Systems Architectures.
Legal Entity/Division - Date Multicore For Avionics Certification Issue 2013 – 03 – 22.
Threads, SMP, and Microkernels Chapter 4 1. Process Resource ownership - process includes a virtual address space to hold the process image Scheduling/execution-
ADAMA UNIVERSITY SCHOOL OF ENGENEERING & INFORMATION TECHNOLOGIES Sem. II,2010/11 INSTRUCTOR TARIKU W OPERATING SYSTEM (IT3016)
Nica Valentin–Danut SEM 2012 Service system fundamentals: Work system, value chain, and life cycle.
© 2016 SlidePlayer.com Inc. All rights reserved.