[U-Boot-Users] Some RFCs about U-Boot's the generic FPGA support

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

Laurent,

On Tuesday 21 August 2007 13:33, Laurent Pinchart wrote:
> On Tuesday 21 August 2007 12:46, Matthias Fuchs wrote:
> > Laurent,
> >
> > now things are getting clearer.
> > All this sounds to me that the shift direction in
> > slave serial mode is not compatible to the parallel download
> > code. When we say that fpga_load (and the fpga load command) should only
> > work for promgen files with mirrored bits and fpga_loadbitstream()
> > (and the fpga loadb command) should be used for .bit files, I
> > would like to get rid of the mirroring at least for slave serial mode
> > because changing the shift order is much more efficient.
> 
> If I understand things well, you would like to get rid of the bit mirroring 
> code to optimize slave serial loading (where changing the shift direction has 
> no performance impact).
yes.
> 
> > Bruce suggested a CONFIG option to turn on/off mirroring. This is
> > not the right way. It should be handled by the FPGA subsystem.
> 
> Agreed.
> 
> > What about passing a bitorder flag down to the load functions?
> > So we get rid of the huge malloc in loadbitstream and we can
> > just swap bits in parallel mode just before writing it to the
> > FPGA port.
> 
> Would it have an impact on slave parallel performances ? Mirroring each byte 
> separately in the slave parallel code might slow things down. I personally 
> don't use the bitstream mirroring code (I use PROM files, so the bitstream is 
> mirrored on the host before loading it to the target flash memory), but it 
> might affect other users.
Well, there is only one public board that uses the FPGA code.

> 
> > For Slave serial mode the _load funtion can use 
> > the correct shift direction and so swapping is needed.
> 
> I suppose you mean "swapping is not needed", as the load function would choose 
> the shift direction depending on the bitorder flag.
yes, of course.
> 
> it seemed cleaner to me to handler mirroring at the high level, so lower-level 
> layers wouldn't have to care about it. If you want to optimize performances, 
> why don't you use a PROM file instead of a .bit file ?
We never used prom files before:-) And as you have noticed I was not aware of this
mirroring issues before. I also do not want to miss the informational header of the 
.bit files.

In the end I will starting fixing the current implementation keeping the swapping
in 'loadb' but this means that the shift direction of the serial slave functions
must be changed.

Matthias