https://wiki.gnuradio.org/index.php?title=GRCon13Coprocessor&feed=atom&action=historyGRCon13Coprocessor - Revision history2024-03-29T00:16:31ZRevision history for this page on the wikiMediaWiki 1.39.5https://wiki.gnuradio.org/index.php?title=GRCon13Coprocessor&diff=65&oldid=prevMbr0wn: Imported from Redmine2017-03-08T01:36:19Z<p>Imported from Redmine</p>
<p><b>New page</b></p><div>= GRCon13 CoProc WG =<br />
<br />
AKA: Putting Blocks Somewhere Besides the General Purpose Processor on Which GNU Radio is Running<br />
<br />
* Diverse hardware platforms each with unique attributes and challenges<br />
* Not practical to make GR a replacement for existing development tools (Xilinx ISE, TI Code Composer, etc.)<br />
* Dynamically scheduling when to do what where is hard<br />
** Goal: enable hardware accelerator users, developers, and researchers to adopt GR as a framework for ''applications''<br />
<br />
* Moving data<br />
** Creating buffers in desired memory region<br />
** Facilitating command/control and parameter loading<br />
* Permit “chains of operations” and “superblocks”<br />
** Allows configuration of accelerated portion at start-up (or not)<br />
* Need a unified accelerator API<br />
** Wrap the necessary parts of the driver interface<br />
** Present the desired functional interface to the flowgraph<br />
** Provide accelerator developers an easy, effective, and efficient way to use GR<br />
<br />
Initial Goals<br />
<br />
* C++ Class API for GR buffer interface<br />
** Allow for multiple types of buffer allocation and usage, each of which all must provide the same data guarantees to scheduler<br />
*** VM Circular; non-circular; non-host based via DMA (circular or not); others<br />
*** Specifics defined by actual interface, inherited from parent class<br />
** Move current GR buffers to use this, or this to use generic GR buffer interface if that is already in place<br />
** Arbitrary size, depending on usage and need of block, but default to a specific value for buffer type<br />
<br />
* C++ Class API for coprocessor interface<br />
** Supports means for creating buffers for data transport between a specific coprocessor and main CPU memory (via new buffer API)<br />
** Separate data transport and kernel execution if/where possible, to minimize latency to coprocessor work, and maximize data throughput when handling processing on coprocessor<br />
** Supports means for executing a single kernel on the coprocessor<br />
** No support for multiple-kernel scheduling yet; multi-kernel combined into single kernel initially<br />
** Single threaded; asynchronous / no blocking (use internal state to keep tabs on processing)<br />
** Work flow: push data to coprocessor, kernel execution, pull data from coprocessor<br />
** Hopefully data push and pull can be made asynchronous to kernel execution<br />
<br />
Future Goals<br />
<br />
* Allow kernel-per-block/thread, multi-kernel control via current host CPU-based scheduler, while maintaining data storage on coprocessor in-between relevant blocks<br />
* Dynamic block allocation on host CPU or coprocessor at flow graph start time<br />
* Dynamic block work location selection on host CPU or coprocessor during runtime<br />
* Supports means for creating buffers for data transport between any specific coprocessors, to avoid having to return data to the host CPU</div>Mbr0wn