Spartan3E readback, SPI programming

Greetings,

I'd like to program my Spartan3E with an SPI memory normally.  For 
development at my desk, I understand I can add a header to allow IMPACT to 
configure the SPI flash memory.

We have many legacy designs that bit-bang the FPGA to program it in slave 
serial mode allowing (re)configuration by software, typically with no 
configuration RAM in the first place.

Rather than getting the software folks to write the SPI driver to reprogram 
the SPI memory through an equivalent bit-bang, I'd be interested in a 
readback of a slave-serial programmed FPGA by the FPGA while the FPGA is 
active to directly program the SPI memory with my own internal routines.

--> Any ideas on whether I can accomplish this or how best to approach it?

While writing this post I came to realize the external readback would be on 
the passive slave port, not the SPI side so the SPI persistence setting 
isn't an issue.  But will I need to double-up the passive serial port to do 
the readback through other I/O pins? 

it all works (should work) with S3e, but you would still to write your
own software to handle the SPI memory

antti

"Antti" <Antti.Lukats@xilant.com> wrote in message 
news:1144859088.483052.301100@u72g2000cwu.googlegroups.com...
> it all works (should work) with S3e, but you would still to write your
> own software to handle the SPI memory
>
> antti

The information I've gathered so far suggests readback is available through 
Slave Parallel or JTAG modes.  I don't seem to find internal readback 
capability.  To read back through the JTAG port, I'd expect to have to 
interface to the JTAG pins externally through four other I/O.

Can I configure with Slave Serial and do the readback through JTAG?

If I'm trying to do this on board as opposed to through the Xilinx tool 
suite I don't see how "it all works" with the info I've perused so far. 

John_H wrote:
> The information I've gathered so far suggests readback is available through
> Slave Parallel or JTAG modes.  I don't seem to find internal readback
> capability.

To read or write the SPI eeprom after config, you bit-bang the SPI pins
from the fpga like any other IO pin.  All of the SPI pins are general
purpose IO pins.

Or perhaps I don't understand the question.

Alan Nishioka

"Alan Nishioka" <alan@nishioka.com> wrote in message 
news:1144865199.566139.147490@u72g2000cwu.googlegroups.com...
> John_H wrote:
>> The information I've gathered so far suggests readback is available 
>> through
>> Slave Parallel or JTAG modes.  I don't seem to find internal readback
>> capability.
>
> To read or write the SPI eeprom after config, you bit-bang the SPI pins
> from the fpga like any other IO pin.  All of the SPI pins are general
> purpose IO pins.
>
> Or perhaps I don't understand the question.
>
> Alan Nishioka

To bit-bang the SPI pins through external software that's used to 
configuring FPGAs through Slave Serial configuration, a new software driver 
that's SPI NAND capable would heve to be developed to provide "new" bit 
banging.  If I left it in the hardware realm, reprogramming the SPI based on 
the FPGA's *own configuration* would be desirable, leaving the NAND 
programming details to me in the hardware.

My need becomes reading back the configuration from the device itself by the 
device while the device is operating. 

basically if you just keep generating CCLK from FPGA then the original
bitstream will appear after the spi flash "wraps around" so if you just
toggle cclk and monitor for the bitstream signature then you get the
original fpga bitstream read back :)

antti

John_H wrote:
> If I left it in the hardware realm, reprogramming the SPI based on
> the FPGA's *own configuration* would be desirable, leaving the NAND
> programming details to me in the hardware.
>
> My need becomes reading back the configuration from the device itself by the
> device while the device is operating.

So you want to have an fpga read its own configuration from itself and
program an SPI eeprom?  Won't that allow it to program itself, and
eventually take over the planet?

Isn't a lot of information missing from such a readback, such as all
the register init states and the bram init?

Alan Nishioka

"Antti" <Antti.Lukats@xilant.com> wrote in message 
news:1144867908.073506.152680@e56g2000cwe.googlegroups.com...
> basically if you just keep generating CCLK from FPGA then the original
> bitstream will appear after the spi flash "wraps around" so if you just
> toggle cclk and monitor for the bitstream signature then you get the
> original fpga bitstream read back :)
>
> antti

1) set switch to Slave Serial
2) (re)configure device with software
3) tell device to reprogram SPI flash with current configuration
4) set switch to SPI programming
5) no software programming required

I don't want to reprogram the SPI memory with the original SPI contents. 

"Alan Nishioka" <alan@nishioka.com> wrote in message 
news:1144867944.717365.44000@j33g2000cwa.googlegroups.com...
> John_H wrote:
>> If I left it in the hardware realm, reprogramming the SPI based on
>> the FPGA's *own configuration* would be desirable, leaving the NAND
>> programming details to me in the hardware.
>>
>> My need becomes reading back the configuration from the device itself by 
>> the
>> device while the device is operating.
>
> So you want to have an fpga read its own configuration from itself and
> program an SPI eeprom?  Won't that allow it to program itself, and
> eventually take over the planet?
>
> Isn't a lot of information missing from such a readback, such as all
> the register init states and the bram init?
>
> Alan Nishioka

*visions of Terminator dance in my head*

Whether there's missing readback info is an *excellent* question.  I just 
assumed that the configuration chain included all the original info; the 
BlockRAM is one point where my assumption wouldn't make a lot of sense.

So, readback without the CAPTURE... does it include the initial REG values? 
Does it include the current (not initial) contents of SRLs and CLB 
SelectRAM?  Does it include current BlockRAM contents?
______

I'm suspecting I would do much better to have software interface to the FPGA 
as if it were bit-banging in the Slave Serial mode but without reprogramming 
the device.  This gives me a system-sourced .bin file that I can push into 
the SPI through my own FPGA routines. 

noway! you cant cheat!

there is software programming involved!

xilinx is maybe adding indirect spi flash programming in ISE 9 or 10,
so if you wait...

Antti
PS both Altera and Lattice support direct SPI flash programming from
Quartus/ispLEVER