Re: [Discuss-gnuradio] [GSoC] Co-Processors Update #9

[Philip Balister]

On 08/08/2014 11:54 PM, Alfredo Muniz wrote:
> Hello all,
> 
> Logistical:
> - coproc dev call is scheduled for August 12th at 2pm US central time
> - Next week is the last week of the program. I'll treat it like a usual
> week. After pencils down there is the last last week to clean things up and
> work on documentation so that's what I'll spend the last last week on.
> After that school will start and I'll get situated to continue working till
> the real deadline: the GNU Radio Conference.
> 
> Progress:
> - I have finally pushed the code for the turbo decoder dsp only test. It is
> in TI's code composer project format so I need to release instructions on
> how to compile without code composer:
> https://github.com/muniza/tcp3d_dsp_test
> - I successfully ran a turbo decoder test with moving data from the ARM to
> the DSP and vice versa using the physical pointer contiguous memory method
> I described on the last email. I'll clean this up and push this code
> sometime this weekend hopefully.
> 
> Plan for GNU Radio:
> - From my talks with Pendlum, I think this approach will work for both Zynq
> and Keystone and any device that has shared memory with the coprocessors.

I doubt depending on contiguous memory will ever work for GNU Radio.
I've heard a lot of talk about changing the guts of GNU Radio, but no
real action. Especially given GNU Radios dependence on double mapped
buffering to handle wrap around. For things with hard IP blocks like
Keystone, this may be a difficult problem. Unless the IP blocks can be
configured to operate on non-contiguous blocks. FPGA code should be
written to avoid dependencies on specific buffer layouts. (Yes, I know I
have made this mistake, but I ahve seen the error of my ways)

I understand why TI drives you towards the CMEM driver, but that is a
lousy long term plan. They are just reusing code from prior generations
of drivers. And I do want to see something work so we can evaluate the
hard IP based GNU Radio block. My concern with your wording is that
people might think depending contiguous memory buffers is a good idea.

Philip

> I'm going to create a kernel module that is able to set aside contiguous
> memory. I will write some functions in GNU Radio runtime to communicate
> with the module through ioctl. We set a flag in the GNU Radio block to tell
> runtime that we should create the buffer differently using the memory
> functions. Basically it will still go through the same process as any other
> buffer the only change is that we put the buffer somewhere in the physical
> memory space that we allocated. We are be able to get the virtual pointer
> to the input and output buffers through the work function so I can have a
> function for translating virtual to physical which can be done through
> get_user_pages in the kernel module. This way we don't need to change much
> in GNU Radio and the ARM and any coprocessor with shared memory has direct
> access to the data so no need for memcpy and userspace - kernelspace
> transfers. I'll bring this up at the coproc dev call.
> 
> Thanks everyone for the support!
> 
> 
> 
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>