A Platform-based Design Flow for Kahn Process Networks

1
A Platform-based Design Flow for Kahn Process
Networks

• Abhijit Davare
• Qi Zhu
• December 10, 2004

2
Overview

• Mapping Overview
• Design Flow
• Reconfiguration
• Allocation
• Initial Sizing
• Deadlock Detection and Resolution
• Common Semantic Domain
• Future work

3
Overview
Function
Architecture

• A design methodology for Platform-based Design
• Within this context, focus on the specific
  problem of mapping KPN applications to
  architectural platforms

Mapping
Function
Architecture
Second Contribution
Function in CSD
Architecture in CSD
First Contribution
Mapping
4
KPN Design Flow
Reconfiguration

• Four clearly defined steps
• Tractable optimization problems
• Amenable to designer intervention
• Leverage prior work from a variety of different
  research communities
• Heuristics developed at each step

Functional Model
Architectural Model
Allocation of Computational Communication
Resources
Initial Sizing of CommunicationChannels
Runtime Deadlock Detection Resolution Algorithms
5
Step 1 Reconfiguration

• Manipulate the functional and architectural
  models
• Behavior must remain the same
• Cost metrics may change
• Architectural Reconfiguration
• Control the number of processors in the platform
• Number of buses and topology
• Functional Reconfiguration
• Clustering of processes based on the concurrency
  limit of architecture model
• Sort the pairs of processes by (cost of internal
  communication cost of external communications)
• Keep merging the pair with largest cost until
  satisfies the architecture platform
• Not applicable to Kahn processes in general

6
Step 2 Allocation Covering Problem

• Allocates computational and communication
  resources from architectural model to functional
  model
• All services used by the functional model must be
  provided by the architectural model
• Matching of type
• Cost function defines expense of a particular
  mapping with respect to a metric of interest
• Latency or Energy

7
Step 2 Allocation Estimating Service Cost

• Typically, an architectural model is defined in
  terms of components
• Components provide/use services with different
  costs
• Defined in terms of quantity managers in
  Metropolis
• Costs known for components, but not for
  architectural model as a whole
• Not just applicable to current design flow
• Model defined for composing the cost of services
  from components

8
Step 3 Initial Sizing

• Assigning memory resources to channels
• Allocation step provides resource constraints
• Assign memory statically such that constraints
  are satisfied and latency is reduced
• Using simulation, get the channel size
  distribution and total data throughput for each
  channel
• Assign memory
• Measure the weight of channels by distribution
  and throughput
• Greedily adjust the channel size with total
  memory constraint

Probability
Size
9
Step 4 Deadlock Detection

• Identify global or local artificial deadlock
  situations
• Global deadlock occurs when all processes are
  blocked
• Local deadlock occurs when processes in a
  directed or undirected cycle are blocked
• Synthesize a deadlock manager for the system
  that checks if deadlock situations have
  developed
• Tag the write-blocked channels

10
Step 4 Deadlock Resolution

• Allocate memory from a shared pool to
  write-blocked channels involved in deadlock
• Each channel is prioritized with a worthiness
  metric
• How deserving of additional memory if it is
  write-blocked and involved in a deadlock
• If no more memory is available in shared pool,
  then attempt to reclaim previously allocated
  memory from channels that are not using it
• In general, finite memory resources imply that
  some artificial deadlocks cannot be resolved

11
Modeling Platform

• Function model PIP application
• 26 processes and 57 channels
• Architecture model Heterogeneous Multiprocessor
  Platform
• 4 CPUs, each with a local memory
• One global bus and one global memory
• Described in Metropolis framework

12
Semantic Domains

• A semantic domain is constructed by some
  elemental semantic concepts
• A model can be described in one semantic domain
  if we can reason about the behavior of the model
  by only considering the elements in this semantic
  domain
• A semantic domain S is said to be the ancestor of
  another semantic domain T if all the elements in
  T are constructed by the elements contained in S
• There exists a domain R called Meta-domain, which
  is the ancestor of all the other semantic
  domains. It has the richest expressiveness.
• The semantic domains are not restricted to only
  involve the well-known models of computation in
  the literature. They are suitable for design
  space exploration, but maybe unnatural from a
  modeling standpoint.

13
Common Semantic Domain (CSD)

• Suppose X is the semantic domain of function and
  Y is the semantic domain of architecture common
  semantic domain is the common ancestor of X and Y
  in the lattice of semantic domain.

Meta-Domain
Finer Abstract Domain
Common Semantic Domain
Finer Abstract Domain


Finer Abstract Domain
Finer Abstract Domain
Semantic Domain of Architecture

Finer Abstract Domain
Semantic Domain of Function

14
Another view of CSD
Meta-Domain
Common Semantic Domain
Function Domain
Architecture Domain
15
Use CSD in KPN Design Flow

• Common semantic domain for our project
• Computational actions
• Execution actions taken by a single thread
• Communication actions
• Blocking read actions to FIFOs
• Non-blocking write actions to FIFOs
• Both functionality in function model and services
  provided by architecture model can be described
  by above elements
• Restrict the behavior of architectural model so
  that it can be described with a CSD lower in the
  lattice

16
Future work

• Design Flow
• Better heuristics for each step
• Test on a set of case studies
• Common Semantic Domains
• More formal definition in terms of constraints on
  usage of primitive elements of a Meta-domain
  (e.g. Tagged Signal model)
• Identification of useful domains for solving
  mapping problems
• What types of analysis are necessary?
• What are natural modeling mechanisms?
• How easy is it to move up/down in the lattice?