@marcus, yes I have gone through that last year GSOC project, that was some real good work for my likings. I haven't gone through Volk link yet. Well, what I have observed is that the speed limitations over hardware is primary imposed by the software piece. But we can't create a dedicated hardware for each module, so we need generalization as well and thats where general purpose computers are good at. So definitely, there is a requirement of careful analysis for moving modules to FPGAs, whether significant performance improvement will be obtained or not.
@Nathan, yes I meant to refer to GSOC project as I wish to apply for this year. Sorry for not writing it down in the subject and causing a confusion. I was going through the GSOC ideas list available here ( http://gnuradio.org/redmine/projects/gnuradio/wiki/GSoC) and I wish to get some more details what the mentor is expecting to achieve in this project, this summer. Junaid On Saturday, February 8, 2014, West, Nathan <[email protected]> wrote: > On Saturday, February 8, 2014, Marcus Müller > <[email protected]<javascript:_e(%7B%7D,'cvml','[email protected]');>> > wrote: >> >> >> Hi Junaid, >> >> such a system already exists in the shape of a xilinx zynq board. >> There's been a talk that (although I was not there to witness it) is >> supposed to be quite good: >> >> >> https://fosdem.org/2014/schedule/event/gnu_radio_hardware_acceleration_on_xilinx_zynq/ >> >> I'm not sure if videos of that talk are available at this point. >> >> However, there is quite a documentation in the GR wiki: >> >> http://gnuradio.org/redmine/projects/gnuradio/wiki/Zynq >> >> For usage of specialized DSP instructions (if these can be part of the >> normal CPU program) please have a look at VOLK, which is a part of GNU >> Radio: >> http://gnuradio.org/redmine/projects/gnuradio/wiki/Volk >> >> Greetings, >> Marcus >> >> PS: Have to slightly disagree with you on the "hardware is faster than >> software, always" part, since design constraints usually limit the >> performance of FPGAs, and moving data guaranteeing coherence comes at >> a performance penalty. >> >> >> On 08.02.2014 10:00, Muhammad Junaid Muzammil wrote: >> > Hello, >> > >> > I am Junaid, currently a Masters student. The topic pretty much >> > inspired me, although I couldn't create a clear picture in my mind. >> > The project is about using coprocessors for acceleration, so >> > basically the target would be a heterogeneous sytem consisting of a >> > RISC microprocessor preferably belonging to ARM family alongwith >> > coprocessors which can be either FPGAs or DSPs. The hardware cores >> > are always faster than the software cores, there is no doubt in >> > that. Similarly DSP due its architecture shows better performance >> > towards signal processing functions. Both these coprocessors will >> > perform acceleration by taking some workload from uP. >> > >> > Now which particular functions/tasks will be taken, this isn't >> > clear to me at this stage and I am looking forward to get some >> > details over it. >> > >> > Junaid >> > >> > >> > >> > >> > >> >> >> > I believe Junaid is referring to a GSoC project to expand the coprocessor > abilities of GNU Radio. Systems that allow coprocessor a definitely exist, > but they aren't widely used and efficiently using a coprocessor with GNU > Radio isn't exactly out of the box functionality. > > What you might do for such a GSoC project depends on your interests and > abilities. It's likely that if you wanted to make accelerators the first > step would be some form of profiling to figure out candidate blocks or > functions. OTOH maybe you've seen in some paper or your own experience a > good candidate for coprocessor off loading. > > I think there's also interest in enabling blocks to handle their own > buffers to allow DMA, but someone else should be able to discuss that far > better than anything I might add at the moment. > > > Nathan > > PS- if you're going to discuss a GSoC project please mention that so > there's no confusion about the subject. If this isn't about GSoC then I > apologize for modifying the subject line. >
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
