Paper Discussion Design of Embedded Systems: Formal Methods, Validation, and Synthesis

1. Paper DiscussionDesign of Embedded Systems:Formal Methods, Validation, and Synthesis Mark McKelvin Vito Dai

2. Outline • Introduction to Embedded System Design • Specification of the Design • Models of Computation • Languages • Heterogeneous Models • Validation • Mapping an algorithm to an architecture • Summary

3. Introduction • Purpose • To address the design of reactive real-time embedded systems and to present methods and tools that aid in the design process. • Characteristics of reactive real-time embedded systems: • Re-usable software components • Ad-hoc hardware components • Reacts in real-time with the environment • Must operate with safety and reliability • Sample applications include: • Autonomous vehicle control • Communication systems • Consumer electronics

4. Introduction (cont’d.) • Challenges • Managing design complexity and heterogeneity • Deciding the hardware + software architecture for the system • Maintaining reliability, safety and optimal performance • Proposed Solution • Understand the interaction between various formal models in the various stages of the design process which includes: • Specification • Validation • Synthesis

5. Embedded System Design Process Specifications Formulate Models Validation Synthesis Implementation

6. Elements of a Model of Computation • The model of computation defines the behavior and interaction of various components of a design. • Components of a formal model of computation: • Functional specification which includes inputs, outputs, and possibly internal (or state) information. • A set of properties the design satisfies that can be checked against the functional specification. • A set of performance indices that are used to evaluate the quality of design in terms of cost, reliability, and overall performance given as a set of equations involving inputs and outputs. • A set of constraints on performance indices.

7. Properties of Models • State: denotes that in most models, behavior is given as a sequence of state transitions. Two types are possible: • Finite number of states • Infinite states • Decidability: denotes the ability for certain desirable properties to be determined in a finite amount of time for a system. • Concurrency and communication • Concurrency can be achieved through various mechanisms • Communication can be explicit or implicit • Explicit: sender process informs receiver processes about the state • Implicit: two or more processes share a common notion of state

8. Communication Example Sender Receiver • Explicit communication: • Send time is not known • Only sender can detect errors • Implicit communication: • Send time is known • Receiver can detect errors

9. Communication Management • Managing the order of events is important for communicating between processes. • Parallel physical systems naturally share a common notion of time, thus, are naturally able to handle concurrent processes. • Logical systems need a mechanism to explicitly share a notion of time. Some common mechanisms for managing the order of events include: • Unsychronized • Read-modify-write • Unbounded FIFO buffered • Bounded FIFO buffered • Rendezvous (single and multiple)

10. Models of Computation • Tagged Signal Model • an abstract formalism for describing aspects of models of computation for embedded system specification. • Discrete-Event • Communicating Finite State Machines • Synchronous/Reactive • Dataflow Process Networks • Other Models

11. Discrete-Event • Time is important • Usually carries a time stamp indicating the time an event occurs • Common in model simulations • Digital hardware is simulated using a discrete-event approach • VHDL • Verilog • Advantages: • Efficient for large systems with large, frequently idle or autonomously operating sections. • Disadvantages: • Expensive • Time consuming • Overhead from processing the time stamps (not efficient)

12. Finite State Machines • Usually consist of … • A set of inputs • A set of outputs • A finite set of states (with a defined initial state) • An output function mapping inputs and states to outputs • A next-state function mapping inputs and states to (next) states • Advantages: • Good for modeling sequential behavior • Memory is decidable • Each state can be examined in finite time, theoretically • Disadvantages: • Practically, its expensive to examine each state in finite time • Impractical for modeling concurrency or memory (due to state-explosion problem)

13. Synchronous/Reactive • Cycle-based Models • Advantages: • Simplifies the simulator by requiring no sorting • Excellent for synchronous circuits • Applied successfully at the system level of signal processing applications • Easily generalized to multirate systems • Disadvantages: • Inefficient for modeling systems where events do not occur at the same rate in all signals, like situations where the alignment of events in different signals is irregular • The cost of processing tokens to indicate the absence of an event is considerable • Synchronous languages • Describes systems as a set of concurrently-executing synchronized modules that communicate through either present or absent signals (i.e., Esterel, Lustre, Signal, Argos) • Advantages: well suited for speed critical applications, can be compiled directly into hardware. • Disadvantages: verifying that a program is causal is a challenge

14. Dataflow Process Networks • A program is specified by a directed graph with the following: • Nodes (actors) that represent computations • Arcs that represent totally ordered sequences (streams) of events (tokens) • Special case of Kahn process networks • Communication by unbounded FIFO buffering • Processes are constrained to be continuous (determinate) mappings from input streams to output streams Key: A C D = token B = actor = stream Figure of a dataflow network.

15. Other Concurrency Models • Rendezvous based • Two or more concurrent processes proceed autonomously, but at some point, coordinate so they are simultaneously at specified points. • By our definition, they are not synchronous • Events are partially ordered, not totally ordered • Petri Nets • Neither Turing complete or finite • A number of theoretical results and practical design aids and methods are based on them.

16. Languages • A language is a set of symbols, rules for combining them (syntax), and rules for interpreting combinations of symbols (semantics). • Denotation semantics – gives meaning of the language in terms of relations • Operational semantics – gives meaning of a language in terms of actions taken by an abstract machine • Expressiveness – denotes the behaviors that can be described in the language • Not expressive enough leads to unsuitable behavior. For example, it may specify interaction between computational modules but not the computation performed by the models. • Too expressive leads to analysis and synthesis problems becoming undecidable • Choosing a language in which the desired behavior is compact can be critical. It helps to solve analysis and synthesis problems.

17. Heterogeneous Models of Computation • Several models of computations have been developed with varying degrees of weaknesses and strengths • Two alternatives can be taken: a mix approach or a single approach • Challenge to the mix approach: • The semantics between different models must be defined

18. Outline • Introduction to Embedded System Design • Specification of the Design • Validation of the design • Simulation / co-simulation • Formal verification • Mapping an algorithm to an architecture • Partitioning • Synthesis • Conclusions

19. Validation • The purpose of validation is to answer questions such as: • Will the communication network deadlock? • Will the software check for user input at least once every 500 ms? • Is the FPGA programmed correctly to implement the FSM? • Will the MPEG decoder, implemented on the DSP, decode at 30 frames per second? • In short, we would like to check whether the specifications are met, and whether the implementation is correct • Other categories: safety properties, liveness…

20. Validation Tools • By construction • Inherent property of the model of computation • By formal verification • Prove using theroems, often the model of computation needs to be restricted • By simulation • Exhaustive simulation frequently not possible • Rich set of tools available for hardware, but co-simulation of hardware+software is difficult

21. Simulation • I’ve got a software program for MP3 (in C) decompression on a DSP and I want to know: • Will it run correctly? • Will it run fast enough? • Classic approach • Build a simulator using e.g. VHDL or Verilog • Translate the software into signals suitable for the simulator • Tradeoff simulation accuracy vs. speed!

22. Simulation Accuracy vs. Speed • Gate level simulation • Accurate verification of hardware • Very slow software simulation, very basic algorithms • Instruction set architecture simulation (ISA) • Standard CPU simulation • Bus-functional models • Models processor components • Uses statistical modelling of bus usage • Translation-based models • Translates code designed to run on target CPU into code running on simulation host • Emulation • Problem: • Accurate simulation of only the simplest algorithms • Time spent translating the algorithm to inputs to each model • Even worse if algorithm isn’t easily expressed in C

23. Co-simulation methods • Ideally, we would like to simulate… • Hardware components at a low-accurate level • Software at a high level where it can be modified and executed quickly • A wide variety of techniques • Customized combined hardware/software simulation [Gupta] • Linking hardware simulator with software process through interprocess communication [Rowson] • Hardware simulator with bus-cycle emulator to interact with software [Wilson] [Thomas]

24. Co-simulation methods • Use native hardware simulator and native software simulator communicating with message passing as needed [Hagen] • Hardware uses e.g. cycle-based simulation • Software uses e.g. profiling time • Master-slave relationship between the two to synchronize times • Ptolemy [Kalavade, Lee] [Lee, Rabaey] • Domains of differing abstraction / models communcating through “Wormholes” to sychronize schedulers • Retargetable complier + automatic VHDL envorinment generator [Sutarwala, Paulin] • Can be used to explore simulate the performance of software on different DSP architectures quickly

25. Formal Verification • Verify properties that must hold for a broad range of inputs, e.g. deadlock, livelock • A wide variety of techniques • Provide tools to assist with theorem proving [Gordan, Melham] [Boyer-Moore] [PVS] • Undecidability • Large search space issues

26. Formal Verification • Finite automata methods and infinite automata methods • Difficulty for designers to describe systems formally • State-space explosion of composing many small automata together • Abstraction and non-determinism, solve a more constrained problem • In particular, model-checking and language containment are particularly successful because of • Automation • Close relationship to finite-state behavior of digital systems • Not every reachable state needs to be modelled explicitly • Partial ordering of computation between elements of a process network

27. Synthesis • So my MP3 decompressor works fine in (abstract super high level language of your choice), how do I convert it to C / assembly without breaking it? • Some environments e.g. Ptolemy, StateCharts, Esterel provide software synthesis, auto-generated C code • Even higher level supervisory control [Ramadage, Wonham] • Describe what needs to be achieved, in contrast to programs which describe how to go about achieving it • Control theory to synthesize an “optimum” finite-state controller

28. Mapping specification to architecture • What architecture or platform should I implement my MP3 decoder on? • Hardware components: CPU, DSP, etc. • Software components: OS, drivers, etc. • Interconnect components: network, bus, etc. • Cost function: time, area, price of component, etc. • Partitioning: which component should do the work? • Severe restrictions are placed on search space to make mappings more manageable

29. Partitioning • No clear winner, a wide variety of techniques • Graph-based model [Earnst] • Profiling to discover bottlenecks in all-software partition • Estimating closeness between operations, e.g. +/- • Count number of data items exchanged between partitions • Block-by-block performance driven [Olokutun] • Specification in Hardware Description Language • Synthesis tools for hardware cost estimation • Profiling for software cost estimation • Takes into account communications overhead of partitioning

30. Partitioning • Set-based representation of the system [Kumar] • Choosing a set of processors to execute a set of cooperating tasks [D’Ambrosio] • Graph based fine-grained representation [Barros] • Acyclic dependency graph derived from dataflow graph [Kalavade, Lee] • Graph based partitioning of a variable-grained specification [Vahid, Gajski] • CDFG representation [Steinhausen] • System specification in SDL [Ben Ismail] [Voss] • Scheduling-based interface partitioning [Chou] [Walkup, Boriello]

31. Hardware and Software Synthesis • Hardware synthesis for ASIC, ASIP, and FPGAs are well studied • Software synthesis in general is not well accepted, but for embedded systems which are more constrained it can be successful • e.g. software implementation of FSMs • e.g. protocol handling • In general software synthesis can be classified according to • How the specification is formally described • How communication will occur • How scheduling is done

32. Methods of Software Synthesis • [Chou] • Specify processes under Verilog with timing constraints • Scheduling by finding a cyclic order of operations which preserves I/O rates and timing constraints • [Chou] Device driver synthesis • Specify a description of each I/O port and list of communication instructions • Algorithm assigns communications to physical entities in the microcontroller (special functions, ports, memory-mapped) • [Gupta] • Specify a set of threads from CDFG (from Hardware-C) • Each thread is statically scheduled, threads are dynamically scheduled • Also a scheduling method for reactive real-time systems

33. Methods of Software Synthesis • [Chiodo] • Specify from a asynchronous finite state machines • Tasks are scheduled with standard run-time algorithms • Simple branch and assignment CDFG blocks are generated • Retargetable compilation for generic processors [Liem] • Microcode generation for VLIW processors [Marwedel] • Measuring power consumption [Tiwari]

34. Summary • A broad overview of the research in embedded system design • A number of specification models and languages • Validation techniques to check the implementation against the specification efficiently • Software synthesis techniques for some specification languages for specific purposes