Spartan6 Mutiboot實現方法記錄


ISE版本爲:ISE 14.5




按照上圖需要在FPGA外置的Flash芯片中放置3個image,分別是Header、Golden和Multi,依據UG380文檔(Spartan 6的data sheet)要求,Header必須放在0x00000000位置;

Header、Golden和Multi Image可以通過ISE軟件來生成,方式如下:










 通過上述方式的設置,生成兩個bit文件,一個是Golden,另一個是Multi,而Header放在了Golden bit的開頭,如下圖所示:


 上述方法將Golden Image放在了0x00000044位置,將Multi Image放在了0x00400000位置



D:\Xilinx\14.5\ISE_DS\ISE\bin\nt64\promgen.exe -u 0 filename.bit -p bin -w -b










 通過上圖可以看出Golden bit與Multi bit的主要區別是多了一些字節,而這些字節就是Header,具體含義如下:

FFFFFFFF       // dummy word, dummy word 
AA995566        // sync word
32610000        // 3261=GENERAL1 0x0000是Multiboot image localtion地址的低16位,即[15:0]
32810340        // 3281=GENERAL2 0x03=SPI x1 read command 0x40是Multiboot image localtion地址的高8位,即[23:16]
32A10044        // 32A1=GENERAL3 0x0044是Golden image localtion地址的低16位,即[15:0]
32C10300        // 32C1=GENERAL4 0x03=SPI x1 read command 0x00是Golden image localtion地址的高8位,即[23:16]
30A1000E        // IPROG Command
20002000        // NOOP, NOOP
20002000        // NOOP, NOOP

不過這裏面有個疑問,依據上面的解釋Golden的地址是0x000044,但是golden bit的0x44位置還處於Header中,是不是這個地址有問題呢?其實不是,因爲真正燒錄到Flash中的是bin文件,再看一下Golden bin文件的結構:


 可以看到Golden bin文件中Golden恰好處於0x44這個地址處。


  1. ug380.pdf



There are three images for MultiBoot configuration. The first image is the Header. This
small bitstream contains the sync word, sets the addresses for the next bitstream as well as
the fallback or golden bitstream, and ends with an IPROG command. To generate this
bitstream automatically, add the BitGen option -g next_config_addr when creating
the programming file for the golden bitstream.
The second image is the MultiBoot bitstream. This is the bitstream that the user plans to configure first. The location of this bitstream is defined by the values of GENERAL1,2. The upper eight bits of the GENERAL 2 register are reserved for the opcode for the non-volatile device. See Chapter 5, Configuration Details, for more information. The third image is the fallback or golden bitstream. This bitstream is known to be “safe” should an error occur consistently during configuration. The location of this bitstream is defined by the values of GENERAL3,4. As with GENERAL1,2, the upper eight bits of GENERAL4 are reserved for the opcode of the non-volatile device.
If the configuration fallback occurs and the golden bitstream is reached, the only way to boot back into the MultiBoot bitstream (located at GENERAL1,2) is to toggle the PROGRAM_B pin, power cycle the device, or use IPROG reconfiguration (see IPROG Reconfiguration, page 136)
For designs that use more than two bitstreams, the GENERAL1,2 values must be set to the location of the next bitstream then an IPROG command needs to be issued. GENERAL3,4 values should be reserved for the fallback bitstream.
The header image must start at address 0. This image has three “strikes” allotted to it. If a CRC error is detected, the strike count increments and configuration restarts if the register setting RESET_ON_ERROR is 1 (located in the register COR2, and can be set from BitGen setting -g Reset_on_err) and the strike count is less than 3. The same behavior occurs if the watchdog timer times out, but it does not depend on RESET_ON_ERROR. The strike counter is found in the BOOTSTS registers. If the count is 3, configuration halts with INIT and DONE driven Low. To clear the strike count, perform a hard reboot (pulse the PROGRAM_B pin) or cycle power.
The MultiBoot image can reside at any address specified in GENERAL1,2. This image has three “strikes” allotted to it. If an error is detected, the strike count increments and configuration will restart at the address specified in GENERAL1,2 if the count is less than 3 and RESET_ON_ERROR is 1. If the count hits 3, configuration moves to the fallback bitstream located at GENERAL3,4. There are two ways to clear the strike count: power cycle the FPGA or pulse the PROGRAM_B pin.
The fallback (or golden) image can reside at any address specified in GENERAL3,4. This image has 3 strikes allotted to it. If an error is detected, the strike count increments and configuration will restart at the address specified in GENERAL3,4 if the count is less than 6. The value is 6 because it shares the strike counter with the MultiBoot image. If the count reaches 6, configuration boots back to zero, where the header image is located. When this occurs, configuration will attempt both the MultiBoot image and the fallback image three more times before halting configuration. This results in a strike count of 9. ************************



鏈接 中的內容如下:

Multiboot with Spartan 6
Jump to solution


I have a problem with programming multiboot designs to a configuration flash. The issue is, to generate a fallback design with a single multiboot design. I am using a XC6LX45T with an 128MBit SPI Flash and ISE 13.2 with Windows 7.


In the properties dialog of "Generate Programming File" in the fallback / golden design, I activate "Place MultiBoot Settings into Bitstream" an set "-g next_config_addr" to 0x200000. The "-g golden_config_addr" value is 0x0, i hope this is set automatically, because i don't know the length of the header. "-g next_config_new_mode" must be set, else ISE return an error while generating the bitfile. "-g next_config_boot_mode" is set to 001, i hope this is the setting for 1x SPI.


In the master / multiboot design i do not activate these options. Only "-g reset_on_error" is active.


With impact i generate a prom file with two revisions. The first was the golden bitfile and the second was the master bitfile with an offset 0x200000. Programming fails because DONE does not rise high.


My question is, is this the right design flow for multiboot designs? Is there anything else to know? Is there a mor detailed documentation than ug380?


with best regards, lodentoni


P.S. Configuring the fpga with singleboot designs out of the flash works without problems.


Hi Lodentoni,

It looks to me that you have the same problem I had. Bitgen seems to clear SPI read command, which should be placed in the highest byte of the next config address. To overcome this problem, please add the SPI read command to to bitgen script as follows

"-g next_config_addr" to 0x200000

"-g next_config_addr" to 0x03200000


"-g golden_config_addr" 0x0

"-g golden_config_addr" 0x03000044"




PS: I have reported this bug to Xilinx and it will be fixed to ISE 13.3(但是Xilinx沒有修改,反正ISE 14.5中沒有修改



View solution in original post


 鏈接 中的內容如下: 

        Spartan 6 multiboot - Fallback does NOT work
Jump to solution

I think my issue is related to the header file. I followed the instructions given by siktap in this thread:


I have a golden image where leds blink quickly.

I have a multiboot image where leds blink slowly.

Both images have been tested stand-alone and work as expected.


On power-up, the multiboot image loads properly. However when I corrupt the multiboot image in the flash memory, the golden image does NOT get loaded; nothing happens and the fpga does not boot up. It seems like I might be missing an important value in one of the registers?


Here is the content of my boot_header.hex:


AA995566     //  SYNCWORD
32610000     //  3261=GENERAL1 0x0000=address[15:0] MultiBoot image location
32810340    //  3281=GENERAL2 0x03=SPIx1 read command, 0x40=address[23:16] MultiBoot image address
32A10000 //  32A1=GENERAL3 0x0000=address[15:0] Golden image address location
32C10301 //  32C1=GENERAL4 0x03=SPIx1 read command, 0x01=address[23:16] of Golden image address
33012100   // IS THIS SET PROPERLY?
20002000    //  NOOP, NOOP
20002000    //  NOOP, NOOP


Here is how I generate the .mcs for my header:

promgen -w -p mcs -r boot_header_only.hex -o boot_header_only.mcs


Here is how I generate the .mcs for the two images:

promgen -w -p mcs -spi -s 16384 -u 010000 goldenFastBlink.bit -u 400000 MultibootSlowBlink.bit -o image_no_header.mcs


And then I add the content of boot_header_only.mcs in the beginning of image_no_header.mcs. I know for a fact that this (at least) partially works because my image at 0x004000000 gets loaded properly. If I try to corrupt a sector in the multiboot image region (let's say 0x00410000), the fallback mechanism does NOT work and NOTHING happens.


Is this related to my header file? What am I doing wrong?


1 Solution
Registered: ‎04-06-2012



Hi, I figured out what was wrong with my design. I had the '-g reset_on_err:yes' option for both the golden and multiboot images since it was mentionned in the thread I linked, so this option wasn't the issue. However, one very important information was missing from that thread.


My problem is that the multiboot image was being compiled with next_config_register_write:enable parameter, which is set by default. In a workflow similar to the reference thread I linked, the manually compiled header contains the important addresses. These addresses are neither found in the golden nor the multiboot images. For this reason, next_config_register_write MUST be set to next_config_register_write:disable for the multiboot image, otherwise the system flow is as follows:


  1. The header commands are executed and the multiboot and golden start addresses are set in the proper registers
  2. The multiboot address is loaded. However since the program is compiled with next_config_register_write:enable, the values for the golden and multiboot addresses that were set at step number 1 get erased and replaced by what I assume are default values (0x000000 everywhere?!).
  3. Assuming the multiboot image gets corrupted on purpose, the system is unable to fallback to the golden image because the address registers have been modified when the corrupted multiboot image was read.

I'm not yet sure if next_config_register_write must be set to enable/disable or if it is irrelevant for my project. I believe it is irrelevant since the golden image only exists to run a minimalist server that will enable me to write a new multiboot image to the memory. After doing so, the system will be rebooted anyway and the header in the flash should be read again, which will load the multiboot image. I believe it would be important if I planned to use icap to handle the signals directly to load the multiboot image without rebooting.


View solution in original post


還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.