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.

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.

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.

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.

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.

Simple FunState Model

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.

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.

Bringing the Functions and States Together

Initialize the current state of the state machine to its initial value.

1.) Predicate Evaluation2.) Check for progress3.) State machine reaction4.) Functions fire

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.

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.

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.

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.

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.

Cyclo-Static Dataflow Graphs

Production and consumption rates of actors change.

Boolean and Dynamic Dataflow Graphs

Introduce data-dependent datapath.

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.

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.

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.

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.

Scheduling Policies Verification can assist development

of scheduling policies. Static scheduling may use a simple

FSM.

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.

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.

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.

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.