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 paper’s approach to SW synthesis • Assumption • Specification written in a network of CFSM’s • 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 CFSM’s and generating RTOS • Compilation into machine code

11. Preliminaries—Previous work • Software synthesis • synchronous language (Esterel) • (v3) single FSM implementation (fast but big) • (v4) multi-FSM implementation (linear size, but no low-level opt., can’t 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. a 1 0 b b 1 0 1 0 1 0 0 0 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 FSM’s • 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 c:integer; output y; var a:integer in loop await c; if a=?c then a:=0; emit y; else a:=a+1; 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 don’t 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-CFSM’s • Provide a mechanism to transfer events between SW-CFSM’s and HW-CFSM’s • Ensure the semantics of input event consumption

35. Generation of RTOS • Scheduling of SW-CFSM’s • Enable & disable • Offline scheduling policies • Communicating Events Between SW-CFSM’s • Communicating Events Between HW- and SW-CFSM’s • SW  HW (memory mapped I/O port) • HW  SW (polling, interrupts(default))

36. Consumption of Events • SW-CFSM’s 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 RTOS’s • When taking commercial RTOS’s • Implement event emission and detection only using the event flags services provided by the RTOS • Provide enough info to RTOS • Advantages of author’s 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

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