cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
gsauvage
Visitor
Visitor
685 Views
Registered: ‎07-16-2020

Bin file size significantly changes between successive runs

Hi,

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?

Thanks,

Guy

Tags (1)
0 Kudos
9 Replies
lowearthorbit
Scholar
Scholar
671 Views
Registered: ‎09-17-2018

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.

lowearthorbit

0 Kudos
gsauvage
Visitor
Visitor
641 Views
Registered: ‎07-16-2020

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?

0 Kudos
lowearthorbit
Scholar
Scholar
631 Views
Registered: ‎09-17-2018

Well,

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?

lowearthorbit

0 Kudos
gsauvage
Visitor
Visitor
626 Views
Registered: ‎07-16-2020

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.

0 Kudos
594 Views
Registered: ‎01-22-2015

@gsauvage 

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.

bin_file.jpg

 

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.

Mark

0 Kudos
gsauvage
Visitor
Visitor
552 Views
Registered: ‎07-16-2020

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:

  • a prefix made up of various commands to configure the FPGA and set-up the data transfer;
  • the 49030 cframes containing the data required by the XQRKU060;
  • a suffix made up of various commands to conclude the FPGA configuration

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?

Thanks,

Guy

 
 

  

Bin file prefix.png
0 Kudos
520 Views
Registered: ‎01-22-2015

I am unable to answer your questions about bitstream composition.

However, fixing "configuration upsets" seems similar to the purpose of Xilinx's Soft Error Mitigation (SEM) IP (see document PG036). 

I believe that @lowearthorbit  is very familiar with the SEM IP - if you are interested.

0 Kudos
lowearthorbit
Scholar
Scholar
509 Views
Registered: ‎09-17-2018

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.

lowearthorbit

0 Kudos
gsauvage
Visitor
Visitor
498 Views
Registered: ‎07-16-2020

Thanks for your advice. I will contact my FAE for the file size.

 

0 Kudos