| There is a mictor connector (J301 on both USRP2 and N2x0) that has 32 signal and 2 clock pins all free to be used in the FPGA. Searching for "mictor" in the archive of this forum will find other posts about this.
However I do want to drive home the point that you are unlikely to find an ARM processor currently that is capable of doing anything useful directly with RF data at bandwidths greater than which the E100 is capable or indeed one with a flexible physical interface that can support 60MB/s....you're clearly in the realm of high-end DSP processors at those rates.
On May 30, 2012, at 8:02 AM, Almohanad Fayez wrote: I don't believe there's a document for this it's more of an exercise left for the motivated user.
On May 30, 2012 6:27 AM, "Page Jack" < address@hidden> wrote:
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
>>
>>
>
USRP-users mailing list
address@hidden
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
|