Synthesis of Software Programs for Embedded Control Application

1
Synthesis of Software Programs for Embedded
Control Application

• Felice Balarin, Massimiliano Chiodo, Paolo
  Giusto, Harry Hsieh, ASV, etc.

Presented by Guang Yang
2
Outline

• Introduction
• Preliminaries
• Software Graphs
• Generation of the
• Real-Time Operating System
• Experimental Results
• Conclusions

3
Introduction

• Embedded Systems
• Electronic components of a physical system that
  typically
• Monitor variables of the physical system
• Process information
• Output signals
• Implementation of Embedded Systems
• Full hardware configuration
• Full software implementation
• Mixed configuration

4
Introduction(cont.)

• The problem Software Synthesis
• software development ? software analysis
• right-for-the-first-time
• Inadequate SW synthesis vs HW synthesis
• SW synthesis vs SW compilation
• Optimization translation process
• vs
• Close to implementation level

5
Introduction(cont.)

• The problem Software Synthesis
• software development ? software analysis
• right-for-the-first-time
• Inadequate SW synthesis vs HW synthesis
• SW synthesis vs SW compilation
• Optimization translation process
• (1970 theoretical work?)
• vs
• Close to implementation level

6
Introduction(cont.)

• Compiler Technology
• 20 years progress
• High level constructs ???
• Intermediate code ???
• Machine code
• Why semilocal?
• Time
• Complexity

Semilocal opt.
Arch. spec. opt.
7
Introduction(cont.)

• SW vs HW Compilation
• functional reg allocation scheduling,
• component synthesis optimization
• vs
• reg allocation, instruction selection,
• and local optimization
• HW syntheis is stronger than SW synthesis
• Synthesize SW HW in a single system
• make SW HW-like

8
Introduction(cont.)

• Restricted Application Domains
• Simpler and more optimal
• In this paper
• Control-dominated embedded sys.
• MoC FSM
• Advantages
• Easily understand widely used
• Abundant theoretical practical results
• Disadvantages
• No good support for computation
• Previous FSM extension pays too much
• CFSM

9
Introduction(cont.)

• This papers approach to SW synthesis
• Assumption
• Specification written in a network of CFSMs
• A Real-Time OS
• An existing general purpose C compiler
• Includes
• Optimization techniques, function description and
  coupling of optimization and estimation

10
Introduction(cont.)

• Approach
• Optimized translation of the transition function
  of a given CFSM into an s-graph (using BDD)
• S-graph optimization and code-size estimation
• Translation of the s-graph into a target lang.
• Scheduling CFSMs and generating RTOS
• Compilation into machine code

11
PreliminariesPrevious work

• Software synthesis
• synchronous language (Esterel)
• (v3) single FSM implementation (fast but big)
• (v4) multi-FSM implementation (linear size, but
  no low-level opt., cant opt. module-by-module.)
• CFSM approach
• User can choose granularity of CFSMs
• User can manipulate CFSM hierarchy in synthesis
• Opt. done close to final c-code implementation
• Both Boolean-circuit and decision-tree based
  optimization

12
Previous work (cont.)

• Software synthesis
• high-level language
• Scheduling of operations to satisfy timing
  constraints
• CFSM approach
• Software generation for each CFSM
• Scheduling of CFSM transitions to satisfy timing
  constraints

13
Hardware High-Level Synthesis

• Behavioral/RT level synthesis
• Input Sequential specification
• Without/with fixed timing and actions
• Output cycle-by-cycle register and register
  changes/gate level netlist
• Behavioral-level synthesis operates on
  structurally similar description to the original
  one but outputs are in a form that facilitates
  BDD logic opt.
• BDD-like structures are very efficient program
  implementations.

14
Hardware Simulation

• Software synthesis techniques come from
  cycle-based hardware simulation.
• (Efficiently compute on a sequential machine
  the transition function of an FSM)
• There are differences
• Starting point large syn. circuit at gate level
  vs explicit representation of an Extended FSM
• Target execution on high-end workstation vs very
  small embedded controllers

15
Binary Decision Diagrams

• An efficient representation for Boolean
  functions.
• Node-Variable
• Edge-Value
• Size, reduce
• Canonicity

16
Characteristic Functions

• or
• where
• Restriction
• Projection
• Support
• The support of an output is the set of inputs
  that the output depends on.

17
Network of Codesign FSMs

• Globally Asynchronous Locally Synchronous
• Locally Synchronous
• Take snapshot of inputs (valued or value-less)
• Perform computation
• Change state or emit output events
• Globally Asynchronous
• Events happen at any time and independently
• No guarantee to receive events

18
Synchrony Asynchrony

• Asynchronous comm. does not overly restrict the
  implementation domain.
• Synchronous lang.s restriction is too strong. (0
  computation time)
• Imply single large FSM
• Formal verification and analysis technieques
• Small solution space
• Synchronous program must be analogous to
  combinational circuit.

19
Asynchronous comm. Model

• Nondeterministic
• Complicate design and verification
• Ease modeling unpredictability of reaction delay
  at spec level and implementation level
• Software implemented in RTOS

20
Reasons for introducing CFSM

• A network of components can express a complex
  behavior while keeping the complexity of each
  component at a reasonable level
• Behavior spec is extended with computation.
• Delays are useful to model and constrain timing.
• Asynchronous comm. is more efficient for
  representing interactions among tasks.

21
Software Graphs

• module simple
• input cinteger
• output y
• var ainteger in
• loop
• await c
• if a?c then
• a0
• emit y
• else
• aa1
• end if
• end loop
• end var
• end module
• Input output signals are associated with two
  values, boolean and value.
• State variable is associated with current and
  next states.

22
S-Graphs

• S-Graph model resemble but differ from branching
  programs and BDD.
• Single variable predicated on TEST nodes
• Assignments to only a single output

23
Evaluation of multioutput function
24
Evaluation of multioutput function
25
S-Graphs

• Definition 2 Let G be an s-graph, and let be
  partitioned among input and output variables as
  assumed by procedure evaluate.
• G is functional if every output variable
  zj
• 1) is assigned by eval_step at least one
  defined (i.e., different from ?) value for each
  combination of values of the input variables
• 2) has a defined value whenever a predicate
  or a function depending on zj is visited by
  eval_step.
• It is easy to show that for a functional s-graph,
  evaluate defines a completely specified I/O
  function.
• It is easy to check that a non-functional s-graph
  denotes
• Either an incompletely specified funciton
• Or a relation between the input and the output
  variables

26
S-Graph Implementation and Optimization

• Represent CFSM
• Again, focus on control part, but support date
  computation
• Set T of tests on input and state variables
• Set A of actions (output emissions or assignments
  to state variables)
• Reactive function

27
An example

• Tests
• present.c
• a?c

28
CFSM

• Transition function is executed in 3 phases
• Tests are evaluated
• S-Graph is evaluated to get output variables
• Actions corresponding to output variables with
  value one, are executed
• Assumption
• Expressions do not have side effects
• (order independent)

29
Initial S-Graph Implementation
30
Initial S-Graph Implementation (cont.)

• Theorem1 Let be the
  characteristic function of multioutput function
  , such that and let v be the
  BEGIN vertex of the s-graph G returned by
  procedure build. Then, for all
• Input to this algorithm could be function or
  relation.
• There may be dont care.

31
S-Graph Optimization

• Optimization by reordering
• Output after its support
• Minimum depth s-graph?minimum exec time
• Heuristically optimal for code size
• Output before its support
• No test vertices
• All exec take the same time
• In principle, better in practice, worse.
• Other orderings
• Optimization by collapsing test nodes
• Closed subgraph approach
• No improvement in experiment

32
S-Graph to C Translation

• Straightforward due to direct correspondence
  between s-graph node types and basic C primitives
• TEST node ? if, goto, switch
• ASSIGN ? assignment
• Users do not see the low level code, they debug
  the original code

33
Software Cost and Performance Estimation

• HW/SW partitioning and SW synthesis for real-time
  embedded systems require accurate and quick
  estimates of code size and of minimum and maximum
  execution time.
• The structure of the code
• The system on which the program will run
• Cost estimation on the s-graph
• Determining cost parameters
• Apply parameters to the s-graph
• Details are covered by another presentation.

34
Generation of RTOS

• To implement the correct behavior of CFSM
  network, we need
• Schedule individual CFSM
• Provide a mechanism to emit and detect events
  between SW-CFSMs
• Provide a mechanism to transfer events between
  SW-CFSMs and HW-CFSMs
• Ensure the semantics of input event consumption

35
Generation of RTOS

• Scheduling of SW-CFSMs
• Enable disable
• Offline scheduling policies
• Communicating Events Between SW-CFSMs
• Communicating Events Between HW- and SW-CFSMs
• SW ? HW (memory mapped I/O port)
• HW ? SW (polling, interrupts(default))

36
Consumption of Events

• SW-CFSMs is running, no transitions are enabled
  ? preserve input events
• When a CFSM starts reading its input event flags,
  no new flags can be set until the CFSM finishes
  its execution.
• E.g.

1) the CFSM checks the flag and finds that A has
not occurred, 2) the CFSM is interrupted, 3) A
occurs, 4) B occurs, 5) the CFSM continues the
execution, finds that B has occurred and
executes a transition which is enabled only if B
has occurred and A has not.
37
Comparison with Commercial RTOSs

• When taking commercial RTOSs
• Implement event emission and detection only using
  the event flags services provided by the RTOS
• Provide enough info to RTOS
• Advantages of authors approach
• Event emission and detection can be efficient or
  avoided in some cases.
• Size of RTOS is often much smaller.
• Experiment with tradeoff is easy.

38
Experimental Result

• Dashboard Controller (Estimation)

39
Experimental Result

• Dashboard (Diff. Orderings)

40
Experimental Result

• Comparison with Esterel v5

41
Experimental Result

• The Shock Absorber Controller

Synthesised Implementation Hand-designed Implementation diff
ROM (byte) 46639 32K 42
RAM (byte) 10229 8K 25
42
Conclusion

• A new technology for synthesis of software for
  embedded real-time control dominated systems
  based on CFSM
• Quick and fairly precise cost- and
  performance-estimation
• Convincing experimental results