[USRP-users] Problems using dsplink on E100

Andre Puschmann andre.puschmann at tu-ilmenau.de
Wed Feb 22 03:45:17 EST 2012


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.

-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