Untethered On-The-Fly Radio Assembly With Wires-On-Demand

Abstract

In systems typified by software defined radio, ex-bitstreams are developed at design-time and new combinations isting flows for run-time FPGA reconfiguration limit resource of existing functionality are not easily created at run-time. For efficiency when constructing datapaths. We present the Wires-example if the expected waveforms are QPSK at frequency on-Demand framework that allocates a sandbox region in which examl if thee two c areQS atsfrequency modules from a library are flexibly placed and interconnected fieand BPSK a fi2,tentwo figuration bitstreams are rapidly and autonomously in an embedded platform without created. One with a filter centered around fi and a QPSK vendor tools. demodulator and one with a filter centered around f2 and a BPSK demodulator. If the need arose for a BPSK waveform at I. INTRODUCTION f 1, an all-software-based radio can create the new waveform With the introduction of Software Defined Radios (SDR) by using the filtering routine of the first waveform and the [1] platforms capable of supporting a wide variety of de-demodulation routine of the second waveform. Accomplishing modulation schemes became possible. Flexibility is achieved the same task on an FPGA is not as trivial, because the module by transferring functionality from fixed hardware to software combinations in each configuration bitstream are defined at routines. At run-time, the behavior of the system can be altered design-time and mainstream tools do not allow the modificaby changing the software routine that is called. Replacing ap-tion of the configuration at run-time. plication specific hardware, which is inherently parallel, with In [2], Xilinx introduced a partial reconfiguration tool flow the General Purpose Processors (GPP) required to execute the that allows the reconfiguration of part of the FPGA. Their flow software routines results in an increase in system requirements. allows the designer to separate the static and dynamic portions For example, an FIR filter with 51 taps requires 101 arithmetic of the design by pre-allocating slots where the dynamic operations (51 multiplies and 50 additions) to process one modules will reside. Slots are areas in the reconfigurable sample. The high number of operations leads to required GPP fabric reserved for the exclusive use of dynamic modules. operating frequencies greater than 100 times the sampling All communication to and from a dynamic module must be frequency, assuming that the GPP is only doing the filtering. routed through the provided bus macros that serve as the Further signal processing would require even higher operating bridge between regions. By providing the ability to reconfigure frequencies or the use of multiple GPPs. With the availability each slot separately, the agility of the implemented design is of 3.2GHz processors, such high operating frequencies might increased. The problems evident in the previous example can not seem to be a problem, but embedded systems rarely contain be addressed by having two dynamic slots in the base design. such powerfu...

Microkernel Architecture and Hardware Abstraction Layer of a Reliable Reconfigurable Real-Time Operating System (R3TOS)

“…Especially interesting is the work described in , where the authors propose to emulate a NoC by harnessing the reconfiguration mechanism of the FPGA. The possibility of creating online routes among the tasks has also been proposed [Suris et al 2008;Koch et al 2010], but its acceptance is low due to the long time overheads when creating the routes, and difficulties when dealing with FPGA configuration, whose format is not documented. Therefore, most of currently available ROSes rely on a static communication infrastructure which interconnects all of the reconfigurable slots in the system, where the hardware tasks are allocated, and the main processor, where the software part of the OS runs, e.g.…”

A Roadmap for Autonomous Fault-Tolerant Systems

“…However, since this system is based on JBits, it is sentenced not to grow as the reconfigurable technology does. On the contrary, in the system described in [44] the relocatable modules are placed and interconnected in a "sandbox" region without using any vendor tools. This system goes indeed beyond the boundaries of TL2 since it is able to create custom routes from scratch as needed.…”