FPGA START-UP

Now that you’ve got an idea of how the LUB works, lets look at the technical details. At start-up, the ATmega88’s program will normally remain stored in flash memory, so there is no need to reprogram it. However, the FPGA has its program stored in SRAM, which means you need to configure it every time you power up.

Kim Goldblatt outlines the programming algorithm for the Xilinx Spartan series of FPGAs in the application note, “The Low-Cost, Efficient Serial Configuration of Spartan FPGAs.” Kim also describes the process of generating the programming files.

The algorithm used in the LUB was designed to work with the Atmel DataFlash parts. First, it sets the DataFlash to start reading from the page that stores the FPGA bitstream. Second, it pulses the PROGRAM pin low for several clock cycles. Third, it waits for the INIT line to go high. Fourth, it clears the CCLK pin. Fifth, it delays about 100 µs. Sixth, it pulses SCK to the DataFlash to get 1 bit. Seventh, it puts that bit on the DI line of the FPGA. Eighth, it pulses CCLK to the FPGA. And finally, if the FPGA’s DONE pin is low, it jumps to the sixth step. Otherwise it exits.

The application note doesn’t tell you how to use the convenient bit file, which is generated by Xilinx ISE to program your device. The document does include information about using the rawbits file, but it isn’t generated by default. The bit file is a direct bitstream that you can download to the FPGA without much processing. Well, almost. There is some text at the beginning of the file that needs to be separated from the actual raw binary to download. Luckily, it has been reverse engineered. Some detective work on your part will make it easy to see.

Listing 1 is what the bit file looks like in hex format with about 80 bytes in it. The exact location isn’t constant, but the format is. The 0x65 byte is followed by 4 bytes that indicate the file size in bytes. In this example, it’s 0x0002C01C, which is 180252 in decimal format.

For my Spartan-IIE with 200,000 gates, that is the exact size for the configuration file specified in the datasheet. Because the configuration file size will never use more than 3 bytes in this system, the 0x65 0x00 combination can be used as the synchronization byte. Following this, 3 bytes are skipped, and data loads in starting with the 0xFF byte and ending with the end of the file. At the end of the file, several 0xFF bytes need to be shifted in.

For the LUB system, the bitstream stored in the AT45DB041B is padded with 0xFF. This means that the tinyloader doesn’t have to keep track of a 24- or 32-bit counter. It doesn’t have to figure out how many bytes have been put in the system, how many more need to go, or when to shift in extra 0xFF. Instead, it simply shifts bytes until the DONE pin goes high. If the system must start when the FPGA is incorrectly loaded, the INIT pin can be checked as well. If the INIT pin goes to a low state from a high state while loading configuration memory, the CRC embedded in the bitstream is incorrect and the FPGA won’t start.