Simulation Based Deadlock Analysis for System Level Designs

1
Simulation Based Deadlock Analysis for System
Level Designs

• Xi Chen, Harry Hsieh
• University of California, Riverside
• Abhijit Davare, Alberto Sangiovanni-Vincentelli
• University of California, Berkeley
• Yosinori Watanabe
• Cadence Berkeley Laboratories

Contacts URL www.cs.ucr.edu/xichen, Email
xichen_at_cs.ucr.edu
DAC June 2005
2
Outline

• Introduction and motivations
• Synchronization mechanism in Metropolis
• Blocking dependency analysis for deadlock
• Case studies
• Future Work

3
System Level Design

• RTL level design is no longer efficient for
  systems containing tens of millions of gates
• System level design becomes necessary

10,000
100,000
1,000
10,000
100
1000
Productivity (K) Trans./Staff-Mo.
Logic transistors per chip (in millions)
10
100
IC capacity
1
10
0.1
1
Productivity
0.01
0.1
0.001
0.01
1981
1987
1993
1999
1983
1985
1989
1991
1995
1997
2001
2003
2005
2007
2009
4
System Level Design (cont.)
System Function
System Architecture

• Separate the various aspects of a design
• Function and architecture
• Communication and computation
• Advantages
• Reuse of design components
• Reduce overall complexity
• Ease debugging

Mapping
Function on Architecture
Implementation of System
Keutzer, TCAD00
5
Deadlock Detection Background

• Extensively studied in operating systems,
  database systems and communications
• Existing deadlock detection or prevention
  techniques only work for these particular systems
  (e.g. OS and DB) Coffman71, Knapp87,
  Peterson83, Sfinghal89
• Formal verification works for abstract protocols
  or models Godefroid93, Holzmann97,
  McMillan93
• State explosion limitation for complex systems
• Reducing design flexibility
• Abstract protocols are not easy to follow

6
Deadlock Detection in Simulation

• Using general assertion languages to catch
  deadlock (available method)
• Possible but not easy
• Not trivial to specify deadlock situations in
  complex models
• Deadlock problems are hard to predict and analyze

• More efficient to automatically check such
  undesirable behaviors with built-in monitors (our
  approach)

7
Outline

• Introduction and motivations
• Synchronization mechanism in Metropolis
• Blocking dependency analysis for deadlock
• Case studies
• Future Work

8
Tool for System Level Design
Design Constraints
Metropolis Project
Function Specification
Architecture Specification

• Heterogeneity of modern embedded systems
• Representation mechanism
• Metropolis Meta-Model
• Design methodology
• multiple levels of abstraction
• High-level abstraction can be refined further
  through the use of
• Constraints
• Annotations
• Schedulers
• Structural transformation

• Metropolis Infrastructure
• Design Methodology
• Base tools
• -- Design imports
• -- Simulation
• Metamodel of Computation

Metropolis point tools Synthesis/Refinement
Metropolis point tools Analysis/Verification
(Metropolis Project Team)
9
Metropolis Meta-Model

• Process defines computation and generates a
  sequence of events
• Medium defines states and methods for
  inter-process communication
• Coordination constraints over concurrent actions

10
Synchronization in Metropolis

• await statements for non-deterministic critical
  sections
• Example
• await
• (foo() interface00 interface01)
• critical_section0
• (true interface10, interface11 interface10,
  interface11)
• critical_section1

• Other processes may also be blocked by await
  statements through setlist

11
Synchronization in Metropolis (cont.)

• synch constraints for function-architecture
  mapping
• Example synch(e0 gt e1 e2 equalities )

Function Netlist
Architecture Netlist
P1
mP0
P2
e0
e1
e2
MapNetlist
12
Outline

• Introduction and motivations
• Synchronization mechanism in Metropolis
• Blocking dependency analysis for deadlock
• Case studies
• Future Work

13
Deadlock Definition
Definition A deadlock is a situation where two
or more processes are blocked in execution while
each is waiting for some conditions to be changed
by others.
14
Dynamic Synchronization Dependency Graph
Blocking dependency
A process is blocked by a synch synch(e0 gt e1
e2)
A process is blocked by 2 synchs
simultaneously synch(e0 gt e1) synch(e0 gt
e2e3e4)
15
Dynamic Synchronization Dependency Graph (cont.)

• A process is blocked by an await
• await
• (foo() intf00 intf01) critical_section0
• (true intf10 intf11 intf10
  intf11)critical_section1

16
Deadlock Detection Algorithm

• A cycle detection algorithm for DSDG considering
  and-, or-, and guard-dependencies

Find all the simple cycles in the graph
For each simple cycle
YES
only contains processes and and-dependencies ?
A Deadlock
NO

• Guard-dependencies are treated the same as
  or-dependencies for now
  further refined analysis in the
  future
• Identify all the deadlocks

find and check other cycles starting from
or-dependencies
17
Deadlock Analysis Methodology
System Level Design
Compilation
Simulation Model
Simulation Vectors
Deadlock Analysis
Simulation
Blocking Dependencies
Simulation Traces
Analysis Report
18
Deadlock Analysis Methodology
System Level Design
Compilation
Simulation Model
Deadlock Analysis
Simulation Vectors
Simulation
Blocking Dependencies
Simulation Traces
Analysis Report
19
Implementation

• DSDG is built and updated dynamically during the
  simulation
• Whenever a process is blocked, the deadlock
  detection algorithm is invoked
• A history of DSDGs can be kept as a trace to help
  identify the cause of the deadlock
• Performance impact on the simulator is small

20
Outline

• Introduction and motivations
• Synchronization mechanism in Metropolis
• Blocking dependency analysis for deadlock
• Case studies
• Future Work

21
Case Study Function Model for Video Processing
RESIZE design complexity 9000 lines of source
code, 22 concurrent processes, 300 communication
media
22
Case Study Function Model for Video Processing
(cont.)

• The simulation will go on and produce thousands
  of lines of traces quickly even after deadlock
  occurs
• Catch the deadlock within 2 minutes of simulation
• Dependency graph is generated to help identify
  the problem

23
Case Study Function-Architecture Mapping

• Design complexity 5900 lines of source code, 8
  concurrent processes, 16 communication media

24
Future Work

• To analyze other interesting properties, e.g.
  starvation, process interaction
• To integrate the approach into other simulation
  environments, e.g. SystemC
• To quantitatively investigate the performance
  impacts on simulators

25
Thank You