FPGA serial PROM programming

[rakeshm55]

Hi...
I use a 7series xilinx FPGA in master spi mode....where in FPGA will self configure from a serial prom...I use FPGA JTAG for loading bit file to PROM....now for factory production/ infield updations how can i load bit file to PROM...should I use a uC to load bit file to PROM....or does xilinx FPGA provide an alternate mechanism...pls suggest

[nctnico]

What kind of interfaces does your device have? On Spartan 6 you can use the programming pins as normal pins once the device is configured so you can have the FPGA load a new configuration from a certain source. I'm guessing newer FPGAs have the same feature. You could implement a softcore + serial interface to allow the upload of a new FPGA configuration. Be sure to add checksums though because it is easy to brick a device this way. IIRC there are some provisions to have multiple images in the same flash in case the primary image gets corrupted.

[jmelson]

Xilinx FPGAs can load from a variety of devices, based on the setting of the Mode pins.  They can take serial downloads from serial PROMs that have address counters in them, or parallel PROMS, that is called master mode, where the FPGA provides the serial clock  Or, there is slave mode, where a micro provides the clock.  It is all described in a Xilinx tech document, and they tell you what makes of serial PROMS they support.

I use an SST serial PROM (I think now made my Atmel) because it is about $0.86 in small quantity, and the Spartan 2E and 3 FPGAs support the initialization of the PROM.  I'm pretty sure the Spartan 7 also support it.  I made a custom programmer for it, it is just a serial protocol.

Jon

[NorthGuy]

7-series can configure themselves from SPI/SQI flash (40-50 cents, depending on the size).

[rakeshm55]

Thanx for suggestions....
I already have a uC in board...FPGA mode pins are configured for Master SPI mode....initial idea was use config pins as normal pins and allow uC to have access to PROM via FPGA...a wrong config file can brick FPGA....this is one reason to think of directly writing to PROM via uC rather than relying on FPGA....or if there is a multi boot option were a default bit file is loaded for updating application bit file....incase of bricking.....default can lie in another boot mode...

[rakeshm55]

""I made a custom programmer for it, it is just a serial protocol.""...can u explain this....

[NorthGuy]

If you have JTAG, you can configure FPGA through JTAG. Then you can load a special design which reads bitstream data from JTAG and program the flash accordingly. That's what Xilinx tools do. If flash gets corrupted, you can simply re-program it through JTAG. Therefore, it is impossible to brick the board. The only way you can brick it is if the config flash becomes damaged and cannot be written to. Even in this case, you simply re-solder a new flash chip and it works again.

Depending on what you like, you can pre-program (and verify) the flash before assembly, or you can use JTAG to program it after assembly.

[dgtl]

If you have a uc on the board already, it is simple to use that for the flash programming if the uc has fast enough interface to load the data from(bitstreams are large enough not to load via UART). Just connect the SPI flash to both the FPGA and uC. In addition connect the INIT_B, PROGRAM_B and DONE to uC to be able to monitor and control the FPGA load process.
I have used full-speed USB (DFU, serial or custom protocol) or Ethernet (TFTP etc) connected to uC to load the bitstream at the factory or FW update. The uC keeps its SPI tristated and first releases INIT and PROGRAM to let the FPGA init itself. If the init fails (no bitstream in flash or corrupted), error is indicated by FPGA via pulling INIT low. If all goes well, it is indicated by DONE. The uC will report it back to PC. If the PC wants to program the FPGA, I pull the INIT and PROGRAM low to keep the FPGA out of the way. Then I configure the uC SPI as output and program the data. After that I tristate the SPI bus again and release the FPGA control signals to let it load the configuration.
If you have set up the FPGA to tristate the SPI flash pins, the uc can monitor the DONE signal to verify that the bitstream is there and then the uc can use the rest of the flash for its own purposes. Alternatively, you can use the same pins for communication with FPGA design as the pins are already connected to FPGA. Just use the pins as SPI slave on the FPGA and another pin for FPGA CS, leave the flash CS for uc->flash.

[radar_macgyver]

You could also wire up the JTAG interface on the FPGA to general purpose I/O on the uC. Then, write some software that will take a .xsvf or .svf file and 'replay' it by bit-banging the uC GPIO. The xsvf files can be written from Impact, you need to select the option to write to xsvf instead of writing to the JTAG port via the USB dongle. Xilinx has an xapp with code for an xsvf player, with stub functions to handle the I/O bitbang. It's quite simple to port to an embedded uC.