Learning Center
Plans & pricing Sign in
Sign Out



									     CSE 237A Spring 2004 Prof. R. Gupta
Modeling in Embedded Systems:
  Discrete Time & Finite State

                 This Lecture: Models
         Next Lecture: Models of Computation

                Rajesh Gupta
     Computer Science and Engineering
     University of California, San Diego.
                    Example: A “set-top” box

 A “Set top box” must interact with
    a backbone network,
        Cable, Wireless, ATM..
    have network interfaces
        ATM, TCP/IP, ...
    I/O devices
        audio, video, game controllers,
          Infrared remote, serial I/O (I2C), ..
    PC interfaces                                Set-top
        PC (host) bus                             Box
 and support
    graphics/audio/video/... processing

  Example Embedded Signal Processing
                              Real time
                              Operating                process

         Microprocessor                                 User
ASIC          Core                                    interface

                                             System Bus

         Host/Bus Interface   Host/Bus Interface    CNTL
         Programmable         Programmable
         Processor Core                                    CODEC
                                DSP Core
         Memory Interface     Memory Interface
 Proc.                                             DSP
 Code                                              Code
                 Multi-ported memory

                                       SERIAL I/O
    Examples of Hardware Subsystems

 Microprocessor cores
 DSP cores
 Field Programmable Gate Arrays (FPGAs)
 Application specific integrated circuits
  (ASICs)                                   Application     Analog
     standard cell/synthesized deigns     Specific Gates     I/O
     custom ICS
 Memory                                     Processor
     RAM, ROM, PROM, ...                      Cores
     Conten addressable memory (CAM)
     Specialized DRAMs, multi-bank
 System Bus structures & interfaces
 I/O interfaces

 Examples of Software Subsystems

 The software components of an embedded signal processing
  system can be quite diverse.
    Software running on a microprocessor core.
       Written in a “high level language” e.g., C/C++, ...
    Cooperative multi-tasking software running on one or
     more DSP processors.
       Largely written in Assembly code
           due to a lack of high quality compilers.
    A Real-time Operating system kernel running on the
     microprocessor core and/or DSP core.
    Control processes running on a
    User interface modules running on the microprocessor.
    Device drivers for interface protocols e.g., TCP/IP, ATM,
        Used, for example, in a Set-top Box application.
 Complex Software architecture
                 Critical bottleneck (ongoing research).
        System Specification: Goals &

 Main purpose: provide clear and unambiguous description of
  the system function, and to provide a
     documentation of the initial design process
 Support
     diverse models of computation
     allow the application of computer-aided design tools for
         design space exploration
         software-hardware synthesis
         validation (verification, simulation)
 Should not constrain the implementation options.
     diverse implementation technologies.

        Examples of useful Models

 Petri nets
 Data flow
     Static (Synchronous), multi-rate, dynamic,
      multidimensional, ...
     Process networks
 Discrete event models
 Communicating Sequential Processes (CSP)
 Finite State Machines (FSM)
     Hierarchical, Nondeterministic, ...
 Object-oriented models
 Imperative models
 Functional models

    Choosing Models & Languages

 Model choice: depends on the application domain, e.g.,
    DSP (digital signal processing) applications use data flow
    Control intensive applications use finite state machine
    HW simulation (algorithms & engines) use simulation
    Event driven applications use reactive models;
 Language choice: depends on:
    Underlying semantics:
       the language syntax must have a semantics in the
         model appropriate for the application.
    Available tools
    Personal taste and/or company policy

  An Event-based characterization:
  <Events> & <Processes> can vary       events        Process events

 Continuous time models, e.g., Analog
 Discrete-time models
    Totally ordered events: <time-stamp, event>
     e.g., VHDL
       “Discrete-time cycle driven”; e.g., DSP
             <clock-tick, event>
             Events with the same clock tick may
              be ordered by data dependencies.
             Used in: DSP systems.
       “Multi-rate discrete time, cycle driven”,
          e.g., multi-rate DSP
             Every n-th signal in one process
              aligns with another.              A1             C1
       Synchronous Finite state machines.
    Partially ordered events                   A2       B1    C2
       e.g., Petri nets, process algebras, ...
                                                 A3      B2    C3
        Graphs as an abstract syntax for
 Graph = <Nodes, Arcs>
 Many computation models are obtained by
  ascribing specific interpretations
  (semantics) to the nodes and arcs, and
  sometimes by constraining the structure
  of the graph.
 Examples of graph-based computation
     Petri nets
     Data flow
     Networks of processes
     Queueing models
     Control-data flow graphs
     Finite State Machines
 Hierarchical graphs thus offer a useful
  visual representation for many application

               Queueing Models

 Queueing models are graph-based system level models.
    Nodes: complex operators e.g., Poisson queues;
     computations & decision nodes.
    Arcs: Events/tokens/requests.
 Used for:
    performance estimation, e.g., determining overall
     throughput, latency, of a network of queueing nodes
 Some commercial modeling systems
    combine queueing-theory based models with other
     "program like" (c-code) nodes.
       e.g., SES modelling system

                      Petri Nets
 Petri nets
    events (transition nodes) execute ("fire") when certain
     conditions hold ("markers are present in the places
     nodes preceding events").
 Models “true” concurrency (as opposed to interleaving event
  sequences). Somewhat weak in supporting hierarchical
  descriptions and compositionality.
    Many variants e.g., Colored Petri nets.
    Very powerful; many problems undecidable unless Petri
     nets are very constrained in strructure & semantics.
 Example: Condition O will occur only when the transitions A
  and B have both fired, either in sequence, or concurrently.

       A       B       A       B   A       B    A       B

           O               O           O            O           12
                Process Networks
                       Channel          Streams

 Network of
    concurrent sequential processes,
    communicating via 1-way FIFO channels;
    the channels have unbounded capacity,
    one producer and consumer;
    writes to the channel are non-blocking, and
    reads from the channel are blocking.
 Kahn process semantics:
    Mapping from one or more input sequences to one or more
     output sequences
    Flexible but hard to schedule
 Synchronous dataflow
    Restriction of Kahn networks
    Fixed communication, easy to schedule
     Methodological Differences due to

 Kahn Process Networks
    Write code for each process (host language)
    Capture process interaction (coordination language)
    Test by simulation (execution)
 Static Data Flow
    Assemble primitive nodes: functions, data generators etc
    Schedule nodes
    Generate code
    Simulate.


process f (in int u, in int v, out int w) {
  int i; bool b = true;
  for (;;) {
       i = b ? wait (u) : wait (v);
       printf(“%i\n”, i);
       send (i, w);
       b = !b;

        Determinism in KPN Costs

 To be useful, KPN must be continuous
    More input tokens do not remove something that was
      there earlier at the output
 Continuous processes are monotonic
    (continuity implies monotonicity, but not vice-versa)
 Networks of monotonic processes are determinate
    Valuable asset to embedded system modelers
 However, semantic carelessness can easily loose
   1. Allow a process to test inputs for emptiness
       1. Think what happens to monotonicity
   2. Nondeterminate process nodes
   3. Allow more than one process to write to a channel
   4. Allow more than one process to consume data from a
   5. Allow processes to share variables

  Therefore, to ensure determinacy

 Sequences of communicated data does not depend upon the
  relative process execution speeds
 A process can not check whether data is available before
  attempting a read
 A process can not wait for data on more than one port at a
 Therefore, order of reads, writes depend only on data, not its
  arrival time

                 Scheduling KPN

 It is a challenge to schedule KN without accumulating

 Many solutions: Park’s algorithm: start with bounded buffers
  and increse the size of the smallest buffer when when buffer-
  full deadlock occurs.

      Variants of data flow models

 Data Flow and Synchronous data flow
    Flow of control is predicatable at compile time.
    Schedule can be constructed once, and repeatedly
    Applications: synchronous multirate signal processing.
 Example:

Data Flow

Synchronous Data Flow


                   SDF Scheduling

 By building a set of “flow and   3a – 2b = 0
  conservation” equations
                                   4b – 3d = 0
                                   b – 3c = 0
                                   2c – a = 0
                                   d – 2a = 0

                                   Solution: a = 2c; b = 3c; d = 4c

                                   Possible schedules:

      Finite State Machines (FSMs)

 Properties of FSMs
    Good for specifying sequential control.
    Not Turing complete.
       More amenable to formal analysis.
 Typical domains of application
    Control-intensive tasks.
    Protocols (Telecom, cache-coherency, bus, ...)
 Many variants of the formulation
    Differ in communication, determinism, ...

            FSM Example: Seat Belt Alarm

 Informal Specification         KEY_ON =>               WAIT
     If the driver              START_TIMER
         turns on the key,
         does not fasten                     KEY_OFF        5_SECONDS_UP
           the seat belt         OFF          or             => ALARM_ON
           within 5 seconds                   BELT_ON
     then sound the alarm
         for 5 seconds, or
         until the driver                             ALARM
                                or BELT_ON or
           fastens the seat
           belt                 KEY_OFF =>
         or until the driver
           turns off the key    No explicit condition => implicit self-loop
                                in the current state

            Finite State Machine: Example +
 FSM = (Inputs, Outputs, States, InitialState,   KEY_ON =>       WAIT
  NextState, Outs)                                START_TIMER

    Inputs = {KEY_ON, KEY_OFF, BELT_ON,
     BELT_OFF, 5_SECONDS_UP,                              KEY_OFF or 5_SECONDS_UP
     10_SECONDS_UP}                               OFF     BELT_ON    => ALARM_ON

    Outputs = {START_TIMER, ALARM_ON,
     ALARM_OFF}                                  10_SECONDS_
                                                 UP or BELT_ON
    States = {OFF, WAIT, ALARM}                 or KEY_OFF =>
       InitialState = OFF                       ALARM_OFF
    NextState: CurrentState, Inputs -> NextState
       e.g., NextState(WAIT, {KEY_OFF}) = OFF
            All inputs other than KEY_OFF are
             implicitly absent
    Outs (function): CurrentState, Inputs ->
       e.g., Outs(OFF, {KEY_ON}) =

     Non-deterministic Finite State

 A finite state machine is said to be non-deterministic when
    The NextState and Output functions may be RELATIONs
      (instead of functions).
 Non-determinism can be user to model
    unspecified behavior
         incomplete specification
    unknown behavior
         e.g., the environment model
    abstraction
         (the abstraction may result in insufficient detail to
           identify previously distinguishable situations)

     Reactive (Real-time) Systems

 Reactive Systems
    “React” to events
        e.g., in the external environment, other subsystems
 Suited for modeling “non-terminating” interactions
    e.g., operating systems, interrupt handlers, process
      control systems.
    Often subject to external timing constraints

 Reactive Synchronous Languages
 Assumptions
    the system reacts to internal and external events by
     emitting other events
    events can occur only at discrete time instances
    the reactions are assumed to be “instantaneous”
        In practise, this means that it takes negligible or a
          relatively small time to proces the event.
        If the processing is significant, start and end events
          can be associated with this task.
 Control flow oriented (imperative) languages
    Esterel
 Data flow languages
    Lustre, Signal
 Simple and clean semantics
    based on FSMs.
 Deterministic behavior
 Simulation, software and hardware synthesis, verification
       Esterel: An imperative language

 module EsterelFSM
                                     R                         R
 input A, B, R;
                                        A&               B&
 output O;                                            (not A)        R
                                      (not B)
     loop
            [await A || await B];
            emit O;
            halt;                       B/O             A/O
        watching R
     end loop
 end module;

         As the number of interrupts (signals to watch) increases,
            the size of the Esterel program grows linearly,
            while the FSM complexity grows exponentially.

           Esterel: Syntax & Semantics

 Esteral is a language for describing a
  collection of interacting synchronous FSMs.
     Imperative syntax                          R                 R
        S1;S2 (sequential execution of S1        A & !B     B & !A
           followed by S2)
        S1 || S2
             S1 and S2 execute in parallel.
             [S1 || S2] executes until both S1, S2
               terminate.                         B/O             A/O
     Succinct specification of Interrupts
        do <body> watching <event>                           R
             The <body> is executed until either
                   it terminates, or
                   the <event> occurs.
 As the number of signals to watch increases,
  the size of the Esterel program grows linearly,
  while the FSM complexity grows exponentially.
                Esterel: Example

 Deterministic Parallelism

trap END in
  await SECOND;
  emit ALARM;
  exit END
  await BUTTON;
  emit ACTION;
  exit END

                 Esterel Statements

Emit S
   -- make signal S present immediately
Present S then p else q end
   -- if signal S is present, perform p otherwise q
   -- stop this thread of control until next reaction
P; Q, P||Q
Loop p end
Await S
   -- pause until the next reaction in which S is present
Abort p when S
   run p upto, but not including, a reaching in which S is present
Suspect p when S
   -- run p except when S is present
Sustain S             = (loop emit S; pause end)

                  Time in Esterel

 Global clock with precise control over when events appear
    At every tick:
       Inputs presented, computation, outputs ready
 Statements
    A bounded number can be packed in one cycle, or
       Emit, present, loop
    Take multiple cycles:
       Pause, await, sustain

Esterel Examples

          Source: Stephen Edwards, Columbia
           Esterel Examples

 Parallel
  start in the
  same cycle
 Block
  terminates once
  all statements

                     Source: Stephen Edwards, Columbia
Abort Statement

                   Esterel Backgrounder

 To Language: Origins in control theory – programming control that
  provided support for time, delays, preemption
     A new vision of concurrency that allowed for determinism and
      broadcast (rooted in G. Plotkin’s Structural Operational Semantics,
 Language to Automata: Combined with Brozozowski’s derivative
  algorithmic for translating REs into automata that can used in SOS
     Improvements by Gonthier in state encoding
     Early adoption by Dassault avaiation
 Language to Circuits: Adapted to controller specification. Structural
  translation from language to circuits and their optimization. Later to
  software generation. Avoided state explosion inherent in earlier efforts.
 Handling Causality and Constructive Semantics: handling cyclic circuits
  was tough for the circuit generation from Esterel until Malik/Shiple’s work
  that enabled Esterel to be used in compiling cyclic programs.
 Esterel now finding its way with C (ECL); Java (Jester) and by itself
     Current extension into Multiclock Esterel (other synch languages are
      also doing the same, e.g., POLYCHRONY from Signal).

              State Charts: An Example

              Init                                                   R
                        Init               Init
                                  A                  B
                               SeenA              SeenB

Concurrency                              (in SeenA && in SeenB)/
                                       done         out O

      Visual syntax: FSMs + concurrency + hierarchy.
      2 concurrent state machines monitor the signals A and B.
      When both FSM transition to their final state,
          the “higher level” FSM transitions to its “done” state.
          Reset signal (R) =>
             self-loop at the highest level of the hierarchy is
              reinitializing all FSMs in the initial state.
      Program size grows linearly with signals being monitored.

 Objects
    states                            A
    events                                D        E
    conditions
    actions (outputs)                              F
                                        B       C
 Events and conditions cause state transitions
 AND or OR composition of states                        A
    leads to a configuration.
                                              B                   C

                                                             E        F

           StateCharts (continued)

 Transitions
    Between states and/or configurations
    Can be across hierarchy
    Unique source state identified
    Multiple sink states
    Multiple simultaneous transitions
    A transition can cause subsequent transitions
    Transitions or states can be labeled for output actions.

 There are many variants of such a formalism.
    Commercial systems
       Statemate (iLogix), VisualHDL (Summit Design Inc),
          SpeedChart, StateVision, ...

        Concurrent Programming
 Primitives
     semaphores (shared variables + atomic test-and-set
     monitors (more elaborate forms of semaphores: shared
      data structures + interface to them via
     message passing/interprocess communication
 Interprocess communication is supported by a combination
     programming languages
     operating systems
     hardware
 Real-time programming languages
     Specify real-time requirements
     These cannot be guaranteed unless the infrastructure
      supports the required primitives (the compilers,
      operating systems, networks hardware, I/O, peripherals,
          How models influence an
            application design
 Consider the following problem: Given input from a camera,
  digitally encode it using MPEG II encoding standards.
 This task involves:
     storing the image for processing
     going through a number of processing steps
         e.g., Discrete cosine transform (DCT), Quantization,
           encoding (variable length encoding), formatting the
           bit stream, Inverse Discrete Cosine transform (IDCT),
 Is this problem appropriate for
     Reactive Systems, Synchronous Data flow, CSP, ...
 More than one model be reasonable.
 Choice may be influenced by
     availability of tools
     efficiency of the model
         in terms of simulation time
         in terms of synthesized circuit/code.
   Requirements in a System Level
        Design Environment

 Specification and Cosimulation of
    diverse models of computation
    diverse implementation technologies
         mixed modes of representation
             compiled code, simulation models (of
              processors, subsystems), hardware, .....
 Design visualization
 Design-flow management
 Partitioning and scheduling tools
 Design data management

            Model of Computation

 A system consists of components
 Important questions to ask when dealing with components
     What is a component?
        States? Processes? Threads? Differential Eqns?
          Constraints? Objects? …
     What knowledge do components share?
        Time? Name spaces? Signals? State?
     How do components communicate?
        Events? Rendezvous? Message Passing? CT
          Signals? Streams? Method Calls? …
     What do components communicate?
        Objects? Transfer of control? Data structures?
 A MOC makes it easier to reason through these questions
     Start with a model of a machine, define its behavior (as
      operational semantics)

          Three Elements of MOC

1. Execution Semantics (or behavior of components)

2. Communication Style (or interaction among components)

3. Aggregation (or composition of components)

         Four MOCs for This Class

1. Discrete Event (DE)
     Timed models
     Suitable for modeling digital hardware
     But can be very general (define what is an event and what
        happens to it)
2. Finite State Machines
     Variants and extensions: StateCharts, StarCharts
3. Synchronous Reactive Models
     Synchrony assumption useful for safety critical
        embedded systems
          Convert timing relations to causal ordering
     Functional and deterministic behavior
     Verifying that a program is causal is a challenge
     Assume “constructive causality” to make it work
          Still a lot better than multi-level time (delta) models
4. Dataflow Process Networks
     Signal processing applications
          Heterogenous Modeling

 When a design spans multiple MOCs
 Sometimes using a language that can support description of
  designs in multiple MOCs can be attractive
     But messy for synthesis, validation
       Common examples: calling conventions used as
          component composition glues
 Important to formally define what compositions are

            Composition Gotchas

 Consider composition in synchronous models
    If done naively, these need not be closed under
     concurrent compositions
    For instance, connecting two FSMs can lead to
     combinational cyclic paths
        Not functional anymore
 Possible solutions to achieve functional composition
    Use Microsteps: e.g., delta time steps to achieve
     determinacy in behavior
    Insist on Acyclic Compositions: e.g., block diagrams with
     zero delay loops (adopted in Lustre)
    Determine Unique Fixpoint: that is, each reaction is a
     solution of a fixpoint equation. Difficult compilation.
     Adopted in Esterel

 Going Across MOC: Ptolemy Approach

 Encapsulate each description in a MOC in a “domain”
 Inter-domain simulations achieved through domain
     Define semantics of every such encapsulation carefully,
      conservatively (and yet with some efficiency)
 The “event horizon”
     Couple timed, untimed domains


 Multiple models and languages are essential for high-level
    Managing complexity by abstraction
    Formality ensures refinement correctness
    Model choice depends on
        Class of applications
        Required operations (synthesis, scheduling, ...)
 Multiple MOCs can co-exist during all phases of design
    Specification
    Architectural mapping and simulation
    Synthesis, code generation, scheduling
    Detailed design and implementation
    Co-simulation


To top