[USRP-users] Problems using dsplink on E100
alfayez at aol.com
Sat Feb 25 23:50:16 EST 2012
philip, I've been trying to watch the video all day on the link provided but it's not loading and I can't seem to find it on youtube, I'm assuming you know some higher ups with access to video do you mind bugging them about it? thanks
Almohanad (Al) Fayez
From: Andre Puschmann <andre.puschmann at tu-ilmenau.de>
To: Philip Balister <philip at balister.org>
Cc: usrp-users <usrp-users at lists.ettus.com>
Sent: Sat, Feb 25, 2012 5:18 am
Subject: Re: [USRP-users] Problems using dsplink on E100
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:
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!
>> 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
>>> 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
>>>> 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?
>>> _______________________________________________ USRP-users mailing
>>> list USRP-users at lists.ettus.com
>> _______________________________________________ USRP-users mailing
>> list USRP-users at lists.ettus.com
lmenau University of Technology, Integrated Communication Systems Group
hone: +49 3677 69-4132, Fax: +49 3677 69-1614
mail: andre.puschmann at tu-ilmenau.de, Web: http://www.tu-ilmenau.de/ics
ffice: Zuse Building, room 1071
SRP-users mailing list
SRP-users at lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the USRP-users