[USRP-users] Problems using dsplink on E100

Andre Puschmann andre.puschmann at tu-ilmenau.de
Tue Feb 28 02:46:10 EST 2012


On 02/27/2012 04:16 AM, Thomas Tsou wrote:
> On Wed, Feb 22, 2012 at 3:45 AM, Andre Puschmann
> <andre.puschmann at tu-ilmenau.de> wrote:
>> @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.
> Indeed. But still, even if there was support for omap3 with RPMsg
> (SysLink 3.0), one has to wonder what benefits that approach would
> provide to the E100.
> SysLink and beyond really evolved to handle the asymmetric
> multiprocessor environment with 5 or more different cores. That's a
> problem omap3 doesn't have when a simple master/slave approach is
> adequate. I can see the benefit (or detriment) of being bleeding edge
> and on the Ice Cream Sandwich upgrade track, but that's about it.

That's certainly true. On the other hand, I guess the E1xx is just the
beginning of a series of embedded SDR platforms. They all look pretty
similar and are likely to benefit from the new approach. And there is
another big thing: mainlining the code. The chance to get the kernel
part of the E1xx mainline is IMHO higher if it's based on the general
virtio appraoch. (I know for now there is no such things involved at all
but it'll come.)

> The other factor of future portability is that DSP access (independent
> of video or imaging units) remains uncertain. Look up DSP Subsystem in
> the omap4430 TRM and you'll find that "This information is not
> available in the public domain." The omap4 includes a reduced
> functionality c64x, 'Tesla', but you won't be able to access it
> without an NDA, which is incredibly unfortunate.

Ohh, I didn't know about that. Does that mean OMAP4, i.e. all the
Pandaboards, are less powerful then OMAP3 in terms of DSP power and
flexibility for open-source developments?

> In short, I find little motivation to go beyond DSPLink on the E100 at
> this time (I can deal with the fact that DSPLink code is just plain
> ugly). If you're concerned about future portability, refer to the
> SysLink migration guide and be mindful of the differences. There are
> SysLink counterparts for many, but not all, DSPLink interfaces.
> http://processors.wiki.ti.com/index.php/SysLink_MigrationGuide
>> 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.
> What role do you see for the c64x inside of UHD?
> I view the DSP as more of an application side processor. Even with an
> fpga->c64x interface (no small feat), I feel that UHD interface should
> end at the transport. The subsequent c64x signal processing code
> should be independent of how the samples got there.

I totally agree. As less application specific stuff as possible. I am
not sure what the current control/data flow is missing to coordinate the
FPGA/GPP/DSP interaction. But at least some of the kernel driver
responsibilities need to be addressed by the DSP then, or shared between
GPP/DSP. And the only interface to this part from an application
viewpoint is through UHD. So at least some changes are required in that
matter I believe.


More information about the USRP-users mailing list