Philip,
On Wed, May 4, 2011 at 01:03, Philip Balister<address@hidden> wrote:
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.
No, we haven't updated. Thank you for pointing to this!
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)
Interesting.
What throughput have you achieved with asynchronous GPMC? It is ok for
is if it can push>=12MSPS, i.e. if it's throughput is 24e6 words/sec
or more.