FunState – An Internal Design Representation for Codesign

1. FunState – An Internal Design Representation for Codesign • A model that enables representations of different types of system components. • Mixture of functional programming and state machines. • Relationship to other models, regular state machines, communicating FSMs, marked graphs and synchronous dataflow, Boolean and dynamic dataflow graphs, Petri Nets, and SPI.

2. Issues of Complex Embedded Systems • Increasing heterogeneity and complexity, decreasing expected time-to-market. • Encompasses a broad range of allocation, scheduling, and binding issues in both hardware and software. • SPI (System Property Intervals) is a methodology designed to deal with certain modeling problems. • Capture semantics of multiple input languages.

3. What is FunState? • Functions driven by State machines • Supports verification and representation of different design decisions. • SPI and FunState are semantically equivalent. • Incremental implementation and verification. • Major results of FunState: • Use as a internal representation of heterogeneous embedded systems for scheduling and verification. • Explicit separation of control and dataflow can represent many different models of computation. • FunStates as regular state machines allows many previously investigated properties to be applied here.

4. Previous Fun Work • Many different models of computations including discrete-event, reactive, and dataflow. • Codesign FSMs also combine synchronous dataflow with FSMs • PSMs • Hierarchical FSMs introduced by Harel including *charts and statecharts. • FunState attempts to reduce complexity by modeling only characteristics of an input specification which are relevant to a particular design method.

5. Basics of FunState • Basic components include a network, N, and a FSM, M. • Network N contains (F, S, E) • F is a set of functions • S is a set of storage units (either queues of unbounded length or registers, linear arrays of pairs of an address and a value) • E is a set of directed edges of (F X S) U (S X F) • Data is represented as valued tokens. • Datapath must be alternate between storage units and functions.

6. Simple FunState Model

7. Functions • Inputs and outputs have associated variables that denote the number of consumed tokens and number of produced tokens. • Can add or subtract nondeterministic (can be bounded) number of tokens.

8. The State Machine • Can use different models to specify the FSM which controls the datapath. • Use a model based on ARGOS similar to Harel’s statecharts. • Transitions are labeled with conditions and actions. Predicates must be true, then the transition is taken.

9. Bringing the Functions and States Together Initialize the current state of the state machine to its initial value. 1.) Predicate Evaluation 2.) Check for progress 3.) State machine reaction 4.) Functions fire

10. Model Extensions • The state machine can be a hierarchical FSM with XOR and AND states. • The network may contain embedded components. • This allows for arbitrarily deep hierarchy.

11. Computational Model for FunStates • Use regular state machines for computation purposes. • Assuming that there are no data dependencies, hierarchy has been completely flattened, and functions have constant rates of consumption and production; FunState models may be translated into static state diagrams and dynamic sate diagrams.

12. Static and Dynamic State Diagrams • Static state diagram has a set of nodes, a set of directed edges which have integer distances between them, predicate functions, and some initial state. • Dynamic state diagrams is an inifinite directed graph which has transitions that may connect nodes dynamically, with an initial state.

13. Relationship with Communicating FSMs FSM M1 can write to a queue during a transition. M2 can guard its transition with predicates. If transition is taken the token is removed. POLIS models may also be represented with this model.

14. Marked Graphs and Synchronous Dataflow Graphs • Nodes representing actors are connected with edges representing communication queues. • A function determines the number of initial tokens in queues, two functions denote the numbers of tokens removed and added by firing of target and source actors, respectively. • For FunState models, we can replace each actor with a function and each edge with an edge-queue-edge. There are existing functions for production and consumption of tokens. State machine has one state with a transition for every actor.

15. Cyclo-Static Dataflow Graphs • Production and consumption rates of actors change.

16. Boolean and Dynamic Dataflow Graphs • Introduce data-dependent datapath.

17. Differences with Petri Nets • Queues in FunStates have a FIFO behavior, unlike Colored Petri Nets (CPNs) • No registers defined in CPN. • Transitions are controlled by a FSM, whereas they are always ready in a CPN.

18. Differences with SPI • SPI does not explicitly separate control and dataflow. States are not explicitly represented. • The “state” of a SPI model is only the channel contents. • SPI processes are autonomous like actors in a dataflow model. FunState functions are all controlled. • SPI autonomous systems can be modeled by FunState models using local control. • The most important difference is the control strategy.

19. Translating between SPI and FunState • Translate the FunState component with a single state and several transitions. Actions of these transitions trigger functions corresponding to SPI process’s modes. • Or we can model the state-dependent behavior of the FunState by using virtual feedback networks in SPI. Then the SPI has a virtual state machine that can control the mode tags.

20. Formal Verification • FunStates can be verified with existing techniques because of their representation in regular state machines. • Interval diagram techniques can be used to verify models efficiently and involves four steps: • Formulation of the verification goal with a computation tree logic formula. • Representation of state transitions in the form of an interval mapping diagram. • Represent state sets as interval decision diagrams • Apply boolean operations, quantification, and state set mapping until a fixed point is reached.

21. Scheduling Policies • Verification can assist development of scheduling policies. • Static scheduling may use a simple FSM.

22. Symbolic and Conflict-Dependent Scheduling • Quasi-static scheduling may be modeled to overcome the disadvantages of static or dynamic schedule policies. Only data-dependent choices are left to run-time decisions. • Complex embedded systems have a growing problem of multiple types of non-determinism. • More complex models of computation designed to handled these have their own problems of system deadlocks and queue overflows.

23. Conflict Dependent Scheduling • Guaranteed to find a deadlock-free and bounded solution if one exists. • This may be applied to a FunState model as a refinement in the internal representation: • Specify all possible schedules through a non-determinate transition behavior; representing all design alternatives • Search state space for cycles representing valid schedules • Extracted schedule is made into a FSM and compacted using state minimization techniques • Replace original specification part with the result, it may be transformed into program code.

24. Example: Molecular Dynamics Simulation • Simple algorithm mapped onto a main workstation (Host) and a special purpose hardware accelerator (CoProc). • Repeated computations in a feedback loop distributed among both processors. • Certain computations are unknown at runtime, represented as conflicts. • Dark circles represent alternatives that may be chosen during development. • Goal: Replace dark circles with white circles, which represent determinate solutions and only one or completely disjoint transitions.

25. Conclusion • FunState model allows internal representation of complex heterogeneous system behavior. • Can easily be used to relate other models of computation. • Hierarchy and step-wise refinement can be easily used to reduce non-determinism.