|Title||Linking run-time management with design space exploration at multiple abstraction levels|
|Publication Type||Conference Paper|
|Year of Publication||2010|
|Authors||Avasare, P., G. Vanmeerbeeck, C. Ykman-Couvreur, G. Mariani, G. Palermo, V. Zaccaria, and C. Silvano|
|Conference Name||Proceedings of the DATE'10 workshop on Designing for Embedded Parallel Computing Platforms: Architectures, Design Tools, and Applications|
|Conference Location||Dresden, Germany|
In present era of Multi-Processor System-on-Chip (MPSoC) embedded devices, to run multiple applications optimally (in terms of execution time and power consumption) is an enormous challenge. Embedded designers usually tackle this challenge by dividing it in two parts : at design-time Design Space Explorations (DSE) are performed to derive Pareto set of optimum operating points for each application and at run-time embedded device is monitored continuously to operate at one of the points in the derived Pareto set. Obviously run-time management relies heavily on accuracy of DSE. With growing complexity of embedded devices and with time-to-market pressures, at design-time, it is not trivial to derive the operating point Pareto set. On the other hand, at run-time, overhead introduced by a run-time management scheme should also not be high so as to minimally affect embedded device performance . We have developed techniques to tackle these embedded design issues. At design time, we use DSE with multiple simulators running at multiple abstraction levels to converge quickly to Pareto set of operating points. At runtime, to keep run-time overhead to a minimum, a hierarchical Runtime Resource Manager (RRM) is used with well-defined interfaces (services) between global and local resource managers. We applied our methodology on an embedded device having eight processor cores running multiple MPEG4 encoders. With our DSE methodology, we could derive Pareto set much quickly (as compared to full-space explorations). With our run-time schemes, overhead introduced by run-time manager was negligible.