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

[Uwe B. <bo...@el...>]

>>>>> "Á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? 

    Á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.

    Á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.

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.

Bye

-- 
Uwe Bonnes                bo...@el...

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------