From GNU Radio
Revision as of 01:36, 8 March 2017 by Mbr0wn (talk | contribs) (Imported from Redmine)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search


The Co-Processors Working Group met on Wednesday 9/17 at 15:30 Eastern (3:30pm local time in DC) (For conference schedule see The schedule gave us approximately 2 hours dedicated to Co-Processors discussion.


  • Hardware Specific Problems

What is needed on a per-device basis

    • Best-practices
    • Skeleton framework to be filled in for each device
  • Non-Hardware Specific

What can we do in mainline GNURadio to help all co-processors

    • Memory transfer
      • Marking blocks as 'accelerated' (i.e. Alfredo Muniz's patchset from GSoC'14 - see
      • Other efforts (e.g. Jonathan Pendlum: Zynq FPGA fabric, gr-dsp, gr-gpu)
    • Scheduling
      • Fine-grained control over number of items to be processed per 'work' call
      • Message passing

Meeting Notes[edit]

Discussion Highlights[edit]

The discussion around what needs changing in mainline GNURadio ended up revolving around three general cases:

  1. Hardware supports scatter/gather DMA: the driver does the hard part (e.g. GPU's, Zynq generally behave well)
    • No changes are needed to GNURadio's buffer management, however the buffer base/length should be more accessible to the work() function
  2. Hardware doesn't support scatter/gather (i.e. it requires contiguous memory):
    • GNURadio needs to support blocks with custom allocators (i.e. signal to the scheduler that a block handles it's own buffers)
    • GNURadio also needs to handle the case that the custom allocator cannot support doubly-mapped buffers (i.e. signal that a buffer is only singly-mapped)
      • The scheduler can handle this by ensuring that a call to work() would never cross the end boundary
  3. Broken hardware + bad driver
    • Complain to the vendor
    • Use memcpy, and return to case 1


Outstanding work that needs addressing can be broken up into the following tasks

  1. Make buffer location (base/length) available to work() function (#729)
  2. Allow blocks to specify they need custom buffer allocators (#730)
  3. Handle non-doubly-mapped buffers appropriately (i.e. call work() with number of items to make sure the end of the buffer is not crossed) (#731)
  4. Block/Buffer life-cycle management (#730)
    • init()/@make_ready()@ function to ensure buffers are allocated before start() is called for blocks with custom allocators
    • shutdown()/@destroy()@ function to ensure buffers are freed when the top_block is destroyed
  5. Notify block (e.g. via callback mechanism) when read pointer has moved, and when write pointer has moved (#732)