A Platform-based Design Flow for Kahn Process Networks Abhijit Davare Qi Zhu December 10, 2004

6/28/ Overview Mapping Overview Design Flow –Reconfiguration –Allocation –Initial Sizing –Deadlock Detection and Resolution Common Semantic Domain Future work

6/28/ Overview FunctionArchitecture Mapping Function Mapping Architecture Function in CSD Architecture in CSD A design methodology for Platform-based Design Within this context, focus on the specific problem of mapping KPN applications to architectural platforms First Contribution Second Contribution

6/28/ KPN Design Flow 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 Communication Channels Runtime Deadlock Detection & Resolution Algorithms Reconfiguration

6/28/ 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/28/ 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

6/28/ 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 i1i1 i2i2 c 1 (i 1, i 2 ) c 2 (i 1, i 2 ) f 1 (i 1, i 2 )

6/28/ 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 SizeProbability

6/28/ 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

6/28/ 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

6/28/ 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

6/28/ 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.

6/28/ Common Semantic Domain (CSD) Meta-Domain Finer Abstract Domain … … … … Semantic Domain of Function Semantic Domain of Architecture Common Semantic Domain 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.

6/28/ Another view of CSD Meta-Domain Architecture Domain Function Domain Common Semantic Domain

6/28/ 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

6/28/ 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?