Re: [Xc3sprog-users] SPI programming - delayed reads

[Álvaro L. <alv...@al...>]

Uwe Bonnes wrote:
>>>>>> "Álvaro" == Álvaro Lopes <alv...@al...> writes:
> 
>     Álvaro> Hi all, This is my first post to this list, and I'd like to
>     Álvaro> thank all of you for the excellent work you are doing with this
>     Álvaro> project. I've been using it (actually variants of it) for a long
>     Álvaro> time, and I feel it's time to go mainline and contribute my
>     Álvaro> changes for the project benefit.
> 
>     Álvaro> Right now I'm porting SST SPI flash programming algorithms to
>     Álvaro> upstream. They are based on very old source code, and there were
>     Álvaro> significant changes to BSCAN based approach - right now there is
>     Álvaro> no way to do a full transfer (write+read) on same transaction.
> 
>     Álvaro> SST uses AAI programming (Auto Address Increment), and they
>     Álvaro> support busy reply at end of each command.
> 
> Could you give a part number, so that we can have a look at teh datasheet
> and the algorithm used. What FPGA parts can use these parts as configuartion
> memory? 

Sure.

SST25VF040B : http://ww1.microchip.com/downloads/en/DeviceDoc/S71295_06.pdf
SST25VF080B : http://ww1.microchip.com/downloads/en/DeviceDoc/S71296_05.pdf

As these SPI flash use standard read commands, I think all devices which support SPI bitstream load support these parts. At least S3E (250 and 500) do.

> 
>     Álvaro> The latest BSCAN
>     Álvaro> approach stores the last scanned-in result in BRAM, and we have
>     Álvaro> to do another request in order to fetch last buffer reply (at
>     Álvaro> least, that's how I understood it from the HDL sources). In
>     Álvaro> order to speed up writes (each AAI command only programs 2 bytes
>     Álvaro> at a time) having to check status register, or do another
>     Álvaro> transaction, has a huge impact on write performance.
> 
>     Álvaro> My first suggestion (and I'll do implementation) is to have two
>     Álvaro> modes when using BSCAN+SPI: one where SPI output is directly
>     Álvaro> mapped to TDO output, and other which uses the current BRAM
>     Álvaro> buffer. This can easily be implemented by a bit-mangling on the
>     Álvaro> 32-bit header. So, at every request, you can specify whether you
>     Álvaro> want the current value to be output, or the last scanned in
>     Álvaro> value (as in current implementation)
> 
> Do both areas overlap in more items? If overlap is few, I would propose to
> write a whole new progalgspixxx class and not touch progalgspiflash.

They are a small exception, like current AT45. In fact, perhaps creating two new classes for these devices would be a good thing.

>     Álvaro> Questions, thoughts ?
> 
> Does any other project already cover that task, e.g. coreboot, openocd or
> urjtag? There is a similar area with AVR direct SPI programming. This is
> already done in avrdude.

Not sure. We have been using this project for long now, because of its versatility (and because it's not very complex).

> But even if there is a similar approach elsewere, your contribution is
> welcome. But try to not add to much more command line options and think
> about encapsulation and reuse.

No new command line options. All things are reused and properly encapsulated. Actually there are also some other changes I made you might be interested in
(which target code cleanup, reuse and understanding).

Best,
Álvaro