Spartan® Family FPGAs

[jsmithsrc]

I am looking for confirmation...

It seems that in older versions of ISE, the golden image "header" (which programs GENERAL registers and commands a reboot) needed to be crafted by hand, as shown in the Xilinx example design for SP605.  Also noted in the presentation slides, that newer versions of the tools generate this header automatically.

When looking in the generated .bit file, I see the header being generated in both my golden image and my multiboot design. This doesn't seem right, but I can't figure out how to disable the header from being inserted in the multiboot design.

For reference, I am using ISE 13.3.

I have tried "-g next_config_register_write:Disable" and unchecking "place multiboot settings into bitstream" but this does not seem to matter.

If I use ICAP to jump directly to base address of where I am programming the multiboot bitstream, then it does not successfully program. If I jump to the base address of multiboot image + 0x44, then it successfully programs. (Note, the length of the multiboot header appears to be 0x44 in the bitstream...)

What am I missing here?

Questions:

0) Am I correct in my assumption that the golden image bitstream has the header (i.e. the bitstream will have two separate areas, two sync words, etc) and the multiboot image will not?

1) How do you enable/disable generation of the header for the multiboot image?

I am almost certain I keep missing the right combination of flags/options...

[bhayes47]

Hi jsmith,

Yes you are correct that the extra header is prepended to the golden image, and is located at address 0, and the golden image normally starts at 0x44.  The multiboot image does not have another header (or should not).  I'm currently using 13.2 and 13.3, and when I'm going to generate a multiboot image, I uncheck "place multiboot settings into bitstream", and it does not add the extra header to the multiboot image.  Actually, this is the normal case, I only occasionally regenerate the golden image, at which time I check that option, otherwise most of the time it is unchecked to create multiboot images.

So it would appear as if you are not actual unchecking that option, or not applying the setting.

The  "-g next_config_register_write:Disable" option replaces several register write commands near the beginning of the multiboot bitstream with NOP's, so those registers won't be rewritten by the multiboot image.  It doesn't effect whether the extra header is generated or not.

Bill

[jsmithsrc]

Ok, so there are two possible outcomes?

1) Multiboot header pre-pended with NOPs (result of -g next_config_register_write:Disable)

2) Multiboot header excluded altogether (result of unchecking "place multiboot settings into bitstream")

What is the command line equivalent to unchecking the option?

[bhayes47]

No, I guess I wasn't clear.  The multiboot header, which is 68 bytes, is located at address 0.  Following this, at address 0x44, is the golden image.  When you check "place multiboot settings into bitstream", it generates these two pieces together in one file, with the multiboot header prepended to the golden image.

When you uncheck "place multiboot settings into bitstream", it creates a normal bitstream, which is usable as a multiboot image, except for one detail, the register writes normally in the beginning of the bitstream need to be disabled.

That's where the "-g next_config_register_write:Disable" option comes into play, you use that to generate the multiboot image with the config register writes disabled.  Those register writes are in the bitstream, and are replaced with NOP's to disable them.

I don't know the command line equivalent for these options.

Bill

[jsmithsrc]

So regardless of the multiboot settings, the size of the generated multiboot bitstream will be the same, because it will always have the "header" even though it is unused/NOPs?

[jsmithsrc]

Trying to understand the differences in the bitstreams based on settings in bitgen....

Case 1: "Normal" bitstream generation (No "place multiboot settings in bitstream", No "-g next_config_register_write:Disable")

Case 2: Has "Place multiboot settings in bitstream" checked, No "next_config_register_write:Disable"

Note that in Case 2, starting at 0xB6, there are NOPs inserted to disable the configuration register writes. However, these registers are also written starting at 0x14.

So, if I wanted this bitsteam to be my multiboot image, located at some offset in flash (say 0x100000), if I point to 0x100000 with the GENERAL 1,2 registers, then the image fails to load. If I point to 0x100044, then the image will successfully load.

My feeling is that there is a way to exclude bytes 0x0 - 0x43 from the multiboot image? Of course these are necessary to correctly setup the header, which prepends the golden image.  Or is the right thing to skip this portion of the bitstream via adding constant offset to bitstream base address?

At this point I am just trying to get power on boot functionality to work and am not concerned with complications of ICAP.

"Expected functionality on power up":

• When multiboot image present & valid, end up in multiboot image (can get this to work)
• When multiboot image missing (erased), end up in golden (can get this to work)
• When multiboot image corrupted (partial erase/partial program), end up in golden (cannot get this to work)

[bhayes47]

I'm not sure what you are doing, but the bitfile you show as Case 1 is not correct, nor is it what is created with the options set as you describe.  The tools only add the extra 68 byte header when you select "place multiboot settings in bitstream".

When you don't select that option, the tools create a normal bitstream, which never has that extra header.

Here are properly formatted golden and multiboot files, and the option panel settings for the golden file creation.

The only difference to create the two files was the golden file

had the  "place multiboot settings in bitstream" checked, and the multiboot file creation had that option unchecked.

Once you have the files created correctly, your third expected functionality will work, without having to jump around an extra header, and with a partially erased flash image.  Also make sure you have the "-g CRC" and the "-g reset_on_error" options set so it will detect the bad image and retry.

Note that once you have the full multiboot functionality working, there is one other way that an incorrect multiboot image can break the process, such that it won't fallback to the golden image.  If you accidently load a non-multiboot image into the multiboot location (one that wasn't created with the "-g next_config_register_write:disabled"), and some portion of that image past the initial portion is partial erased, then the config registers will get overwritten, and the configuration will fail.

Then it's back to the JTAG cable.

Bill

[jsmithsrc]

Here is the full command line, copied right out of the bitgen report, and the corresponding file that was generated.

This is not what you are showing me, and not what I would expect. I am not sure what I am doing wrong.... Is this a software bug?

C:\Xilinx\13.4\ISE_DS\ISE\bin\nt64\unwrapped\bitgen.exe

-intstyle ise

-g next_config_register_write:Disable

-w

-g DebugBitstream:No

-g Binary:yes

-g CRC:Enable

-g Reset_on_err:Yes

-g ConfigRate:4

-g ProgPin:PullUp

-g TckPin:PullUp

-g TdiPin:PullUp

-g TdoPin:PullUp

-g TmsPin:PullUp

-g UnusedPin:PullDown

-g UserID:0xFFFFFFFF

-g ExtMasterCclk_en:No

-g SPI_buswidth:4

-g TIMER_CFG:0x1FFF

-g multipin_wakeup:No

-g StartUpClk:CClk

-g DONE_cycle:4

-g GTS_cycle:5

-g GWE_cycle:6

-g LCK_cycle:NoWait

-g Security:None

-g DonePipe:Yes

-g DriveDone:No

-g Encrypt:No

-g en_sw_gsr:No

-g drive_awake:No

-g sw_clk:Startupclk

-g sw_gwe_cycle:5

-g sw_gts_cycle:4

[jsmithsrc]

Ok, I think I found what the difference is... And it makes no sense to me.

When I use -g SPI_buswidth:4 then I get the extra header, when I use -g SPI_buswidth:1 I do not get the extra header, all other settings remaining the same in bitgen.

What is going on?

[bhayes47 · Accepted solution]

I just tried setting the SPI buswidth option in 13.2 and can confirm your findings.  With the width set to 2 or 4, it incorrectly inserts the multiboot header.  With the width at 1, which is what I've been using, it works correctly.

I would suggest you file a webcase, this appears to be a bug.