You know, some things I've thought about for a long time in the
context of "what cool things could a grad student do in the context
of
Gnu Radio". More interesting, for many of us here, isn't what you
could do *with* Gnu Radio as it currently stands, but what could
you do *to* Gnu Radio.
For example, GRC was developed as a student project by Josh Blum
(although he took over from someone else, whose name escapes me).
One idea, which I credit to a conversation I had with Frank Brickle
some months ago, is the ability to synthesize a new block using a
collection
of sub-blocks, and have it be "efficient". For example, in GRC, I
might draw a box around a collection of relatively-cheap, adjacent,
sub-blocks,
and command GRC to produce a compiled object that is the
aggregation of those adjacent functions into an efficient
"superblock". The idea
is that for simple blocks, it may be more efficient (and likely
*is*) to have them avoid the buffer/block-scheduling *internally*,
and only have
them visit the block/buffer scheduler *at the edge*. The approach
might have GRC emit a block of C++ code that subsumes the
functionality
of the selected adjacent blocks, and then it gets compiled and
linked-in to your final flow-graph. The idea could obviously be
extended in
various ways--like integrating GPGPU support in a way that is
"seamless" in GRC--provide a separation between function and
implementation
that we don't really have in Gnu Radio.
On a similar track, the CASPER folks at Berkeley have an interesting
tool-chain for taking MatLab/SimuLink simulations, and producing
downloadable VHDL (either Verilog or VHDL) for their various FPGA
hardware. My thought would be wholesale theft of that idea, but
using GRC as the high-level design abstraction, and having
*something* that can produce some subset (or all) of the flow-graph
that lives on
FPGA hardware (like USRP-family or other similar devices).
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org