Very interesting ideas. Thanks Marcus for sharing! Unfortunately I don't have enough background in compiler to implement such ideas. I'm in the phase of learning GNU Radio, keeping up with its fast development is already a big task for me. I'm certainly willing to do something *to* GNU Radio when I'm more capable and the opportunity presents. But I can definitely see some CS grad student picking this up.
My question is more of what I can look at/practice so that I can ask the right questions at the conference, if my goal is to be familiar enough with GNU Radio to implement my own applications/algorithms. Given that there are only 2 weeks left, I think wandering around might not be a good idea. Thank you, Johnny On Mon, Aug 29, 2011 at 8:55 PM, Marcus D. Leech <mle...@ripnet.com> wrote: > ** > 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 Consortiumhttp://www.sbrac.org > > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
