OSIP: Operating System Application Specific Instruction Set Processor
Motivation and Introduction
With the advent of heterogeneous Multiprocessor Systems on Chip (MPSoCs), the complexity of software development has become one of the biggest problems embedded designers have been faced with. Apart from the challenges of programming itself, distributing the application to processors and providing efficient low-overhead run-time scheduling is one of the key issues that have to be solved in future platforms. Several solutions are currently being proposed, but most of them, coming from the high performance community, rely on highly hierarchical software stacks and distributed Operating Systems that add a time and energy overhead that cannot be tolerated in embedded systems targeting next generation devices. To reduce the overhead incurred in SW solutions, some academic projects have focused on providing HW support. These solutions, although very efficient, are typically dedicated to specific platforms, are expensive in terms of area and integration cost, and lack flexibility.
A joint project between the ISS and SSS chairs has been defined to seek for alternative solutions to this problem. In our approach we combine the efficiency of dedicated HW solutions with the flexibility and ease of use of SW solutions. This was accomplished by designing an Application Specific Instruction Set Processor (ASIP) tailored to provide support for mapping and scheduling in heterogeneous MPSoCs. We call this processor Operating System asIP (OSIP), since it offloads administrative tasks from the MPSoC cores. Additionally, a light weight SW stack is provided that eases programming for MPSoCs.
The OSIP Concept and Architecture
When designing OSIP, a flexible approach for task mapping, scheduling and synchronization was sought. This approach should be aware of the presence of several processors of different classes (e.g. RISC, DSP, ASIPs) and applications of different natures (e.g., hard/soft real time, best effort). To support all this, a hierarchical scheduling approach was selected as the OSIP underlying concept. The principle of hierarchical scheduling and mapping is illustrated in Figure 2. Leaf nodes represent task queues where individual tasks are scheduled according to local scheduling policies. Interior nodes implement schedulers and can be used to differentiate among the various application classes. From the root node, a task can be mapped to any processor in the corresponding class. Processing classes are user-defined and can be determined by physical architectural features (e.g. RISC, DSP, VLIW, HW accelerator) or by logical features (e.g. PEs sharing some cache level).
With an implementation of the scheduling behavior described above, OSIP was designed following a typical ASIP design flow with the Processor Designer tool from Synopsys. The resulting architecture, a 6 stage pipelined RISC, is shown in Figure 3. It includes a slave register interface to receive commands from the processors in the MPSoC. The master interface on the right hand side is used to trigger interrupts, which is the mechanism used by OSIP to schedule tasks on the processing elements. Several instructions were devised that accelerate the scheduling process. These includes, for example, instructions for traversing task queues and the scheduling hierarchy.
System Level View
OSIP can be easily integrated in an MPSoC by making the register interface visible from the processing elements and re-routing their interrupt signals. From the SW integration point of view, a lightweight abstraction layer composed of a set of Application Programming Interfaces (APIs) is provided. This APIs allow the programmer to write code independent of the platform and without necessarily knowing on which processing element the code would run.
A functional model based on SystemC was written for OSIP that allows faster system simulation. Both the functional model and the real ASIP were integrated in a virtual platform environment that includes up to 16 ARM926EJ-S processors, an AMBA AHB bus and several peripherals (see Figure 4). The virtual platform was modeled with Synopsys Platform Architect. This allowed to benchmark and to analyze the overhead incurred by scheduling with OSIP and compare it against pure SW solutions. The average overhead was of around 900 cycles, which is one order of magnitude smaller than typical SW Operating Systems.
Figure 4 OSIP in Virtual Platforms. a) Virtual Platform. b) Virtual platform simulation for benchmarking
For more information about the OSIP technology please refer to the list of publications.
- Analysis of communication architectures for OSIP based systems.
- Integration of OSIP into heterogeneous platforms.
- Integration of OSIP into the MAPS framework for MPSoC programming. This includes automatic code generation from dataflow languages to OSIP-based platforms.
Jeronimo Castrillon, Diandian Zhang, Torsten Kempf
Ispas, A., Schneider, C., Ascheid, G. and Thomä, R.: Analysis of Local Quasi-Stationarity Regions in an Urban Macrocell Scenario, in Proc. 71st IEEE Veh. Tech. Conf. (VTC 2010-Spring)(Taipei, Taiwan), May. 2010, 10.1109/VETECS.2010.5494098 ©2010 IEEE
Silvano, C., Fornaciari, W., Crespi Reghizzi, S., et. al., and Kempf, T.: 2PARMA: Parallel Paradigms and Run-time Management Techniques for Many-core Architectures, in IEEE Annual Symposium on VLSI( Lixouri, Kefalonia - Greece), pp. 494-499, Jul. 2010, ISBN: 978-0-76954-076-4
Gong, X., Ispas, A. and Ascheid, G.: GLRT-Based Cooperative Spectrum Sensing for Cognitive Radio with Rank Information, in Proc. IEEE Workshop on Statistical Signal Process.(Nice, France), Jun. 2011, 10.1109/SSP.2011.5967780 ©2011 IEEE