Spartan3E readback, SPI programming

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.

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

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

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.

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

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

----- I realize what I'll be implementing in the FPGA to interface between the existing FPGA programming drivers in our operating system and the SPI will be "software" in a sense. I don't maintain and expand the OS and those folks are sometimes too burdened to take on extra "nice to have" tasks, hence my desire to find a reprogramming interface that supports both bit-bang Slave Serial and reprogramming of the SPI flash for development (dozens of platforms). -----

----- Direct programming from the parallel cable or direct programming through some FPGA interface? I'm looking for a solution on everyones' desks, not just the FPGA developer's. I can use the XSPI utility separate from Project Navigator without concern.

"John_H" schrieb im Newsbeitrag news:q8d%f.5598$ snipped-for-privacy@news02.roc.ny...

direct means from vendors tools using standard jtaga no that X_SPI s***

- whatever you are looking for you have out-smarted me! what is that magic thing that is one everones desks and what could allow SPI programming ??

anyway nomatter what it is, as I have said its its very likely NO NO NORWAY.

Antti

The magic thing I have is the target FPGA in a system that has a processor with our own OS drivers with ethernet and USB connectivity that are live before the FPGA is ever programmed. I couldn't reconfigure the FPGA's SPI configuration memory on everybody's desk without external tools (JTAG, ByteBlaster, Parallel Cabe IV) if the FPGA were the only smarts on the board.

I'm sorry, I don't follow what you're trying to do here. However, if it helps, I can point to a couple of potential "helper" designs.

For the Spartan-3E Starter Kit board, there is a reference design that allows you to program the SPI serial Flash via the 9-pin RS-232 port on the board. The FPGA contains an embedded PicoBlaze controller that performs the actual programming.

The reference design and a short overview presentation are available at the following link.

PicoBlaze SPI Flash Programmer for the Spartan-3E Starter Kit Board

The board documentation, if it helps, is available at the following link. The chapter on SPI Flash also talks about the XSPI option, which uses an external header and a parallel-to-JTAG cable. The document is rather large because it also contains the board schematics.

UG230: Spartan-3E Starter Kit Board User Guide [11 MB]

This is also a reference deisgn using MicroBlaze, linked below.

Using SPI Serial Flash on the Xilinx Spartan-3E Starter Kit Board

Does any of this help your cause?

--------------------------------- Steven K. Knapp Applications Manager, Xilinx Inc. General Products Division Spartan-3/-3E FPGAs

--------------------------------- The Spartan(tm)-3 Generation: The World's Lowest-Cost FPGAs.

"John_H" schrieb im Newsbeitrag news:zWf%f.5617$ snipped-for-privacy@news02.roc.ny...

gosh, writing SPI flash is 26 lines of C-source code, are you really SOO lazy that you are looking into possibilities to do it without doing any programming ??

antti

I'm a hardware guy, not software. I can write disposable software but not code for our product. In our company, the software responsibility for drivers resides with software professionals responsible for maintaining and troubleshooting the production code.

Similar provisions were made by hardware for direct programming of a different configuration memory configuration but the software folks never had the time or inclination to write 26 lines of code because of schedule and priorities rather than laziness.

By taking on the task myself in hardware (Steve Knapp's pointer to a PicoBlaze solution might take care of me) I don't have to rely on those who don't understand the convenience of having a clean system to update the configuration memory.