Re: [Discuss-gnuradio] User experience with E1x0 boards

[Philip Balister]

On 05/03/2011 11:25 AM, Alexander Chemeris wrote:
> Hi Josh, Philip,
>
> On Sat, Apr 23, 2011 at 17:05, Philip Balister<address@hidden>  wrote:
> > On 04/22/2011 07:05 PM, Almohanad Fayez wrote:
> > > I've always wondered about the design difference between the E100 and the
> > > work you did with Chris Anderson's board ... now I know.  BTW where do you
> > > have your driver code posted for the E100 and any documentation, if it
> > > exists yet :) ? I found slides that you presented on April 13th.
> >
> > Those slides are a recent as it gets. There may be video of that talk in a
> > few months.
> >
> > Driver code is here:
> >
> > https://github.com/balister/linux-omap-philip
>
> We're seeking to get maximum throughput from USRP E100. Our goal is to
> collect some samples to RAM and then process them offline. Right now
> E100 can't achieve even 4MSPS, which is not enough for us. What is
> your feeling what is the limiting element? GPMC should be wide enough
> to transfer much more data and RAM should be fast enough too. Is it
> IRQ, or user-space processing?

First, do you have all the E100 kernel updates from here:

http://ettus-apps.sourcerepo.com/redmine/ettus/projects/usrpe1xx/wiki/Updating_E1XX_Boot_Files_and_Kernel_Modules

The MLO update is very significant as the L3 clock is running slow with 
the original MLO. The driver updates help some.


There are a few factors here:

1) The interface with the FPGA is still asynchronous. This limits the 
bus cycle time we can use. We have spent some time looking at a 
synchronous interface, but the GPMC controller does not provide a free 
running clock for the FPGA. (The clock is only active during bus cycles, 
leaving no clocks available to finish internal fpga cycles)

2) The transfer size is 2048 bytes. Larger sizes are possible, but they 
make latency worse. Smaller sizes are better for latency, but max 
transfer rate suffers.

3) There is a delay getting interrupts after the fpga signals data ready 
via GPIO. This is not huge, but for high rates it hurts. I'm not certain 
where the delay is (gpio interupt controller, or kernel interrupt handler).

4) Be sure to tell UHD you want integer samples. I'm thinking even then 
UHD has to swap IQ for historical reasons. (Josh, help?)

5) Anything you can do in the FPGA to reduce the sample rate helps. With 
the E100 there is lots of free space in the FPGA for custom processing.

6) If I was smart about the DSP (I'm not), having the DSP take the data 
from the FPGA and reduce the rate should help also.

As always, I am very interested in ideas for improving performance.

Philip

> We consider replacing Gumstix with a more powerful C6-Integra SoC,
> like TMS320C6A8167. But before we dive into hardware modswe want to
> make it somehow working with what we have already. :)
>
> This is for the open-source WiMAX scanner project:
> http://code.google.com/p/wimax-scanner/