350 likes | 524 Views
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
E N D
IT-606Embedded Systems(Software) S. Ramesh Kavi Arya Krithi Ramamritham KReSIT/ IIT Bombay
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
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
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 ?Tea (x); x>b !Mk_tea !Mk_coffee ?ready !change (x-a); ! Pour_coffee ?ready !change (x-b); ! Pour_Tea
User ? tired ? tired ! Tea (z) ! Coffee(z) ? Pour_coffee ! collect ? 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 coffee Tired idle VM pour - coffee pour - tea Change
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
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
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