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