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

[Alexander Chemeris]

On Wed, May 4, 2011 at 19:32, Philip Balister <address@hidden> wrote:
> On 05/04/2011 09:37 AM, Alexander Chemeris wrote:
>>
>> On Wed, May 4, 2011 at 17:05, Philip Balister<address@hidden>  wrote:
>>>
>>> We should move this to the usrp-users list since this has no gnuradio
>>> content. I've added it to the cc list.
>>>
>>> On 05/04/2011 02:01 AM, Alexander Chemeris wrote:
>>>>
>>>> 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.
>>>>
>>>
>>> I don't remember of the top of my head. On a loopback test, I see about 2
>>> MSPS, which means 2 MSPS go into the PFGA and 2 come back. There is a
>>> test
>>> program that lets you set a decimation and the looks for drops for
>>> testing
>>> one way transfers. 90% of my work has revolved around correctness to this
>>> point.
>>>
>>> The Read and Write cycle times are 17 clocks at the moment (L3 Clock rate
>>> is
>>> 166 Mhz). So that is 102 nS per sample if everything else is perfect.
>>
>> If 9 MSPS is a theoretical limit, that's too bad. Do you know is it
>> the maximum for async GPMC?
>>
>
> I'm not sure what the max is. The FPGA clock is 64 MHz, so you need to be
> able to sync the gpnc signals to that clock. With a sync interface, I hope
> you could to transfers in 4-5 L3 clocks.
>
> All this said, I still feel like the best solution is to reduce the sample
> rate in the FPGA.

We *need* at least 11.2MSPS to get WiMAX going. We could use 8-bit
samples, but this decreases dynamic range. That's the last resort.


-- 
Regards,
Alexander Chemeris.