data coding functions for software defined radios ...

DATA CODING FUNCTIONS FOR SOFTWARE DEFINED RADIOS IMPLEMENTED ON R3TOS Raúl Torrego, Iñaki Val*

Eñaut Muxika

Xabier Iturbe, Khaled Benkrid

Communications Department IK4-Ikerlan 20500, Arrasate-Mondragón (Spain) email: [email protected], [email protected]

Communications and Signal Theory Department University of Mondragon 20500, Arrasate-Mondragón (Spain) email: [email protected]

System Level Integration Group The University of Edinburgh EH9 3JL, Edinburgh (Scotland) email: [email protected], [email protected]

ABSTRACT This paper presents the implementation of several data coding functions used in Software Defined Radios, on R3TOS: a Reliable, Reconfigurable and Real-Time Operating System. The latter offers efficient high performance computing on FPGAs as well as protection against emerging faults, hence making it a perfect candidate for the implementation of SDRs. In particular, R3TOS’ ICAP-based Inter-task Communication Infrastructure (I2CI) has been used for data feeding and collection from coding functions, while a task context saving and restoration procedure, and a fast function parameterization system have been developed in order to improve system performance. The design of the data coding functions has been carried out using Xilinx’s rapid prototyping tool System Generator in order to ease their development. 1. INTRODUCTION Software Defined Radios (SDR) [1] are becoming the technological answer that satisfies the features that users demand from new communication systems. These features cover different aspects such as communication speed, compatibility with various communication standards, communication reliability, battery life, device size and price. Defined as communication systems that change their characteristics “on-the-fly”, SDRs are able to meet many of these requirements. Evolutions like Cognitive or Intelligent Radios [2], with the ability of making decisions about changes of characteristics depending on the environment status, are suitable when dealing with secure communications in harsh environments [3]. There are several implementation possibilities for SDRs, from classical DSPs or general purpose processors to dedicated multi-core architectures [4]. Among these, the use of FPGAs and dynamic partial reconfiguration fits perfectly with the high performance computing and the flexibility SDRs demand. Partial reconfiguration in particular enables an FPGA to change the functionality of * Work partly supported by the Strategic Research Project program of the Government of the Basque County (Spain), through the project MOVITIC, (Etortek program).

part of the chip while the rest remains working, providing for continuous operation despite changing functionality requirement or emerging faults. This characteristic comes from the use of SRAM technology-based configuration memory of the FPGA, what permits the download of new configuration data at runtime. Harnessing this feature, R3TOS, a Reliable, Reconfigurable and Real-Time Operating System [5], exploits FPGA resources efficiently over time, depending on functional requirements and existing resources, using classical software operating system-like support. Furthermore, R3TOS is completed with several scrubbing functions that ensure safe operation even in harsh environments such as aeronautics and space [6]. Considering all of the above, the use of R3TOS for the implementation of Software Defined Radios is an appealing proposition. Their joint leads to a system in which SDR takes care of a secure communication while R3TOS guarantees efficient and reliable hardware utilization. However, some special features needed by some of the functions involved in an SDR, such as context restoration and task parameterization, still need to be developed and added to R3TOS. Dealing with the design and implementation of signal processing functions, the use of rapid prototyping tools is highly advisable [7]. These tools enable model based design allowing the designer, on the one hand, to program the required algorithms in a graphical way, generating synthesizable code automatically. On the other hand, functional simulations are feasible in the early design steps, which in turn lead to huge time savings. Because of this, we use Xilinx’s System Generator tool for the design of the data coding functions of an SDR. The main contributions of this paper are: 1) The implementation of data coding functions for Software Defined Radios on R3TOS, 2) The design, implementation and testing of a novel procedure for saving and restoring task contexts, and, 3) The development of a function parameterization system that reduces reconfiguration time.

The remainder of this paper is organized as follows. An overview of R3TOS is presented Section 2. Section 3 then introduces Software Defined Radios and describes the data coding functions to be implemented. The ICAP-based Intertask Communication Infrastructure (I2CI) used to connect these tasks and its link with System Generator is introduced later in Section 4. In Section 5 the novel procedure for task context saving and restoration is presented. Then, Section 6 introduces the function parameterization system that has been developed, after which numerical results about system performance are presented in Section 7. Finally, concluding remarks are drawn in Sections 8. 2. OVERVIEW OF R3TOS The R3TOS project [5] aims to develop a fault-tolerant, real-time operating system for FPGAs. R3TOS puts the versatile resources embedded in a reconfigurable chip at the service of computation in a reliable way. Unlike the classical way of implementing data processing tasks on FPGAs, R3TOS enables hardware tasks to behave like software tasks. Tasks are swapped in and out of the FPGA’s reconfigurable area depending on computation requirements over the execution time. This way, FPGA resources can be efficiently shared over time, which allows for the execution of very large applications on small devices, increasing performance per area and reducing power consumption. Other main characteristics of R3TOS are real-time performance thanks to a real time scheduler and fault-tolerance as tasks can be placed around emerging and permanent faults on-chip. Indeed, hardware tasks are scheduled based on their deadlines and placed on nondamaged resources, which are detected through regular scrubbing, keeping the system fault-free at all times. A simplified illustration of R3TOS is presented in Fig. 1 [8] [9]. 2.1. ICAP controller Many of the operations and possibilities R3TOS offers lie in the use of dynamic partial reconfiguration of FPGAs. Xilinx FPGAs provide an Internal Configuration Access Port (ICAP) to the configuration memory, which removes the need for external devices to control this reconfiguration procedure. There is a single ICAP port per FPGA and its maximum access speed is of 400 Mbytes per second, in theory. Efficient control of this port is necessary to harness its maximum bandwidth. R3TOS implements a custom-made ICAP controller composed of a finite state machine and a PicoBlaze microcontroller, which offers several high level functions for the ICAP port. The basic functions are: task loading, task blanking, data feeding and collection to/from tasks, and scrubbing. All these functions are executed exploiting the

Fig. 1. Scheduling,

allocating and executing hardware tasks onto a partially damaged FPGA in R3TOS

maximum bandwidth of the ICAP port, accessing 32 bit words at 100 MHz. 2.2. R3TOS Scheduler The scheduler is the part of R3TOS in charge of deciding the order in which different hardware tasks have to be executed. It is implemented on a PicoBlaze processor that executes a port of the well-known Earliest Deadline First (EDF) scheduling algorithm. Unlike the classical implementation of this algorithm in software operating systems, where usually only a single task can be executed at a time, the R3TOS approach considers the possibility of executing tasks in a true parallel way. This way the scheduler has a higher degree of freedom to accomplish its work while the placement of the different tasks becomes more complicated. The allocator, discussed in the next subsection, is in charge of dealing with this issue. Consequently, the scheduler shares information with the allocator as well as the processor that that issues the tasks. Moreover, as already mentioned in the introduction, the aim of R3TOS is to make hardware tasks behave like software ones. Therefore, tasks in R3TOS meet the typical states in any operating system: Waiting, Ready, Preempted and Executing, plus two hardware-centric additional states: Allocating and Allocated [10]. Due to concrete restrictions of partial reconfiguration, task preemption is not straightforward and needs special care as will be seen in Section 5. 2.3. R3TOS Allocator Once the scheduler has decided that a particular task has to be executed, it is the allocator’s job to look for an appropriate site within the reconfigurable area of the FPGA. For this purpose there are three main parameters it has to take into account: the damaged sites where it is not possible to allocate any resource, the sites already under

Fig. 2. Implementation

in System Generator of the ‘Full-standard’ design

utilization by other tasks and the resources the scheduled task needs for its execution. Due to the non-homogeneous distribution of resources on modern FPGAs, e.g. DSP Blocks or BRAMs, the use of this type or resources by any task may be very restrictive and a bottleneck for the allocator’s performance. Therefore this has to be taken into account when dealing with task design for R3TOS. The allocator implementation is based on a third PicoBlaze that executes the Empty Area Compaction (EAC) allocation algorithm [9]. The algorithm gets task information from the scheduler and information about the damaged sites from the ICAP controller. 2.4. Miscellaneous The full version of R3TOS completes with a MicroBlaze processor which is in charge of several control tasks of the whole system such as task bitstream management on startup, and generation of the list of tasks to be executed. It also eases the connection with the external world via standard communication IPs such as Ethernet or RS232, and is also available for the execution of any software task if and when needed. Other IPs within R3TOS are: a recovery unit that can reconfigure any of the aforementioned parts of R3TOS in case of failure; a Configuration Guardian (CG) that is independent from the allocator ensuring that a task does not accidentally overwrite any existing part of the system; and a communication monitor that guards the communications between the different processors in the system and reports any malfunction. 3. SOFTWARE DEFINED RADIOS AND DATA CODING FUNCTIONS The term “Software Radio” was used for the first time by Joseph Mitola in 1991 to refer to reconfigurable or reprogrammable radios. These radios could support different functionalities at different times by changing their

configuration in software. This definition has however endured different interpretations since then, leading the term Software Defined Radios to be used for a wide spectrum of implementations ranging from pure software implementations on general purpose processors to FPGAbased implementations. This change of functionality can also be interpreted in different ways. From minimum granularity changes where single parameters like filter coefficients or amplifier gains are updated, to coarse granularity reconfigurations where a whole communication standard is changed (i.e. from WiFi to WiMAX). In any case, Software Defined Radios fit perfectly with FPGA dynamic reconfiguration [11] and with R3TOS. As a proofof-concept of this suitability, this paper presents the implementations of the first functions (the data coding functions in a modulator) of a future full SDR implemented in R3TOS. In order to test the potential of R3TOS, two different granularities have been chosen for testing: 1) a function-byfunction execution whereby every coding function is executed in an individual task, and 2) a coarse grained execution, also named ‘full-standard execution’, whereby every single task embraces the necessary functions for a concrete communication standard (Fig. 2). This way the task scheduling only happens when a change of standard is required. The coding functions used by three of the most used communication standards nowadays have been elected: WiMAX, WiFi and UMTS. These functions are: data randomizer, data puncturer, Reed-Solomon encoder, convolutional encoder and data interleaver. As stated before, these functions have been implemented using the Xilinx System Generator tool. 3.1. Data randomizer Randomization is used to provide simple encryption and prevent vicious receivers from decoding the data.

Therefore, the same pattern is used both in the transmitter and in the receiver side. This function consists of a Pseudo Random Binary Sequence generator (PRBS), plus a XOR gate that mixes the input data with the sequence generated by the PRBS. The PRBS block is built with a chain of registers initialized, in this case, with a predefined pattern generated by the x15 + x14 + 1 polynomial. 3.2. Reed-Solomon encoder Reed-Solomon and convolutional encoders are part of Forward Error Correction (FEC) coding. FEC can detect and correct errors without the need to retransmit the data through the channel. It is achieved by incorporating redundant bits into the transmitted data and recovering data in the receiver side. Reed-Solomon encoder is a systemic linear block code based on the Galois Field arithmetic. Due to its mathematical complexity and in order to ease the implementation, the Reed-Solomon encoder IP delivered with the standard Communication library in System Generator was used. Further synchronization blocks needed by the IP have also been added to the function. 3.3. Convolutional encoder A convolutional encoder is based on a linear finite-state shift register made up of K registers and N adders, with K being the so called constraint length and N the number of generator polynomials. As with the Reed-Solomon encoder, our implementation uses the dedicated IP block that System Generator provides for this purpose. Simple glue logic is added to the convolutional encoder block in order to adequately output data to the output digital interface. 3.4. Data puncturer Data puncturing is usually used after a convolutional encoder to achieve higher code rates and also to improve the flexibility of the encoder without involving different encoders. During data puncturing some bits are selectively deleted. For this purpose, all output data from the encoder is firstly stored in a memory. Later, only the specified positions are extracted and passed to the output of the block. In the implementation proposed for this work, the memory used is a Dual-Port RAM, so that data input and output can be performed simultaneously.

Fig. 3. ICAP-based

inter-task communication infrastructure detail

3.5. Data interleaver Data transmitted in channels with multipath fading (a very common scenario in wireless communication) may suffer burst errors which cannot be easily corrected by FEC codes. An effective method for solving this issue is using temporal diversity. Interleaving the coded bits the burst errors are distributed to different modulated data symbols, hence easing the work of FEC decoding. A Dual-Port RAM is also the key component in this case. Input data is stored sequentially through the first port while output data is read-back simultaneously from the second port in the order determined by the interleaving pattern. A free-running counter connected to a BRAM that stores this pattern generates the output access sequence to the Dual-Port RAM. 4. ICAP-BASED INTER-TASK COMMUNICATION INFRASTRUCTURE (I2CI) One of the main peculiarities of R3TOS lies in the data communication of the tasks. In order to obtain the highest area performance and a total freedom for the allocator to avoid hardware failures, the classical inter-task ‘wired’ communication systems have been replaced with a new inter-task communication mechanism. Indeed, systems such as Network on Chip (NoC) or point-to-point communications between tasks and host force tasks to be placed into certain places. Furthermore, this kind of solutions requires the use of static lines that make the management of partial reconfiguration more difficult. For this reason, R3TOS takes advantage of the capabilities of ICAP and implements a novel ICAP-based Inter-task Communication Infrastructure (I2CI) mechanism [8]. In it, data stored in diverse resources across the FPGA like BRAMs or LUTs configured as RAM, is accessible for

is reused as input buffer for the next task. This way, there is no need for data transfer through the ICAP port. 5. FUNCTION CONTEXT SAVING AND RESTORATION PROCEDURE

Fig. 4. SLICE

Flip Flop representation in FPGA editor

tasks that need it via ICAP. Considering this, I2CI uses ICAP to move data to/from tasks from/to other tasks or the host. In the work presented in this paper, each task has an input and an output buffer implemented by a BRAM, and so does the MicroBlaze host interface processor. The ICAP controller is responsible for copying input data to the task from the MicroBlaze processor or other tasks, and once data is processed, copying it back. Glue logic is added to adapt data from the way it is stored in the buffers to the needs of the tasks and vice versa (i.e. data rate, bit length, etc.). I2CI also adds some synchronization features for controlling the execution as can been seen in Fig. 3. These features are based on a Hardware-oriented Semaphore (HWS), implemented on a LUT. This HWS acts as task reset signal before execution and as ‘DONE’ signal when it has finished computation. We have implemented a joint of infrastructure including the I2CI and communication interface generated by System Generator. This communication interface consists on the data input and data output signals defined by the user plus a clock input, clock enable input and clock enable clear input signals. These last two signals are in charge of controlling tasks’ internal clocking and multi-rate synchronization. Therefore, they have to be properly connected and synchronized with the HWS in order to ensure proper task functioning. Further considerations about I2CI involve BRAM scalability and Snake BRAM reuse strategy [12]. After analyzing the storage requirements of the currently implemented tasks it is concluded that the maximum memory need of the Reed-Solomon encoder task reaches the 2040 bits (255 Bytes). This amount of memory is well within the 16 Kbit storage capacity of a BRAM. In case a task storage capacity exceeds the capacity of one BRAM, I2CI supports the use of more than one BRAM as data input or output buffer. Another feature supported by I2CI is the Snake BRAM reuse strategy that was used in the case of function-by-function execution. Provided that output data from a function becomes directly the input of the next task, it is possible to improve ICAP bandwidth utilization by reusing BRAM content. In the Snake strategy, the output buffer BRAM of a task is not blanked after execution and it

Functions like Data randomizer are not time invariant. The Pseudo Random Binary Sequence (PRBS) block that generates the randomization data has to start from the point of the last execution in order to ensure coherent data recovery in the receiver. The same happens with other signal processing functions like Infinite Impulse Response (IIR) filters or with any task that has been preempted. This feature, similar to context saving and restoration performed in software processors, has been extensively covered in [13], [14] and [15]. However, some issues related with the behavior of the Flip-Flops have been discovered, which, at the best of the authors’ knowledge, are not covered by these previous works, at least not for the Virtex 4/Virtex 5 FPGAs considered in our approach. When dealing with context saving, it has to be noticed that the information that can be read-back via ICAP, if not previous action is performed, contains the initial values of the Flip-Flops, not the current ones. It is precisely the current state of the Flip-Flops the one that holds the context of the task. Moreover, programming a partially reconfigurable area configures everything but the state of the Flip-Flops that maintain their previous state. Therefore, in case another task is placed in the same area and updates the state of these Flip Flops, the context recovery would fail. This way the straight procedure for context saving and recovery, would fail. A first approach to solve this issue could consist in designing tasks so that no Flip-Flops are used. Instead, SRL16 shift registers or LUTs configured as RAM are used. This approach, although functional, can lead to very poor performance in terms of resource utilization and is unfeasible in case the designer does not have control over task implementation (i.e. third party tasks or tasks designed with rapid prototyping tools in which code is generated automatically). A better approach is presented in the next sub-section. 5.1. Context saving It is possible to capture the current state of Flip-Flops using the GCAPTURE command through the ICAP port [16]. This command forces a copy of the current values of the Flip-Flops into the configuration memory so that they can be read-back. More precisely, the current Flip-Flop states are stored in the INIT/VALUE bits of the frame that stores the Flip-Flops’ configuration of each CLB column (frame with minor address 20). This way, it is possible to readback via ICAP the current state of the Flip-Flops and save it until it is needed in the next execution of the task. However,

Table 1. Task

Table 2. Task

resource utilization

configuration time comparison

we note that this command overwrites the initial value of INIT/VALUE bits, so in case the default value of the task needs to be reprogrammed, further considerations are needed. Another important peculiarity of the GCAPTURE command is its application range. Indeed, when executed, the values of the entire FPGA are updated, what should be taken into account to avoid future functional problems. As will be stated later within the conclusions, a procedure for a local application of the GCAPTURE command is under development. This procedure processes certain bits in the so called “Special frame” [17] of each column of the FPGA protecting the Flip-Flops within that column against the effect of the GCAPTURE and GRESTORE commands. 5.2. Context restoration GRESTORE is the inverse command of GCAPTURE. This command initializes the state of the Flip-Flops with the values stored in the INIT/VALUE bits of the configuration memory. Unfortunately, this command is also applied to the whole FPGA so its execution would lead to a corruption of the R3TOS system and of other tasks being executed at the same time. Until the procedure for a local application of the initialization commands is fully developed, in order to restore the state of Flip-Flops within just one task, it is necessary to perform a local initialization of those FlipFlops via a local reset. The key points for this reset are the SR pin of each Flip-Flop and the SRMODE bits in the configuration memory. Driving the SR pin high, the FlipFlop is initialized with the value stored in the SRMODE bit. Therefore, a manual update of SRMODE bits via ICAP, followed by a reset, enables the load of user-defined values into the Flip-Flops.

Access to the SR pin is granted with a proper coding in VHDL or Verilog, or through certain parameters in System Generator or other rapid prototyping tools. In the particular case of the work presented this paper, all the SR signals obtained are connected together to the Hardware-Oriented Semaphore so that an automatic reset is performed prior to the execution of a task. A detailed view of Flip-Flop connections is given in Fig. 4. Overall, the procedure for context saving and restoration includes the following steps: 1- Execute the GCAPTURE command 2- Read-back the frames that make up the task. The INIT/VALUE pins are already updated with the current values of the Flip-Flops in the partial bitstream. 3- Store the partial bitstream in R3TOS’ RAM memory. When the task needs to be restored: 4- Recover the task’s partial bitstream from RAM. 5- Copy the values of INIT/VALUE bits to SRMODE bits. 6- Program-back the task into the reconfigurable area using the modified partial bitstream. 7- Force a local reset prior to task execution. 6. FUNCTION PARAMETERIZATION Dealing with partial reconfiguration, one of the main parameters to take into account is the reconfiguration time [18]. It is defined as the time needed for the reconfiguration procedure to take place and during which the reconfigurable area is not functional. Therefore, it is important to reduce this time. R3TOS offers several strategies for this purpose such as the aforementioned Snake strategy or the Task preservation strategy. The latter strategy does not blank out a task until the area it uses is needed by another one. This way, in case the task needs to be executed again, the time to program it is saved. Following this philosophy a Task parameterization strategy is presented in this section. Due to the particular characteristics signal processing tasks have, similar but not identical functions are used by many communication standards. For example, among the functions implemented in this paper the convolutional encoder changes its generation polynomial from WiMAX to UMTS. The same happens with the interleavers. Both the interleaving pattern and length change from standard to standard. Following a traditional design procedure for these functions would end up with the implementation of independent functions for each standard, without any reuse, being necessary to load a new full task in every standard change. The proposed design strategy takes advantage of R3TOS’ ability to access and reconfigure every individual resource in the FPGA to generate parameterized versions of the functions. This way, the functions can be reused across

Table 3. Task

execution time comparison

different standards just with minor partial reconfiguration. The key point of the strategy resides in a proper coding of the functions so that the parameters to be changed are mapped into resources easy to reconfigure such as BRAMs or LUTs. In the implementation carried out in this paper the aforementioned functions have been parameterized: namely the convolutional encoder and the interleaver. In the case of the convolutional encoder, the generation polynomial is mapped into a 16 bit RAM LUT. This way it can be reconfigured, and therefore reused, with a single frame read-write. With the interleaver, two actions have been carried out. On the one hand, the Dual-Port RAM memory used to store the data has been sized to the worst case scenario, namely the storage of the 1920 bits of the Matrix interleaver in the WiFi standard. On the other hand, the interleaving pattern has been stored in a BRAM. Updating the 64 frames that make up the user data of a BRAM change this interleaving pattern. Section 7 provides implementation results regarding the reconfiguration time saving that this strategy achieves. 7. IMPLEMENTATION RESULTS This section sums up the results obtained from the implementation of the aforementioned strategies. Table 1 shows the FPGA resource utilization of the implemented functions as well as R3TOS’ overhead. It can be observed that a minimal of 2 BRAMs per task corresponding to the input/output buffers has been used. It is also noticeable that the Full-standard design occupies fewer resources than the sum of the individual functions. This is due to the removal of the glue logic that connects the input/output buffers to each task. In the full-standard implementation this glue logic is only used once. Concerning R3TOS’ overhead two different data sets are presented, one with a full version of R3TOS with all the components mentioned in Section 2 implemented and another, named ‘Stand-alone’, in which just the minimum components needed by the SDR implementation are present (i.e. the MicroBlaze processor is not preset). Taking into account the small size of the SDR data coding tasks, the overhead of the full version of R3TOS is quite high in this case. However, it has to be stated that this version includes a MicroBlaze processor that

cannot be considered as an overhead as it offers the possibility of executing complex software tasks on it if needed. The overhead of the stand-alone version, on its side, is more assumable in relation with the functions it offers. Table 2 compares the configuration time of the parameterized functions with the configuration times these functions would have if needed to be reloaded completely. As stated before, the parameterization of the convolutional encoder only needs the update of a single LUT, and therefore the read and write of a single frame. Compared to the whole task configuration the time saving is considerable (98%). In a worse case, like the parameterization of the interleaver where the update of a BRAM is required, this time saving still reaches a 70%. Finally, Table 3 compares the total execution time of the different approaches that have been used: the function-byfunction execution (in both the default version and using the Snake strategy) and the full-standard one, in which all the coding functions are implemented in parallel. The total execution time is divided into task configuration time, data feeding and collection times, and processing time. We note that these timing measurements have been carried out with a timer/counter within MicroBlaze. At first sight it can be observed that the full-standard execution is the fastest one (1.13 ms). This kind of implementation, closer to the traditional way of programming FPGAs, takes advantage of the parallelization potential that the device offers to execute tasks in a pipelined way. However, it has to be noticed that the measured times for the function-by-function execution correspond to a single iteration and with the execution of a single task at a time. In a cyclic execution where the functions have to be implemented once again, and where more than one task is executed in parallel, a virtual pipeline would be obtained leading to a further reduction in the execution time (i.e. a recursive execution with resources for the execution of two tasks in parallel leads to an execution time per task of 1.63 ms). Moreover, the use of smaller tasks eases allocator’s job when dealing with permanently damaged FPGA resources, so this time overhead is assumable. Comparing the function-by-function implementations, the effect of the Snake strategy can be seen. Removing the

data copy from task to task, a 20% reduction in task execution time is achieved (1.82 ms with the Snake strategy vs. 2.32 ms with data copy).The concatenation of longer task sets would further increase this time reduction.

[7]

[8]

8. CONCLUSION This paper has presented the implementation of several data coding functions for Software Defined Radios on R3TOS, a hardware operating system concerned with real-time task execution and reliable operation. As such, it is suitable for SDR implementation as has been demonstrated, leading to a system in which SDR takes care of a secure communication while R3TOS guarantees efficient and reliable hardware utilization. Furthermore, due to the particular characteristics that SDR tasks have, a task context saving and restoration procedure and a function parameterization design strategy have been developed and tested successfully. Future work will improve the state saving and restoration procedure to make it localized hence improving ICAP bandwidth utilization. We will also implement the remaining functions that make up a whole SDR system.

[9]

[10]

[11]

9. REFERENCES [1]

Mitola, J.: ‘Software radios-survey, critical evaluation and future directions’. Proc. National Telesystems Conference, 1992. NTC-92., pp. 13/15-13/23, 1992 [2]http://www.wirelessinnovation.org/page/Defining_CR_and_D SA, accessed 2012 [3] Mueck, M., Piipponen, A., Kalliojaሷrvi, K., Tsagkaris, K., Demestichas, P., Casadevall, F., Sallent, O., Baldini, G., Filin, S., Harada, H., Debbah, M., Haustein, T., and Gebert, J.: ‘ETSI reconfigurable radio systems: status and future directions on software defined radio and cognitive radio standards’, Communications Magazine, IEEE, 2010, 48, (9), pp. 78-86, [4] Zong, W., and Arslan, T.: ‘A low power reconfigurable heterogeneous architecture for a mobile SDR system’. Proc. ICECE Technology, 2008. FPT 2008. International Conference on, pp. 313-316, 2008 [5] Iturbe, X., Benkrid, K., Erdogan, A.T., Arslan, T., Azkarate, M., Martinez, I., and Perez, A.: ‘R3TOS: A reliable reconfigurable real-time operating system’. Proc. Adaptive Hardware and Systems (AHS), 2010 NASA/ESA Conference on, pp. 99-104, 2010 [6] Iturbe, X., Benkrid, K., Arslan, T., Chuan, H., Erdogan, A.T., and Martinez, I.: ‘Enabling FPGAs for future deep space exploration missions: Improving fault-tolerance and computation density with R3TOS’. Proc. Adaptive Hardware and Systems (AHS), 2011 NASA/ESA Conference on, pp. 104-112, 2011

[12]

[13]

[14]

[15]

[16] [17] [18]

Haessig, D., Hwang, J., Gallagher, S., and Uhm, M.: ‘A case study of Xilinx System Generator design flow for rapid development of SDR waveforms’. Proc. SDR Forum Technical Conference, Orange County, pp. 6, 2005 Iturbe, X., Benkrid, K., Arslan, T., Torrego, R., and Martinez, I.: ‘Methods and Mechanisms for Hardware Multitasking: Executing and Synchronizing Fully Relocatable Hardware Tasks in Xilinx FPGAs’. Proc. Field Programmable Logic and Applications (FPL), 2011 International Conference on, pp. 295-300 Hong, C., Benkrid, K., Iturbe, X., Erdogan, A.T., and Arslan, T.: ‘An FPGA task allocator with preliminary FirstFit 2D packing algorithms’. Proc. Adaptive Hardware and Systems (AHS), 2011 NASA/ESA Conference on, pp. 264270, 2011 Hong, C., Benkrid, K., Iturbe, X., Ebrahim, A., and Arslan, T.: ‘Efficient On-Chip Task Scheduler and Allocator for Reconfigurable Operating Systems’, IEEE Embedded Systems Letters, 2011, 3, (3), pp. 85-88, Torrego, R., Val, I., and Muxika, E.: ‘OQPSK cognitive modulator fully FPGA-implemented via dynamic partial reconfiguration adn rapid prototyping tools’. Proc. 2011 Wireless Innovation Forum European Conference on Communications Technologies and Software Defined Radio (SDR’11 – WInnComm – Europe), Brussels, pp. 142-147, 2011 Iturbe, X., Benkrid, K., Ebrahim, A., Chuan, H., Arslan, T., and Martinez, I.: ‘Snake: An Efficient Strategy for the Reuse of Circuitry and Partial Computation Results in High-Performance Reconfigurable Computing’. Proc. Reconfigurable Computing and FPGAs (ReConFig), 2011 International Conference on, pp. 182-189, 2011 Simmler, H., Levinson, L., and Manner, R.: ‘Multitasking on FPGA Coprocessors’. Proc. Field Programmable Logic and Applications (FPL), 2000. Kalte, H., and Porrmann, M.: ‘Context saving and restoring for multitasking in reconfigurable systems’. Proc. Field Programmable Logic and Applications, 2005, pp. 223-228. Jozwik, K., Tomiyama, H., Honda, S., and Takada, H.: ‘A Novel Mechanism for Effective Hardware Task Preemption in Dynamically Reconfigurable Systems’. Proc. Field Programmable Logic and Applications (FPL), 2010, pp. 352-355. (XILINX): ‘UG71 Virtex-4 FPGA Configuration User Guide’, 2009, pp. 114, (XILINX): ‘UG191 - Virtex-5 FPGA Configuration User Guide’,(2011, V3.10 edn.), pp. 166 Liu, M., Kuehn, W., Lu, Z., and Jantsch, A.: ‘Run-time partial reconfiguration speed investigation and architectural design space exploration’. Proc. FPL 09: 19th International Conference on Field Programmable Logic and Applications, Prague, pp. 498-502, 2009