[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] GNU Radio Conference 2011

From: Tuan (Johnny) Ta
Subject: Re: [Discuss-gnuradio] GNU Radio Conference 2011
Date: Mon, 29 Aug 2011 23:19:39 -0400

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,

On Mon, Aug 29, 2011 at 8:55 PM, Marcus D. Leech <address@hidden> 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 Consortium

Discuss-gnuradio mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]