[USRP-users] Problems using dsplink on E100

Philip Balister philip at balister.org
Thu Feb 23 12:46:35 EST 2012


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.

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
> 
> 




More information about the USRP-users mailing list