A Case Study of System Level Specification and Software Synthesis of Multimode Multimedia Terminal

1
A Case Study of System Level Specification and
Software Synthesis of Multi-mode Multimedia
Terminal

• Seoul National University
• CAP Laboratory
• Dohyung Kim, Minyung Kim, Soonhoi Ha

2
Content

• Introduction
• System level specification
• PeaCE approach
• Related work
• Conclusion

3
System Level Design

• Design Procedure
• System behavior specification
• Functional simulation
• Design space exploration architecture decision
• Design verification
• Synthesis of software, hardware and interface
• Hardware/software Codesign Methodology
• Target architecture may consist of processors and
  hardware components
• Concurrent design of hardware architecture and
  software code

4
Motivational Example

• Multi-mode Multimedia Terminal Example
• Three different modes of operations with multiple
  tasks
• Video phone H.263 encoder/decoder and G.723
  encoder/decoder
• Divx player H.263 decoder and MP3 player
• MP3 player

Mode Task control
User control
5
Motivational Example

• Multi-mode Multimedia Terminal Example
• Diverse execution types of tasks
• Periodic, sporadic, function

periodic
function
H.263 decoder
Demux
sporadic
Internet
G.723 decoder
Network IF
H.263 encoder
mic
Mux
G.723 encoder
camera
6
Motivational Example

• Multi-mode Multimedia Terminal Example
• Dynamic execution rate between tasks
• Streaming of data results in dynamic rate
  connections

H.263 decoder
Demux
Internet
G.723 decoder
Network IF
H.263 encoder
mic
Mux
G.723 encoder
camera
streaming of data
dynamic rate connection
7
Content

• Introduction
• System level specification
• PeaCE approach
• Related work
• Conclusion

8
System Design Procedure and Issues
System Function
System Microarchitecture
mapping
Function on Microarchitecture
Refine
Implementation of system
9
Where to start?

• System Level Specification
• How to specify the system functionality?
• Issues
• User friendliness
• Executable / simulatable
• Flexible enough to specify system behavior
• Implementation independence
• Design validation / error detection capability
• Design Maintenance and collaboration
• Well defined path to synthesis

10
(Informal) Programming in C, C?

• Not Good For Initial Specification. Why?
• Imperative Language not easy to exploit
  concurrencyNot good for HW implementation
• Simulation based verification
• Not easy to detect semantic error
• Not easy to debug and maintain the codeCode
  reuse is difficult
• Not easy to cooperate with others
• Productivity is low

11
We argue for Formal Specification

• CASE tool for software design
• Coding rule for design maintenance and easy
  debugging
• Software design is a subset of system design
• Precise and unambiguous semantics
• Functional specification f (input, output,
  state)
• Well defined function composition
• Properties and Constraints

port
f()
g()
Module or actor (function)
12
Advantages of Formal Specification

• Amenable to property validation, simulation, and
  analysis by computers
• Top-down refinement from specification to
  implementation
• Design reuse and maintenance
• Described what to do design space exploration
• Productivity is high

13
Weaknesses of Formal Specification

• Barrier to learn a new rule of specification
• will be overcome if benefit is large (ex CASE
  tools)
• Limited expression capability
• Can express all system behaviors (specially for
  dynamic behavior)?
• Inefficient synthesis result
• Performance comparison with manually designed
  (optimized) result
• Current status
• There exist some tools for a specialized set of
  applications.
• There exist tools for co-simulation, but not for
  co-synthesis yet.

14
Challenges of Target Application

• System level specification
• How to specify and analyze multiple modes of
  operations?
• Diverse execution semantics of tasks
• Periodic (time-driven), sporadic (event-driven)
  or function (data-driven)
• Diverse port semantics
• Dynamic rate port
• FIFO queue type (data flow), buffer type (control
  flow)
• Formal models of computation
• Well defined path to efficient synthesis

15
Content

• Introduction
• System level specification
• PeaCE approach
• Related work
• Conclusion

16
PeaCE Approach

• Formal Models of Computation for Algorithm
  Specification
• Signal processing tasks synchronous dataflow
  (SDF)
• Control tasks finite state machine (FSM)
• Implicit Specification for Control Flow
• Specified by action scripts in FSM
• Control tasks supervise behavior of signal
  processing tasks
• Task-level Specification Model
• Coordination model on top of SDF and FSM
• Extended task execution semantics
• Extended port semantics

17
Synchronous Dataflow Representation of H.263
Encoder

• Intuitive representation similar to algorithm
  flow-chart
• suitable for multimedia/DSP applications
• Block reuse possibility
• Implementation Independence

1
1
Motion Estimation
Distributor
Macro Block Encoding
Variable Length Coding
Read From Device
1
99
1
1
1
99
1
1
Macro Block Decoding
Motion Compensation
Write To Device
1
1
99
1
1
Delay initial sample
18
Finite State Machine (FSM)

• Well-known semantics
• Rich analytical properties
• Reachability analysis, liveness

System Under Design
power_on
timer
time-out
a
19
Extended Models of Computation

• Fractional Rate Dataflow (FRDF)
• Permit a fractional rate between dataflow blocks
• Reduce buffer requirement of SDF models
• Synchronous Piggybacked Dataflow (SPDF)
• Allow global states in SDF models
• Support dynamic constructs like if-then-else
  and for constructs
• Flexible Finite State Machine (fFSM)
• Overcome state explosion problem
• Use concurrency, hierarchy and variable state

20
H.263 Decoder using Extended SDF
GST
for
if
n
X
1
1/n
1/n
IDCT
DQ
ZigZag scan
MUX
MB to block
0
header parser
PB
MC
PB
1
X
0
copy 0
21
Implicit Specification for Control Flow

• Support different modes of operations
• Change a mode of operation to another
• Deliver initial parameters or control parameters
• Handling exceptions
• Specify action scripts in a state of FSM model

task
toggle
start task
stop task
start
stop
Reader
Player
toggle
toggle
22
Supported Action Scripts in FSM model
23
Control Flow Specification for DIVX Player
suspend1
H.263 Decoder
divxread
divx run
divx suspend
AVI Reader
MP3 Decoder
script in divsuspend suspend divx
script in divxrun run divx
exit
start1
divx
scripts in divx deliver ui filename divxread
filename run divx
stop1/ tostart1
divx
text4
script in divxstop stop divx
exitDivx 1
divxstop
start
script in exit state get divx exit exitDivx
tostart1
24
Task-Level Specification Model

• Task-level specification bridges gaps between
  formality and flexibility
• Maintain formality of SDF and FSM models
• Extend expression capability
• Definition of task-level specification model
• Tasks which are specified by SDF or FSM models
• Explicit connections which indicate data flow
  between tasks
• Implicit connections by action scripts which
  indicate control flows between tasks
• Additional specification for task execution types
  and port semantics

25
Specification of Task Execution Type

• Function task
• Basic execution type of SDF and FSM model
• When data is available, it starts an iteration
  and sends output data
• Periodic task
• Explicitly specify period at the task
• After triggered by time, it is same as function
  task
• Sporadic task
• Explicitly specify interrupt conditions at the
  task
• After the condition is met, it is same as
  function task

26
Motivational Example

• Multi-mode Multimedia Terminal Example
• Diverse execution types of tasks
• Periodic, sporadic, function

periodic
function
H.263 decoder
Demux
sporadic
Internet
G.723 decoder
Network IF
H.263 encoder
mic
Mux
G.723 encoder
camera
27
Port Semantics in Task-level Specification

• Port properties
• data rate static or dynamic
• data size static or variable
• port type queue or buffer
• Automatic translation for basic ports in SDF and
  FSM models
• Explicit specification for dynamic rate port in
  SDF models
• Blocked when data is not available
• Port semantics
• Dynamic-rate static-size queue
• Dynamic-rate variable-size queue

28
Motivational Example

• Multi-mode Multimedia Terminal Example
• Dynamic execution rate between tasks
• Streaming of data results in dynamic rate
  connections

H.263 decoder
Demux
Internet
G.723 decoder
Network IF
H.263 encoder
mic
Mux
G.723 encoder
camera
streaming of data
dynamic rate connection
29
Automatic Translation for Basic Ports
30
Layered Software Structure

• Virtual operating system (OS) API
• Architecture and design step independent API to
  application tasks
• Operating system wrapper
• Implementation of virtual OS API on the target
  architecture

Application tasks
Communication API
Task Management API
Interrupt Service API
Virtual Operating System API
Operating System Wrapper
Inter-process Communication (IPC)
Scheduler
Task Management
Interrupt Handling
Target Architecture
31
Behavioral Synthesis from Task-level
Specification Model

• Task code generation from SDF and FSM models
• Synthesis path is well defined
• Accompany with task types and port properties
• Based on virtual operating system API
• System code generation from task-level
  specification
• Initialization codes for data structures of task,
  port and buffer
• main codes to create tasks and start a scheduler

32
An Operating System Wrapper on POSIX Thread

• Operating system wrapper on POSIX thread
• Inter-process communication
• Interrupt service routine
• Non-preemptive scheduler
• Performance profiler

Application tasks
Communication API
Task Management API
Interrupt Service API
Inter-Process Communication
Scheduler (non-preemptive)
Interrupt Handling
Profiler
Task Management
POSIX Thread
33
Multi-mode Multimedia Terminal Example
34
System Level Specification
Video Phone task
H.263 Encoder
H.263 Decoder
TCP/IP
G.723 Encoder
G.723 Decoder
Top-level schematic
Three mode schematics Each mode is a multi-task
application.
Mode control FSM
35
Performance Profile
36
Content

• Introduction
• System level specification
• PeaCE approach
• Related work
• Conclusion

37
Related Works (1)

• SDL, CFSM
• control oriented reactive system
• not appropriate for signal processing tasks
• ACFSM, TinyGALS, Kahn process network
• single computation model for both control and
  signal processing tasks
• doubtful whether it satisfies all the
  requirements of system level specification like
  MMMT system

38
Related Works (2)

• Ptolemy II
• hierarchical composition of diverse models of
  computation
• no result on automatic software synthesis

XXX domain
FSM domain
YYY domain
E
E
G
G
F
F
Modal model
39
Related Works (3)

• STATEMATE
• Control model (statechart) specifies the system
  behavior (activity chart) manual specification
  is needed for complicated task schedules

40
Related Works (4)

• SystemC, SpecC based design
• Language extension approach
• A network of function blocks
• no formal semantics in block specification

41
Conclusion

• Shows validity of system-level (software) design
  of complicated multimedia embedded application
• Heterogeneous specification maintain formality
  but extend expression capability
• extended formal models of computation for task
  behavior
• task-level specification model
• Layered software structure
• Retargetable for different target architectures
  and system softwares
• Future Work
• HW/SW co-design work design space exploration
  and cosimulation

42
Thank you.