IT606 Embedded Systems Software

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

8
Design Methodology POLIS View
9
Functional Level

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

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
Mapping

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

12
Architectural Level

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

13
POLIS Design Flow
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
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
VM
?coffee(x) xgta
?Tea (x) xgtb
!Mk_tea
!Mk_coffee
?ready
!change (x-a) ! Pour_coffee
?ready
!change (x-b) ! Pour_Tea
17
User
? tired
? tired
! Tea (z)
! Coffee(z)
? Pour_coffee
! collect
? Pour_Tea
!Collect
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
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
Interaction Example

tea
USER
coffee
Tired
idle
VM
pour - coffee
pour - tea
Change
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
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
Next Step

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

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
Synthesis (contd.)

• Interfacing Synthesis
• external world
• HW-SW, SW-HW interface
• All these steps are automatic with some user
  inputs

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
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
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
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
HW-SW Interface
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
SW-HW interface
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
Systems Developed

• Many systems
• Automotive Applications
• Dashboard product
• Engine management unit

35
POLIS

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