[U-Boot-Users] RFC: Some improvements for the FPGA subsystem

[Matthias Fuchs <matthias.fuchs@esd-electronics.com>]

Hi,

On Monday 12 November 2007 10:15, w.wegner at astro-kom.de wrote:
> I have one wish on my list:
... you haven't seen my wishlist :-)
> 
> Would it be possible to have an optional "block write" function for the FPGA?
yes.
> 
> While I appreciate the current approach of single bit functions for the FPGA
> to be very convenient for board bring-up, it is somewhat slow on the larger
> FPGAs (with something like 1.5 MByte bitstream size).
> 
> An additional block write function that - if present - replaces the internal
> (generic) programming algorithm would give a clean way to use the existing
> FPGA infrastructure (commands, image handling, pre- and post-configuration)
> and switch to a fast load for production use.
> 
> Only then, you could take advantage of buses like SPI for FPGA load, too.
I was in a similar situation some time before. Our PMC440 board (patches have
been posted yesterday) uses a Spartan3E FPGA that is programmed in slave serial 
mode. I started with download time about 13 seconds (!!!). The main reason 
is the extensive use of callbacks by the FPGA subsystem. Then updated the boot 
code to use U-Boot's slave parallel implementation to boot the FPGA still in
slave serial mode. My write-data-byte function just shifts out the byte bit by bit.
This improved the download time to about 3 seconds. The last step was to
enable the cache for the 440 CPU. This speeds things up to an acceptable level.

But I agree, a block write function would be cleaner.
> 
> (I hacked something like this in my local u-boot, and the speed-up for
> FPGA loading was significant, at least 3 times. And I still did not
> implement the SPI path because I did not have the time yet...)
If you already have something it might be a good idea to share your work
with us. I think this is independent from what my patch does at the moment.

Matthias