[USRP-users] Problems using dsplink on E100

Stefano Speretta s.speretta at isispace.nl
Wed Feb 22 15:52:51 EST 2012


Thanks to everybody for the inputs... rewriting part of the kernel 
module can actually be quite tricky...

Out of curiosity, how does the transfer between ARM and FPGA works? At 
first glance it seems there is a bus for TX and RX
and then a strobe signal that triggers an interrupt in the arm to fetch 
/ load a new I-Q pair. Is this correct?

I did not check the code too deeply, but what is the data format for IQ? 
Is it a 16 bit integer for I&Q?

Stefano

Il 22/02/2012 09:45, Andre Puschmann ha scritto:
> 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
>


-- 
Stefano Speretta
ISIS - Innovative Solutions In Space BV
Molengraaffsingel 12-14
2629 JD Delft
The Netherlands

Phone:   +31(0)15 256 9018
Fax:     +31(0)15 257 3969
E-mail:  s.speretta at isispace.nl
Web:     www.isispace.nl





More information about the USRP-users mailing list