On 05/30/2012 11:46 AM, Ian Buckley wrote: > 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.
If you need to do the processing on an ARM, you should research this company: http://www.calxeda.com/products/energycards/quadnode Philip > > > 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" <jack.page...@gmail.com> wrote: >> Hi Almohanad , >> thanks for this information, can you provide more detail or is there any doc? >> >> On 5/30/12, Almohanad Fayez <almohanad.fa...@gmail.com> 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" <jack.page...@gmail.com> 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 >>>> <phi...@balister.org>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 <phi...@balister.org> 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 <ben.hilb...@ettus.com> >>>>>>>> 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 <jack.page...@gmail.com> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Thanks, does the ARM memory bus use DMA or it eat cpu? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Thu, May 24, 2012 at 5:06 AM, Ben Hilburn >>>>>>>>>> <ben.hilb...@ettus.com>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 >>>>>>>>>>> <jack.page...@gmail.com>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 >>>>>>>>>>>> usrp-us...@lists.ettus.com >>>>>>>>>>>> >>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> USRP-users mailing list >>>>>>>> usrp-us...@lists.ettus.com >>>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> USRP-users mailing list >>>>>> usrp-us...@lists.ettus.com >>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >>>>>> >>>>> >>>> >>>> >>>> _______________________________________________ >>>> USRP-users mailing list >>>> usrp-us...@lists.ettus.com >>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >>>> >>>> >>> >> _______________________________________________ >> USRP-users mailing list >> usrp-us...@lists.ettus.com >> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > > _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio