07-16-2020 07:23 AM
With XQRKU060 device we noticed that the .bin file size varies significantly between successive place & routes, even with minor design changes in between. The header size, containing registers accesses, is changing and the data starts at different positions. Is it normal? We would have expected a fixed sequence of registers accesses in the header for a given device according to UG570. What is the maximum possible header length?
07-16-2020 07:35 AM
Check your warnings and info messages,
Look for trimmed and removed logic. A 'small change' may not be small at all. You think you have not done anything major, but your opinion is not what matters: it is the tool results. You have to look at what the tool tells you it did.
07-16-2020 11:22 AM
We get two main sections in the .bin file: the header section including registers and the data section including configuration data frames.
Obviously the overall .bin file size changes for each place & route because the data frames are different, but why would the .bin file header section size would change? The header size should be fixed for a given device no?
07-16-2020 12:19 PM
Are you using bitstream compression? Tandem bitstream? I agree that for the simple case, I would not expect header differences. Again, have you read through the messages?
07-16-2020 12:26 PM
No I have a single bistream (no tandem) and no compression. I could double check all synthesis notes and warnings, but I doubt it would explain why the header changes.
07-16-2020 04:34 PM
I suspect you are interested in the bitstream header only because you want to get rid of it. Yes?
If so, then it is the .bit file (and not the .bin file) that has a header. Vivado will always give you the .bit file, but a bitstream setting (as shown below) is required to also get the .bin file.
On page 20 of UG580 (v1.12) it says:
A complete bitstream for each device has a fixed length for a given set of configuration options, independent of the logic used. However, bitstream options such as compression (BITSTREAM.GENERAL.COMPRESS) can change the required bitstream length.
So, according to Table 1-4, your KU060 bitstream (ie. .bin file) should always have a length of 192,999,264 bits.
07-17-2020 05:18 AM
I should not have used the word "header". It's confusing in this case because it's the .bit that has a header, not the .bin file. We want to use the .bin to get rid of the header and just get the data to load in the Xilinx. However the .bin file has 3 sections:
The prefix looks like in the attached picture. We thought the prefix was always fixed in terms of size, but it's not the case and we wonder why? We need to load that prefix only once in the Xilinx and then we could keep reloading frames with a configuration scrubber in case of configuration upsets (it's a space application). Do you know why the prefix changes between successive place & routes?
07-17-2020 02:00 PM
07-17-2020 02:21 PM
My middle name (SEU),
The SEM IP has both proton and heavy ion beam test results (cross section), so it is a viable solution to configuration bit upsets for most missions. I would contact your dedicated FAE to explain the difference in the files. Does not make any sense to me. In any event if not using SEM IP, I would also use INIT_b (RBCRC fails and drops INIT_b when you set the bitgen to notify upon error) to trigger an external 'scrub' rather than waste power scrubbing when not needed.