From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matthias Fuchs Date: Mon, 12 Nov 2007 10:45:28 +0100 Subject: [U-Boot-Users] RFC: Some improvements for the FPGA subsystem In-Reply-To: <473827BA.1750.2697C2@w.wegner.astro-kom.de> References: <200711111745.02822.matthias.fuchs@esd-electronics.com> <473827BA.1750.2697C2@w.wegner.astro-kom.de> Message-ID: <200711121045.28656.matthias.fuchs@esd-electronics.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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