| 8 | | In this context, the possibility to add as much processing resources as required for a given application, making not necessary to change it at all, is of must importance. The possibility of (re)configuring the radio terminal and/or the base station built by using different hardware from different providers requires the capability of adding (and removing) plug-and-play hardware to (from) the system. Different hardware topologies, configurations and, above all, assigned tasks impose restrictions on the integration of different hardware to construct software radio platforms. Due to these and the previously stated objectives, a multi-platform software abstraction layer and execution environment, PHAL-OE (Platform-Hardware Abstraction Layer Operating Environment), has been defined and designed to provide such features. |
| | 7 | One of the most relevant objectives in the process of defining a common framework to develop and deploy software radio applications is to eliminate platform (hardware and support software) dependencies. In this context, the possibility to add as much processing resources as required for a given application, making not necessary to change it at all, is of must importance. The possibility of (re)configuring the radio terminal and/or the base station built by using different hardware from different providers requires the capability of adding (and removing) plug-and-play hardware to (from) the system. Different hardware topologies, configurations and, above all, assigned tasks impose restrictions on the integration of different hardware to construct software radio platforms. All these objectives have pushed us to define and develop a multi-platform software abstraction layer and execution environment, PHAL-OE (Platform-Hardware Abstraction Layer Operating Environment), capable to provide such features. |
| 10 | | The context where the radio applications will be executed influences strongly the system performance. Radio appliactions are built by signal processing blocks most of them adquiring input signals and delivering output signals. Thus, the first step would be as simple as provide the mechanism to the application to deal with these input/output signals. These entities can be software or hardware entities, but in any case, abstracted from real implementation. The particularity of such interfaces between several entities is that is unknown at development time, and only during execution time all the entities will be unified and the entire application will be build. |
| | 9 | On the other side, from the point of view of radio application, it is commonly assumed hat such radio application is built based on a set of software modules (hardware or software based) that communicates among them. The common used terms denominates such modules as “objects”. Therefore each one of such objects are signal processing blocks, some of them with important requirements in terms of computing resources, that needs to acquire/deliver information from/to other objects. Thus, the first step would be as simple as provide the mechanism to the application to deal with these input/output interfaces. Nevertheless, one of the most relevant assumptions of PHAL-OE is that such interfaces between objects are unknown at object development time. Only at execution time all the required objects will be integrated and the entire radio application will be built. |
| 38 | | To illustrate the concept of PHAL-OE as a simple mechanism of information exchange lets consider, for example, the following simple piece of code of an execution thread of a general radio application: |
| 39 | | |
| 40 | | {{{ |
| 41 | | for ever { |
| 42 | | sample=read(MY_INPUT,BYTES_PER_SAMPLE); |
| 43 | | result=process_sample(sample); |
| 44 | | write(MY_OUTPUT,BYTES_PER_SAMPLE,result); |
| 45 | | } |
| 46 | | }}} |
| 47 | | The process_sample function of the previous example can be written using any kind of portable programming language (C/C++ or VHDL for example) that can be compiled and translated to processor specific binary files. On the other hand, the read and write operators closely depend on the platform and must be specifically designed for it. Thus, when porting this code to another platform, the read and write specific PHAL-OE library implementation will be used. |
| 48 | | |
| 49 | | Now the question is: would this simple P-HAL be enough to build Software Radio signal processing applications? The answer is yes. Only a short specification of an origin and a destination of a data flow is enough to build any kind of application. Similar to the Turing Machine computing theory, any kind of processing machine based on a single operation of moving data from one origin to a destination is able to execute any kind of processing task. Thus, porting this concept to signal processing tasks is trivial. |
| 50 | | |
| 51 | | In previous figure, a representation of the abstraction layers involved in PHAL-OE is drawn. On the top we see the connection graph of the object pieces building the radio application, this is the Abstract Application Layer. On the next level, objects are mapped into real Processing Elements (PE), they physically need a place to be executed or located on. The PHAL-OE Layer is the abstraction layer found between the real application processes and the Hardware Layer. An overall P-HAL Platform is represented although three PE (each of them enabling the PHAL-OE functionalities) are under it. |
| | 37 | Previous figure tries to illustrate the PHAL-OE concept. On the bottom we can see the Hardware Layer where we can found several processors or Processing Elements (PE) physically interconnected among them. On top of the figure we can see the Application Layer where a graph of a radio application tries to define the required tasks (objects) and the data flow among them. In the Real Application Layer we can see the previous tasks but using the services or functionalities provided by PHAL-OE to build coherently the radio application. On th PHAL-OE Layer we observe that from the point of view of the tasks (objects) conforming the radio application all them only see the same platform, the PHAL-OE Platform, not being aware of any detail related with the hardware. On such layer, but from the hardware point of view, we can find the specific implementation of the PHAL-OE functions for each one of the processors used to build the entire Hardware Layer. |
