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 >> >> > _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
