Single chip multi-processor architecture. 

Context in source publication

Context 1

... show the benefits of validating the model accuracy on a virtual platform for the purpose of defin- ing and refining an effective allocation and scheduling methodology on MPSoCs. The paper is organized as follows: the application is described in section 2 and commented in section 3. The models developed are introduced in section 4 and simplifying assumptions are motivated in section 5, explaining why they could affect the quality of the overall solution. Experiments are presented in section 6. Related works and a discussion on future perspec- tives conclude the paper. Recent advances in very large scale integration (VLSI) of digital electronic circuits have made it possible to integrate more than a billion of elementary devices onto a single chip, thereby enabling the de- velopment of low-power, low-cost, high-performance single-chip multi-processors. These devices, called multi-processor systems-on-chip (MPSoCs), are finding widespread application in embedded systems (such as cellular phones, automotive control engines, etc.) where they are employed as special-purpose computing engines. In other words, once deployed in field, they always run the same application, in a well- characterized context. It is therefore possible to spend a large amount of time for finding an optimal allocation and scheduling off-line and then deploy it on the field. For this reason, many researchers in digital design automation have explored complete approaches for allocating and scheduling pre-characterized workloads on MPSoCs [18], instead of using on-line, dy- namic (sub-optimal) schedulers [5, 4]. The multi-processor system we consider consists of a pre-defined number of distributed computation nodes, as depicted in Figure 1. All nodes are assumed to be homogeneous and made by a processing core and by a tightly coupled local memory. This latter is a low access cost scratchpad memory, which is commonly used both as hardware extension to support message passing and as a storage means for computation data and processor instructions which are frequently accessed. Unfortunately, the scratchpad memory is of limited size, therefore data in excess must be stored externally in a remote on-chip memory, accessible via the bus. The bus for state-of-the-art MPSoCs is a shared communication channel, and serialization of bus access requests of the processors (the bus masters) must be car- ried out by a centralized arbitration mechanism. The bus is re-arbitrated on a transaction basis, based on several policies (fixed priority, round-robin, latency- driven, etc.). A task graph representation of the target application is input to our methodology. For each node/task, the worst case execution time (WCET) is specified and plays a critical role whenever application real time (RT) constraints (expressed here in terms of minimum required throughput) are to be met. In fact, tasks are scheduled on each processor based on a time-wheel. The sum of the WCETs of the tasks for one iteration of the time wheel must not exceed time period RT (i.e., the minimum task scheduling period ensur- ing that throughput constraints are met), which is the same for each processor since the minimum throughput is an application (not single processor) requirement. However, since we are now developing an allocation and mapping methodology, we are primarily inter- ested in assessing the accuracy of our problem model. Therefore, we at first extracted the average (not the worst) case execution time of the tasks by means of functional simulation, since it is likely to better match the average task durations measured on the validation virtual platform. When our stable methodology will be used for design purposes, the WCET should be used instead, not to violate timing requirements. Each task also has three kinds of memory requirements. Program Data : storage locations are required for computation data and for processor in- structions. They can be allocated either on the local scratchpad memory or on the remote on-chip memory. Internal State : when needed, an internal state of the task can be stored either locally or remotely. Communication queues : the task needs queues to transmit and receive messages to/from other tasks, eventually mapped on different processors. In the class of MPSoCs we are considering, such queues should be allocated only on local memories, in order to implement an efficient inter-processor communication mechanism. Finally, the communication requirements of each task are automatically determined depending on the size of communication data and on the physical lo- cation of computation data in scratchpad or remote memory. The methodology proposed in this paper has been applied to a synthetic signal processing pipeline. Functional pipelining is widely used in the domain of multimedia applications. Task parameters have been derived from a real video graphics pipeline processing pixels of a digital image. The proposed allocation and scheduling techniques can be easily extended to all applications using pipelining as workload allocation policy, and aim at providing system designers with an automated methodology to come up with effective solutions and cut down on design time. In the open literature, approaches to this kind of problems usually make very strong simplifying assumptions, like infinite number of processing units, zero time communication or unlimited memory capacity [16, 17, 1]. In addition, they often do not consider the real implementation of the solution they produce. We make simplifying assumptions to derive a problem model as well, but we also include a validation stage in our framework, in order to assess the impact of such approximations and verify the mismatch between off-line and on-line solution. An MPSoC virtual platform, called MP-Arm [14, 8], has been used for the validation of models and theoretical results, i.e. for implementing the on-line solution. There are three main reasons potentially originat- ing the mismatch between the off-line and the on-line ...