Re: [Discuss-gnuradio] [USRP-users] what is the largest data transfer rate between fpga and overo in e100

[Page Jack]

Hi Almohanad ,
thanks for this information, can you provide more detail or is there any doc?

On 5/30/12, Almohanad Fayez <address@hidden> wrote:
> If memory serves correctly the n200 or the usrp 2 has an fpga expansion
> interface to some xilinx development platform which you might be able to
> use to create a custom solution to serve your needs.
>
> Al
> On May 29, 2012 6:17 PM, "Page Jack" <address@hidden> wrote:
>
>> I don't want to using a ethernet wire to connect N series to an ARM
>> board.
>> anyone have tried
>> build N series with ARM or DSP in one board which means the ethernet line
>> between N and
>> the processor is on PCB.
>>
>> On Wed, May 30, 2012 at 6:24 AM, Philip Balister
>> <address@hidden>wrote:
>>
>>> On 05/25/2012 09:18 PM, Page Jack wrote:
>>> > Hi Philip,
>>> > How does the conclusion be made that ARM can not swallow the current
>>> > max data transfer rate? I need to build a project that need to process
>>> > 60MB/s data, so any way to achieve my goal. Use a more powerful CPU or
>>> > use dsp on the omap?
>>>
>>> 60 MB/s is far more data than the OMAP3 can transfer from the FPGA. We
>>> have worked hard on configuring the GPMC interface and this figure is
>>> basically an order of magnitude more then the hardware will support.
>>>
>>> You need to look at the N series with Gig-E, or do the high rate
>>> processing in the FPGA.
>>>
>>> Philip
>>>
>>>
>>> >
>>> > On 5/25/12, Philip Balister <address@hidden> wrote:
>>> >> On 05/24/2012 09:46 PM, Page Jack wrote:
>>> >>> Thanks Ben,
>>> >>> does e100 use EMIF to transfer sample data between FPGA and ARM? If
>>> >>> so
>>> >>> the
>>> >>> data rate should be able to improved.
>>> >>> Anyone have tried to improve the data rate?
>>> >>
>>> >> EMIF is basically identical to GPMC. The interface uses DMA to move
>>> data
>>> >> in 2K chunks between the FPGA and memory. This is the largest
>>> >> transfer
>>> >> possible due to how we connected the address and data lines
>>> >>
>>> >> My impression of the current limiting factor is interrupt response
>>> time.
>>> >> There is probably some room for small improvements, but as Ben notes,
>>> we
>>> >> are already collecting data faster than the ARM can swallow it.
>>> >>
>>> >> Philip
>>> >>
>>> >>>
>>> >>> Regards
>>> >>>
>>> >>> On Thu, May 24, 2012 at 9:01 AM, Ben Hilburn <address@hidden>
>>> >>> wrote:
>>> >>>
>>> >>>> The CPU sets up the initial DMA parameters, but from then on, it's
>>> pure
>>> >>>> DMA.  No CPU is required.
>>> >>>>
>>> >>>> Cheers,
>>> >>>> Ben
>>> >>>> ----------------------------
>>> >>>> Ben Hilburn <http://goo.gl/5DdZ3> @ Ettus Research,
>>> >>>> LLC<http://www.ettus.com/>
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>> On Wed, May 23, 2012 at 5:55 PM, Page Jack <address@hidden>
>>> >>>> wrote:
>>> >>>>
>>> >>>>> Thanks, does the ARM memory bus use DMA or it eat cpu?
>>> >>>>>
>>> >>>>>
>>> >>>>> On Thu, May 24, 2012 at 5:06 AM, Ben Hilburn
>>> >>>>> <address@hidden>wrote:
>>> >>>>>
>>> >>>>>> Page -
>>> >>>>>>
>>> >>>>>> The memory bus to the ARM provides 40 MBytes / second.  This is
>>> used
>>> >>>>>> for
>>> >>>>>> streaming samples, as controlled via software.  Currently, UHD
>>> supports
>>> >>>>>> 16
>>> >>>>>> bit and 8 bit samples for TX & RX.  The GPMC can only going to
>>> talk to
>>> >>>>>> one
>>> >>>>>> slave at a time; the possible slaves are TX, RX, and ethernet.
>>> >>>>>> So
>>> you
>>> >>>>>> can
>>> >>>>>> only be sending TX samples, receiving RX samples, or
>>> >>>>>> communicating
>>> via
>>> >>>>>> ethernet.
>>> >>>>>>
>>> >>>>>> Thus, doing the math with the numbers above, you can stream:
>>> >>>>>> 16 bit I, 16 bit Q -- Total: 32-bit samples -- @ 10 MSps
>>> >>>>>> 8 bit I, 8 bit Q -- Total: 16-bit samples -- @ 20 MSps
>>> >>>>>>
>>> >>>>>> What you choose to do with this data is obviously up to you. It
>>> >>>>>> is
>>> >>>>>> very
>>> >>>>>> easy to try to do more processing than the ARM can handle, in
>>> >>>>>> which
>>> >>>>>> case
>>> >>>>>> samples will start getting thrown out by UHD.  Thus, you can
>>> typically
>>> >>>>>> process between 4 and 8 MHz of baseband bandwidth, depending on
>>> your
>>> >>>>>> application.  If you are willing to dig deep into the code to
>>> >>>>>> make
>>> NEON
>>> >>>>>> and
>>> >>>>>> C64 optimizations, you can improve the performance dramatically.
>>> >>>>>>
>>> >>>>>> Cheers,
>>> >>>>>> Ben
>>> >>>>>> ----------------------------
>>> >>>>>> Ben Hilburn <http://goo.gl/5DdZ3> @ Ettus Research,
>>> >>>>>> LLC<http://www.ettus.com/>
>>> >>>>>>
>>> >>>>>>
>>> >>>>>>
>>> >>>>>> On Tue, May 22, 2012 at 7:47 PM, Page Jack
>>> >>>>>> <address@hidden>wrote:
>>> >>>>>>
>>> >>>>>>> Hi,
>>> >>>>>>> I want to know the overo model used in e100 and the largest data
>>> >>>>>>> transfer rate between fpga  and overo in e100.
>>> >>>>>>>
>>> >>>>>>> Regards!
>>> >>>>>>>
>>> >>>>>>> _______________________________________________
>>> >>>>>>> USRP-users mailing list
>>> >>>>>>> address@hidden
>>> >>>>>>>
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>> >>>>>>>
>>> >>>>>>>
>>> >>>>>>
>>> >>>>>
>>> >>>>
>>> >>>
>>> >>>
>>> >>>
>>> >>> _______________________________________________
>>> >>> USRP-users mailing list
>>> >>> address@hidden
>>> >>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>> >>
>>> >
>>> > _______________________________________________
>>> > USRP-users mailing list
>>> > address@hidden
>>> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>> >
>>>
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> address@hidden
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>