S(o)OS Deliverables

Print

S(o)OS D2.2 First Implementation Set: Hardware - Introduction

The main objective of WP2 is to develop abstraction mechanisms to express both the functionality and the non-functional properties of hardware architectures in a semantic way. Chapter II introduces the C╬╗aSH hardware description environment that focusses on the functional aspects of hardware architectures. It lifts the design process of hardware to a higher level of abstraction than offered by traditional tools and design environments. It allows us to capture and describe complexity of contemporary and future architectures (far) more easily than possible in current design environments.
Moving to Chapter III, we go into dealing with non-functional, derived, aspects of hardware and processor architectures. We discuss a modelling environment that allows us to describe the rough structure of a processor architecture. We can use the same environment to query (non-functional) properties of the processor models, such as whether they are superscalar. We developed a new modelling environment as there was no existing work that allows for easy capability extraction.
Using a hierarchical model as opposed to flat data to encode these capabilities is both less error-prone and more general (as we can derive many capabilities through queries as opposed to hard-coding them). We also go into detail how the capability information can be used for code instrumentation.
As we need to make the information of the hardware architecture and capabilities available across nodes (for efficient code/application distribution) in heterogeneous large-scale dynamic environments, we need to categorize information relevant at the different hierarchies. This problem is tackled in Chapter IV. As the systems are potentially highly dynamic (ephemeral connectivity of mobile devices), capability information might have to be transmitted frequently, warranting the need to reduce overhead of capability information exchange. Also for this purpose a hierarchical capability information encoding makes sense, as we can reduce capability information being sent to that which is relevant for the specific level in the hierarchy.
Having to analyse the impact of our design choices relating to the code mapping we do based on capability information (Chapter III), and not having future hardware architectures available, we choose to simulate our systems. Because one of the major aspects of future processing systems [8] is due to the network connecting all the cores, we chose to start our focus of a simulator there. Chapter V discusses the MCoreSim NoC-simulator [9] we are developing based on the well-known
OMNeT++ network modelling and simulation framework. We intend to incorporate the topology descriptions from D3.2 [7] into future versions of the MCoreSim framework.

Download

S(o)OS D2.2 First Implementation Set: Hardware

Thursday the 24th. Sponsored under FP7-ICT-2009.8.1, Grant Agreement No. 248465. This website is monitored by Google Analytics. IP addresses are anonymized.
Copyright 2012

©