Jump to Navigation

Creating a GReasy block with GNU Radio 3.7

This section will step through the process of using scripts to generate the necessary files and source code needed to create a GReasy block.  By following these steps, a user will be able to create a FPGA-based processing module, register it with GNU Radio, and use it as a component in the GNU Radio block library.  The scripts referenced are optional, but are highly recommended.  This tutorial will also attempt to explain what these scripts are actually doing and what important files are being generated.  Some important file locations that may be mentioned or referenced in this section are:

  • {INSTALL_ROOT}/GReasy/trunk - the main trunk of the GReasy repository.
  • {INSTALL_ROOT}/GReasy/trunk/hdl - HDL/netlist source for GReasy hardware modules
  • {INSTALL_ROOT}/GReasy/trunk/gnuradio - top level of GNU Radio source code.
  • {INSTALL_ROOT}/GReasy/trunk/gnuradio/*{BLOCK LIBRARY NAME}*/grc - XML representations of GNU Radio blocks
  • {INSTALL_ROOT}/GReasy/trunk/gnuradio/gr-afpga - GNU Radio GReasy block library
  • {INSTALL_ROOT}/GReasy/trunk/tflow or {INSTALL_ROOT}/GReasy/trunk/zflow or {INSTALL_ROOT}/GReasy/trunk/zedflow - top-level of the TFlow precompiled library and the TFlow run-time assembly scripts.  These three different top levels represent the different supported FPGA families.  The folders zedflow and zflow are for the Zed/ZC702 and ZC706 respectively, while the tflow folder is for the Virtex-5.
  • {INSTALL_ROOT}/GReasy/trunk/tflow/modules/lib - module library for TFlow.  Each supported family/device has its own associated TFlow module library.



Creating a Module From HDL

The following section guides a user through the first phase of module creation.  The process is automated; however, understanding the process step-by-step can better inform modular design decisions.


1. Design Entry

  1. Start by designing your HDL block.  VHDL or Verilog can be used, yet Verilog is used in this example.  As in GNU Radio, module reuse is an important design principle that should become part of the design process.  Blocks created should be intended for reuse; hence, should follow good design practices, be well documented, and sufficiently flexible.  The declaration of the module should look like the following example:



1| module adder{

2|    // --------------------------------------------------

3|    // External interface (visible to the user)

4|    // --------------------------------------------------

5|    input [32:0] A, //data source A

6|    input [32:0] B, //data source B

7|    output reg [32:0] OUT,//data sink

8|    // --------------------------------------------------

9|    // Internal interfaces - DO NOT MODIFY THE CODE BELOW

0|    // --------------------------------------------------

11|    //

12|    // -- system hooks

13|    input clk,  // ADC by default, for DAC use ‘dac_clk’

14|    input rst,  // Active-high synchronous reset

15|    // -- run-time parameter update

16|    input [1:0] param_in,   // optional parameter IF input

17|    output [1:0] param_out, // optional parameter IF output

18| };



      1. There are a certain set of guidelines that should be followed to ensure the best performance from the tools (tFlow and GReasy).
        1. All GReasy modules are assumed to be synchronous, thus clk and rst lines are required.
          1. A GReasy design can have multiple clock domains.  For the ZC706 Zynq design, there are multiple clocking options. By default a clock line named, clk will be connected to the ADC clock. If the clock is instead named dac_clk then the module clock will be connected to the DAC clock. Each of these clocks are driven by the AD FMCOMM1-EBZ board (Figure 9).

    Figure 9. AD-FMCOMM1-EBZ board used as an RF
    frontend for the GReasy platform.  


        1. No pads or clock division components should be included within a component.  Access to these components should be through the static sandbox ports.
        2. All module outputs should be registered (see the example declaration above).
        3. Module I/O buses must have a valid bit at bus index 0. Therefore, if the bus provides 32 bits of data and a valid bit, the bus must be 33 bits wide.   This bit is true when the data on the subsequent bits represent valid data.
        4. Following GNU Radio design standards, signals between user created modules are standard data types: 32-bit I/Q data (16 I, 16 Q) and 32 bit integer data.  Not all of these wires need to be used within a design.
        5. Any size bus can be created for any block, but it can then only be connected to other blocks with the same sized bus. GNU Radio automatically assumes bus interfaces are 32 bits of data. If a block has a different sized bus, some further customization may need to be done in GNU Radio, but the functionality of the block in the FPGA will be unaffected.
        6. Every output and output valid signal must be set to a known state by the active-high reset signal.
        7. Valid signals are a requirement for interblock data transfer.


    Example Registered Output (Verilog):


    Main menu 2

    Blog | by Dr. Radut