it 606 embedded systems software l.
Skip this Video
Loading SlideShow in 5 Seconds..
IT-606 Embedded Systems (Software ) PowerPoint Presentation
Download Presentation
IT-606 Embedded Systems (Software )

Loading in 2 Seconds...

play fullscreen
1 / 35

IT-606 Embedded Systems (Software ) - PowerPoint PPT Presentation

  • Uploaded on

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

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'IT-606 Embedded Systems (Software )' - afia

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
it 606 embedded systems software
IT-606Embedded Systems(Software)

S. Ramesh

Kavi Arya

Krithi Ramamritham

KReSIT/ IIT Bombay

  • 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
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
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
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
Functional Level
  • System behaviour
    • precisely captured using high level models (CFSMs)
    • Example: MPEG encoder algorithm, DCT algorithm
  • Analysis
    • Simulation and Formal Verification
architecture selection
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
  • Critical step
  • mapping of behavior onto candidate architecture
  • partitioning and performance analysis
  • Manual partitioning
  • Analysis using Ptolemy tool
architectural level
Architectural Level
  • Automatic synthesis of HW and SW
  • Interface synthesis
  • RTOS function integration
  • Scheduling and communication
  • Fast prototyping and back annotation
input translation
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
  • 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

?coffee(x); x>a

?Tea (x); x>b




!change (x-a); ! Pour_coffee


!change (x-b); ! Pour_Tea


? tired

? tired

! Tea (z)

! Coffee(z)

? Pour_coffee

! collect

? Pour_Tea


interacting machines
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
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
Interaction Example







pour - coffee

pour - tea


precise execution semantics
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
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
Next Step
  • Architecture Selection
    • Choice of processors, DSP, ASIC,
    • Library of processors and architectures available in POLIS
  • Partitioning of CFSMs
  • Manual Step
  • 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
Synthesis (contd.)
  • Interfacing Synthesis
    • external world
    • HW-SW, SW-HW interface
  • All these steps are automatic with some user inputs
interface synthesis
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 synthesis27
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
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
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
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
  • 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
Systems Developed
  • Many systems
  • Automotive Applications
    • Dashboard product
    • Engine management unit
  • Free and can be downloaded
  • Web-address: