For efficient module creation, it’s important to understand the basic design philosophy behind the GReasy GNU Radio extension, and the underlying TFlow physical assembly tool. Having this understanding will better help put the subsequent assembly steps into context.
With GReasy, various components of a GNU Radio design can be mapped into FPGA fabric. The FPGA base design is prepared in advance, and contains static logic that remains persistent in the device over time, and includes interfaces, such as network, ADC, DAC, and perhaps fixed signal processing components. Additionally, the FPGA base design contains an amorphous sandbox region where GNU Radio components are placed and assembled into processing chains.
The GReasy design process is split into two phases. The first phase is the module creation phase. In this phase of the flow, a hardware engineer designs individual modules using the standard FPGA design entry flow. Then, after testing and verifying the module design, the module is registered into the GNU Radio module library. This registration process involves generating the module’s bitstream as well as extracting metadata from the module, including resource constraints, and valid placements of the module on the hardware device. This metadata is used by TFlow to speed up the bitstream assembly process in the second phase.
The second phase is the design assembly phase. In this phase, the user creates a GNU Radio design composed of individual components from the module library. Much like GNU Radio’s software library of processing blocks, TFlow has a precompiled library of hardware modules from which the user can select. TFlow stitches the module bitstreams together and combines them with an additional static bitstream design to create a full bitstream for the target FPGA. Currently, targeted FPGA architectures of TFlow include the Virtex-4 and Virtex-5 families as well as the Zynq family. TFlow can be easily expanded to other Xilinx FPGA family architectures due to certain generic components of the TFlow toolchain.
In the second phase of the design the precompiled modules are placed in the sandbox region of the FPGA. The sandbox is an allocatable region of the FPGA that is initially empty. It’s the complementary region to the static design, which contains data handlers and other necessary pre/post processing desired by the user that remains relatively unchanged.
Figure 1. Sandbox Region of the FPGA (Xilinx ZC706 board). Precompile modules are placed in any valid placements inside this region. There are ports and buses that connect the sandbox modules to the outer static that handles data transfer.
The two phases can be mixed to rapidly prototype and test individual modules to cut down on testing and verification time in the module design process. Instead of re-compiling an entire design in a traditional vendor flow, an individual module can be recompiled and registered into the module library. Once the individual component is recompiled, the whole design can be stitched together in the design assembly phase. This cuts down on turn around time significantly.