[USRP-users] Problems using dsplink on E100

Andre Puschmann andre.puschmann at tu-ilmenau.de
Sat Feb 25 05:18:10 EST 2012


On 02/23/2012 06:46 PM, Philip Balister wrote:
> On 02/22/2012 03:45 AM, Andre Puschmann wrote:
>> On 02/21/2012 09:30 PM, Philip Balister wrote:
>>> /me chants remote_proc and virtio.
>>
>> @Al Thanks for explaining the difference between dsplink and syslink.
>> I believe, remote_proc (or RPMsg) successes even syslink but is only
>> available for OMAP4 and beyond if I am not mistaken.
>>
>> In general I would really like to see something that nicely combines
>> both worlds on the E100 (and beyond it). Integrating an interface for
>> adding/removing DSP blocks into UHD would also make sense, since radio
>> parameter configuration would be done using UHD anyway. But not sure
>> though how something like this could look like.
> 
> This talk should make my chanting a little clearer:
> 
> http://video.linux.com/videos/using-virtio-to-talk-with-remote-processors
> 
> I haven't got my head around how to apply this, but the kernel guys I
> know seem to think this is the answer to many things.

Watched it, understood it, liked it!

-Andre

> 
> Philip
> 
>>
>> -Andre
>>
>>>
>>> Philip
>>>
>>> On 02/21/2012 02:59 PM, Almohanad Fayez wrote:
>>>> Well a more appropriate solution might be to have the GPP transfer
>>>> the data to memory already accessible to the DSP instead of moving
>>>> data to the DSP memory space directly would mean having to redo the
>>>> device driver and Philip has already done a pretty good job writing
>>>> a GPP driver :)  DSPLink buffers are kind of slow I'm hoping to
>>>> start looking at the CMEM (Continuous Memory) module soon as an
>>>> alternative.  The bad thing about CMEM, if I'm understanding it
>>>> correctly, it provides just memory mapping which means you would be
>>>> forgoing things such as automatic cache coherence and data
>>>> structures for the GPP/DSP communications.  If you want to go down
>>>> this path you might find it helpful to look at some of the work
>>>> I've done based on dsplink for reference sake
>>>>
>>>>
>>>> https://github.com/alfayez/OMAP-DSP-Main-Wiki/wiki
>>>>
>>>>
>>>> this link is for a general wiki for gpp/dsp omap3530 stuff and if
>>>> you access my main github branch you can download all the code.  If
>>>> you want to do something from scratch it's worth looking in
>>>> Syslink, which wasn't available when I first started this work, but
>>>> it's supposed to have similar performance to dsplink except it can
>>>> support non-shared memory interfaces basically TI has released and
>>>> plans to continue releasing multi-core processors which don't
>>>> necessarily have a shared memory region between there processors
>>>> which renders dsplink obsolete for future processors.  Basically if
>>>> you use dsplink you're fine using USRP E100 and E110 since they're
>>>> OMAP3530 based, but if a future USRP E series uses a multicore
>>>> processor or you switch to a difference platform using such
>>>> processors you'll need to switch to syslink.
>>>>
>>>>
>>>> Almohanad (Al) Fayez
>>>>
>>>>
>>>>
>>>>
>>>> -----Original Message----- From: Philip Balister
>>>> <philip at balister.org> To: Stefano Speretta
>>>> <s.speretta at isispace.nl> Cc: usrp-users
>>>> <usrp-users at lists.ettus.com> Sent: Tue, Feb 21, 2012 12:17 pm 
>>>> Subject: Re: [USRP-users] Problems using dsplink on E100
>>>>
>>>>
>>>> On 02/21/2012 12:04 PM, Stefano Speretta wrote:
>>>>> Actually we are just started playing with the E100. I tried using
>>>>> the ARm while also running a demodulation routine and it uses
>>>>> quite a lot of CPU, so we where thinking about offloading part of
>>>>> the computation to the DSP.
>>>>>
>>>>> In the short term I was thinking of using UHD to receive samples
>>>>> and pushing them straight to the DSP but we may also try to
>>>>> directly map the FPGA pins to the DSP and play directly there....
>>>>> The second option is definitely interesting but I fear it 
>>>>> requires quite a lot of work ... I tried googling around to see
>>>>> if somebody actually did something similar but I had no success.
>>>>
>>>> This would be the best solution. However it means you need to learn
>>>> a lot about the DSP. You will also need to modify the device driver
>>>> so the ARM does not use the pins from the FPGA to start data
>>>> transfers.
>>>>
>>>> Philip
>>>>
>>>>
>>>>>
>>>>> Stefano
>>>>>
>>>>> On 2/21/2012 5:38 PM, Andre Puschmann wrote:
>>>>>> On 02/21/2012 04:24 PM, Stefano Speretta wrote:
>>>>>>> Here is the output:
>>>>>>>
>>>>>>> i-dsplink - 1:1_65_00_03-r0i.9 ti-dsplink-examples -
>>>>>>> 1:1_65_00_03-r0i.9 ti-dsplink-module - 1:1_65_00_03-r0i.9
>>>>>>>
>>>>>>> We also tried the module you sent us and it works!
>>>>>> Great! What was special about it Philip? I guess you've
>>>>>> compiled it for your kernel?
>>>>>>
>>>>>> Stefano, you mentioned you wanted to use the DSP for
>>>>>> off-loading stuff. Are you just beginning or have you or
>>>>>> anybody else already done something? Is the memory used by the
>>>>>> FPGA to exchange bits between GPP and FPGA accessible by the
>>>>>> DSP already? Are there any UHD changes required?
>>>>>>
>>>>>> -Andre
>>>>>
>>>>>
>>>>
>>>> _______________________________________________ USRP-users mailing
>>>> list USRP-users at lists.ettus.com 
>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>
>>>>
>>>>
>>>
>>> _______________________________________________ USRP-users mailing
>>> list USRP-users at lists.ettus.com 
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>


-- 
Andre Puschmann
Ilmenau University of Technology, Integrated Communication Systems Group
Phone: +49 3677 69-4132, Fax: +49 3677 69-1614
Email: andre.puschmann at tu-ilmenau.de, Web: http://www.tu-ilmenau.de/ics
Office: Zuse Building, room 1071




More information about the USRP-users mailing list