RE: [microblaze-uclinux] optimized memcpy() based on DMA transfer

[Brettschneider Falk <fbrettschneider@xxxxxxxxxxxxxxxxx>]

Hi,

We want to constantly copy much image processing data or parts of it. The C
application is cross-platform and also runs on e.g. SuSE Linux, that's why
I'd like to use a common library function (like memcpy()). But it seems we
have to create our own special DMA engine in the FPGA (with a bigger buffer)
and a myMemcpy() function which uses that DMA engine to get things fast
enough on the device with the microblaze. Right? I just want to prevent the
reinvention of the wheel before we start doing such stuff, that's why I'm
asking if we don't see feature which are already ready to use.

Cheers
F@lk

> -----Original Message-----
> From: owner-microblaze-uclinux@itee.uq.edu.au
> [mailto:owner-microblaze-uclinux@itee.uq.edu.au]On Behalf Of Kristian
> Chaplin
> Sent: Thursday, March 31, 2005 12:26 AM
> To: microblaze-uclinux@itee.uq.edu.au
> Cc: Kristian Chaplin
> Subject: RE: [microblaze-uclinux] optimized memcpy() based on DMA
> transfer
> 
> 
> Hi John, Falk,
> 
> The OPB Central DMA does have a 16 word buffer.  OPB does not have
> burst, but does have something similar "sequential addressing", so I
> would expect some speedup for peripherals that could make use 
> of it such
> as DDR, as the latency for DDR / SDRAM us usually for the first
> transaction - subsequent transactions typically can take a lot less
> time, if sequential addressing is used.
> 
> Best regards
> 
> Kris
> --
> 
> --------------------------------------------------------------
> ----------
> ----
> / /\/ Kris Chaplin
> \ \   Application Engineer - Embedded Processors
> / /   Xilinx Europe
> \_\/\ +44 (0)870-7356-563
> 
> 
> -----Original Message-----
> From: owner-microblaze-uclinux@itee.uq.edu.au
> [mailto:owner-microblaze-uclinux@itee.uq.edu.au] On Behalf Of John
> Williams
> Sent: 30 March 2005 22:15
> To: microblaze-uclinux@itee.uq.edu.au
> Subject: Re: [microblaze-uclinux] optimized memcpy() based on DMA
> transfer
> 
> Hi Falk,
> 
> Brettschneider Falk wrote:
> 
> > has someone implemented a specially optimized version of memcpy() or
> similar
> > that uses DMA to put the data in the SDRAM, probably on sizes >
> minimum? I
> > suppose the current memcpy() just passes DWORD by DWORD by bus... 
> 
> I've thought about it, and when I googled it a while ago, it 
> was clear 
> that many others had as well :)
> 
> For microblaze systems with no ICACHE, it might make sense, but 
> otherwise you'd really have to wonder how much improvement would be 
> made. The inner loop of the optimised memcpy would be in cache, 
> executing at 2 cycles per instruction, it's the OPB latency 
> (reading/writing to/from the OPB_SDRAM/DDR) controller that 
> will become 
> the limiting factor.
> 
> AFAIK EDK's standalone DMA engine has no internal buffering, and does 
> not do burst transfers - it's essentially just a programmable 
> OPB-talking state machine.  For memory to memory transfers, I don't 
> think you'd win.  However, it would still be an interesting 
> experiment, 
> and pretty quick to try out.  Another example of experimental 
> computer 
> architecture!
> 
> John
> 
> ___________________________
> microblaze-uclinux mailing list
> microblaze-uclinux@itee.uq.edu.au
> Project Home Page : 
> http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
> Mailing List Archive :
> http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/
> 
> 
> 
> 
> ___________________________
> microblaze-uclinux mailing list
> microblaze-uclinux@itee.uq.edu.au
> Project Home Page : 
> http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
> Mailing List Archive : 
> http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/
> 
___________________________
microblaze-uclinux mailing list
microblaze-uclinux@itee.uq.edu.au
Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
Mailing List Archive : http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/