ICS 212 Fall 2002 Prof. R. Gupta Modeling in Embedded Systems: Discrete Time

1
ICS 212 Fall 2002 Prof. R. GuptaModeling in
Embedded SystemsDiscrete Time Finite State

• Rajesh Gupta
• Information and Computer Science
• University of California, Irvine.

Contribution courtesy P. A. Subrahmanyam, Luciano
Lavagno
2
Example A set-top box

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

3
Example Embedded Signal Processing System
4
Examples of Hardware Subsystems

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

5
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 microcontroller/pro
  cessor.
• 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).

6
System Specification Goals Characteristics

• 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
• partitioning
• software-hardware synthesis
• validation (verification, simulation)
• testing
• Should not constrain the implementation options.
• diverse implementation technologies.

7
Examples of useful Computation 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

8
Choosing Models Languages

• Model choice depends on the application domain,
  e.g.,
• DSP (digital signal processing) applications use
  data flow models
• Control intensive applications use finite state
  machine models
• HW simulation (algorithms engines) use
  simulation models
• 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

9
An Event-based characterizationltEventsgt
ltProcessesgt can vary

• Continuous time models, e.g., Analog
• Discrete-time models
• Totally ordered events lttime-stamp, eventgt e.g.,
  VHDL
• Discrete-time cycle driven e.g., DSP
• ltclock-tick, eventgt
• 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.
• Synchronous Finite state machines.
• Partially ordered events
• e.g., Petri nets, process algebras, ...

10
Graphs as an abstract syntax for models

• Graph ltNodes, Arcsgt
• 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 models
• 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 domains.

11
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

12
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.

13
Process Networks

• 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.

14
Variants of data flow models

• Synchronous data flow
• Flow of control is predicatable at compile time.
• Schedule can be constructed once, and repeatedly
  executed.
• Applications synchronous multirate signal
  processing.
• Dynamic data flow
• The consumption and production of data tokens
  (node firing) is data dependent.
• Turing complete gt many questions undecidable.
• Algorithms exist that work most of the time.
  Combine these with dynamically constructed
  schedule.
• Multidimensional data flow
• useful for 2-D operations, e.g., images video.

15
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, ...

16
FSM Example Seat Belt Alarm Control

• Informal Specification
• If the driver
• turns on the key, and
• does not fasten the seat belt within 5 seconds
• then sound the alarm
• for 5 seconds, or
• until the driver fastens the seat belt
• or until the driver turns off the key

No explicit condition gt implicit self-loop in
the current state
17
Finite State Machine Example Definition

• FSM (Inputs, Outputs, States, InitialState,
  NextState, Outs)
• Inputs KEY_ON, KEY_OFF, BELT_ON, BELT_OFF,
  5_SECONDS_UP, 10_SECONDS_UP
• Outputs START_TIMER, ALARM_ON, ALARM_OFF
• States OFF, WAIT, ALARM
• InitialState OFF
• NextState CurrentState, Inputs -gt NextState
• e.g., NextState(WAIT, KEY_OFF) OFF
• All inputs other than KEY_OFF are implicitly
  absent
• Outs (function) CurrentState, Inputs -gt Outputs
• e.g., Outs(OFF, KEY_ON) START_TIMER

18
Non-deterministic Finite State Machines

• 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)

19
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
• real-time

20
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

21
Esterel An imperative language

• module EsterelFSM
• input A, B, R
• output O
• loop
• do
• await A await B
• emit O
• halt
• 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.

22
Esterel Syntax Semantics

• Esteral is a language for describing a collection
  of interacting synchronous FSMs.
• Imperative syntax
• S1S2 (sequential execution of S1 followed by S2)
• S1 S2
• S1 and S2 execute in parallel.
• S1 S2 executes until both S1, S2 terminate.
• Succinct specification of Interrupts
• do ltbodygt watching lteventgt
• The ltbodygt is executed until either
• it terminates, or
• the lteventgt occurs.
• As the number of signals to watch increases, the
  size of the Esterel program grows linearly, while
  the FSM complexity grows exponentially.

23
Esterel Example

• Deterministic Parallelism
• trap END in
• await SECOND
• emit ALARM
• exit END
• await BUTTON
• emit ACTION
• exit END
• end

24
State Charts An Example
FSMs
Hierarchy
Concurrency

• 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) gt
• self-loop at the highest level of the hierarchy
  is triggered,
• reinitializing all FSMs in the initial state.
• Program size grows linearly with signals being
  monitored.

25
StateCharts

• Objects
• states
• events
• conditions
• actions (outputs)
• Events and conditions cause state transitions
• AND or OR composition of states
• leads to a configuration.

26
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.
• Example.

27
State Charts

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

28
Concurrent Programming Languages

• Primitives
• semaphores (shared variables atomic
  test-and-set mechanisms)
• monitors (more elaborate forms of semaphores
  shared data structures interface to them via
  functions/procedures)
• message passing/interprocess communication
• Interprocess communication is supported by a
  combination of
• 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, etc.)

29
Communicating sequential processes (CSP)

• each process is sequential, but different
  processes can execute at different rates, and
  coordinate by communicating and thereby
  synchronizing.

30
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.

31
Digital Camera
32
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

33
Domain-specific Languages

• Language embodies methodology
• Verilog
• Model hardware system and testbench
• Javas concurrency
• Software threads plus per-object locks to ensure
  atomic access
• Multi-rate signal processing (dataflow) languages
• Blocks with fixed I/O rates, SW or HW
  implementation
• Extended Finite State Machines languages
• Hierarchical states and decision, SW or HW
  implementation

34
Types of Languages

• Hardware (Discrete Event)
• Structural and procedural styles
• Unbuffered wire communication, discrete-event
  semantics
• Software
• Procedural (instructions and data)
• Some concurrency using scheduler
• Dataflow
• Practical for signal processing
• Concurrency buffered communication
• Hierarchical Finite State Machines
• Concise representation of complex control
• Graphical and textual languages

35
Hardware Languages

• Goal specify connected gates concisely
• Originally targeted at simulation
• Discrete event semantics skip idle portions
• Mixture of structural and procedural modeling

36
Hardware Languages

• Verilog
• Structural and procedural modeling
• Four-valued vectors
• Gate and transistor primitives
• Less flexible, succinct
• VHDL
• Structural and procedural modeling
• Few built-in types Powerful type system
• Fewer built-in features for hardware modeling
• More flexible, verbose
• SystemC 1.0, Cynlib VHDL/Verilog in C

37
VHDL

• Designed for everything from switch to
  board-level modeling and simulation
• Also has event-driven semantics
• Fewer digital-logic-specific constructs than
  Verilog
• More flexible language
• Powerful type system
• More access to event-driven machinery

38
VHDL Entities and Architectures

• Entity interface of an object
• entity mux2 is
• port(a,b,c in Bit d out Bit)
• end
• Architecture implementation of an object
• architecture DF of mux2 is
• begin
• d lt c ? a b
• end DF

39
VHDL Architecture contents

• Structural, dataflow, and procedural styles
• architecture ex of foo is
• begin
• I1 Inverter port map(a, y)
• foo lt bar baz
• process begin
• count count 1
• wait for 10ns
• end

40
VHDL Communication

• Processes communicate through resolved signals
• architecture Structure of mux2 is
• signal i1, i2 Bit
• Processes may also use local variables
• process
• variable count Bit_Vector (3 downto 0)
• begin
• count count 1

41
VHDL The wait statement

• Wait for a change
• wait on A, B
• Wait for a condition
• wait on Clk until Clk 1
• Wait with timeout
• wait for 10ns
• wait on Clk until Clk 1 for 10ns

42
SystemC 1.0
43
SystemC 1.0 Semantics

• Multiple synchronous domains
• Synchronous processes run when their clock
  occurs.
• Asynchronous processes react to output changes,
  run until stable

Sync.
Clock
Async.
44
Simultaneous Events in DE
t
Fire B or C? Assume B fires first
t
A
B
C
Assume B has 0 delay
Assume B has delta delay
t
t
t
t
A
B
C
A
B
C
Fire C once? or twice?
Fire C twice
Still have problemif B is split into
two(functional behavior changes)!!!
45
Summary of HDL and Discrete Events

• Totally ordered time stamps
• DE simulator maintains a global event queue
• E.g. Verilog, VHDL, SystemC, OpNet
• Drawbacks
• Global event queue gt tight coordination between
  parts
• Simultaneous events gt non-deterministic behavior
• Some simulators (VHDL, SystemC) use synchronous
  delta delay to prevent non-determinism
• Used for all sorts of performance analysis(from
  system to gate level)

46
Software Languages

• Goal specify machine code concisely
• Sequential semantics
• Perform this operation
• Change system state
• Raising abstraction symbols, expressions,
  control-flow, functions, objects, templates,
  garbage collection

47
Software Languages

• C
• Adds types, expressions, control, functions
• C
• Adds classes, inheritance, namespaces, templates,
  exceptions
• Java
• Adds automatic garbage collection, threads
• Removes bare pointers, multiple inheritance
• Real-time operating systems
• Add concurrency, timing control

48
Software Methodology

• C
• Divide into variables and functions
• C
• Divide into objects (data and methods)
• Java
• Divide into objects, threads
• RTOS
• Divide into processes, assign priorities

49
Java Simplified C

• Simple, high-level C-like language
• Standard type sizes fixed (e.g., int is 32 bits)
• No pointers object references only
• Automatic garbage collection
• No multiple inheritance except for interfaces
  method declarations without definitions

50
Java Threads

• Threads have direct language support
• Objectwait() causes a thread to suspend itself
  and add itself to the objects wait set
• Sleep() suspends a thread for a specified time
  period
• Objectnotify(), notifyAll() awakens one or all
  threads waiting on the object
• Yield() forces a context switch

51
Java Locks/Semaphores

• Every java object has a lock that at most one
  thread can acquire
• Synchronized statements or methods wait to
  acquire the lock before running
• Only locks out other synchronized code
  programmer responsible for ensuring safety
• Public static void abs(int values)
• Synchronized (values)
• For (int i 0 I lt values.Length I)
• If (valuesi lt 0)
• Valuesi -valuesi

52
Java Thread Example
synchronized acquires lock

• Class OnePlace
• Element value
• public synchronized void write(Element e)
• while (value ! null) wait()
• value e
• notifyAll()
• public synchronized Element read()
• while (value null) wait()
• Element e value value null
• notifyAll()
• return e

wait suspends thread and releases lock
notifyAll awakens all waiting threads
53
Java Thread Scheduling

• Scheduling algorithm vaguely defined
• Made it easier to implement using existing thread
  packages
• Threads have priorities
• Lower-priority threads guaranteed to run when
  higher-priority threads are blocked
• No guarantee of fairness among equal-priority
  threads

54
Summary

• Multiple models and languages are essential for
  high-level design
• 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