|From:||Marcus D. Leech|
|Subject:||Re: [Discuss-gnuradio] GNU Radio Conference 2011|
|Date:||Mon, 29 Aug 2011 20:55:48 -0400|
|User-agent:||Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:220.127.116.11) Gecko/20110817 Fedora/3.1.12-1.fc14 Thunderbird/3.1.12|
On 08/29/2011 08:31 PM, Tuan (Johnny) Ta wrote:
I'm very excited for the upcoming conference. The issue is I haven't worked on GNU Radio for almost a year. And I see that there're quite a few changes. Even when I was working with GNU Radio, I couldn't say that I was very comfortable with it.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
|[Prev in Thread]||Current Thread||[Next in Thread]|