cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Visitor
Visitor
10,785 Views
Registered: ‎05-18-2012

.ebd file format for essential bits

Hi,

 

I have a question about the .ebd file generated by bitgen. The XAPP538 shows how to generate an .ebd file which shows which configuration bit are essential for the functioning of the desing. The ebd file is in ASCII format. However the generated file contains only fraction of bits containded in the full bitstream file.  What is the mapping betweent the .ebd file and .rbt (containing ful bitstream)????

 

I am using 14.1 versio of the tools.

I attached a zip file with a simple project wich shows that the full bitstream file (.rbt) is about 45MB and the .edb file is only about 33MB

 

Thank you!

0 Kudos
8 Replies
Highlighted
Scholar
Scholar
10,783 Views
Registered: ‎02-27-2008

s,

 

The ebd file is used by the free SEU Monitor IP core, and is not intended for any other use whatsoever.


Bitstream details, and the details of this file are proprietary.

 

An essential bit is defined as a bit, that if changed in value, it affects the way the FPGA device is programmed to behave.


There is a 1 in 3 chance that the bit will affect the design in some way, causing a functional failure.


The reason why the bit may not cause a failure has to do with the fact that some bits might be programmed to perform a function that is never used by your design.  A good example is reset code, quality of service code, test code, etc. that is either rarely, or never executed.  States in state machines that are never exercised, as well as features never used, all comprise the fact that 1/3 of the essential bits are actually critical (cause a functional failure).


The essential bit file is where to start looking:  no need to look for any other bits, as no other bits will cause a functional failure.


Most important is that the bits deemed non-essential will not cause a functional failure.  We have tested this on V5, and V6, and 7 series to less than 100 failures per million bits, per billion hours.  In fact, this is now below 10 FIT/M in the software, with no known failing (mismarked) bits.  We have cusrtomers who do not believe our testing is good enough, and have tested 100% of their bits for functional failures.  Occasionally we had bits reported that we did not classify correctly.  It has been some number of months now with no new "missed bits."


This is incredibly tough to do (test), as the quality of the results depends on the test bench they use (can they catch all bad behavior?).  Thankfully we have many safety critical systems customers who must do exhaustive testing.

 

Other than the documentation for the SEU Monitor IP, no other details are provided.  Any questions about the IP core, and its function, will be answered, and answered in public (like this, or email directly to me).  But details of what and how the bitstream works is still proprietary.

 

The latest SEU data is also out (May 8, 2012) with 7 series published in ug116.pdf on our website.


The 7 series is now the most soft error reliable family of FPGA devices sold, at 71 FIT/Mb for the raw, unmitigated upset rate (lowest upset rate since we started testing at 250 nm in 1998).

 

The fact that no one else publishes this data underscores just how bad everyone actually is (and they should be ashamed of themselves for not being honest with their customers).

 

 

Austin Lesea
Principal Engineer
Xilinx San Jose
0 Kudos
Highlighted
Visitor
Visitor
10,780 Views
Registered: ‎05-18-2012

Hi Austin,

 

Thank you for the information.  However, I am dissapointed with the stance that Xilinx is talking on this topic.  I am not asking what is the function of each bit, or any other information which would reveal any real information as to the function of the bitstream.  I only want to know which bits are essential so I can do fault injection without using the SEU Monitor IP core.

 

Greg

0 Kudos
Highlighted
Visitor
Visitor
10,772 Views
Registered: ‎05-18-2012

Hi Austin,

 

I have one more question.  In one of your other posts on this subject you said "Essential bits is a feature of bitgen.  It delivers a file of the bits, that if changed, would change the function of the FPGA device's hardware."  How are the end users supposed to know which bits are essential if the ebd file format is proprietary?

 

Greg

0 Kudos
Highlighted
Scholar
Scholar
10,768 Views
Registered: ‎02-27-2008

Greg,

 

I belive there is a misunderstanding here:  every bit which is a 1 in the essential bit file, is essential.


Every bit marked with a 0, is non-essential (if it flipped, it would NOT cause any problem at all).

 

What else is there to know?  Essential bits (1) are bits that, if they change, change the function of the FPGA device hardware.  Bits marked 0, may change, and will NOT cause any functional change to the hardware.

 

Crtiical bits are only known to the customer:  they depend on your RTL code.  Even though essential, the bit may not be used in time (on a particular clock), nor in space (code that is not being exercised).

 

 

Austin Lesea
Principal Engineer
Xilinx San Jose
0 Kudos
Highlighted
Visitor
Visitor
10,761 Views
Registered: ‎05-18-2012

Austin,

 

I understand the fact that "every bit which is a 1 in the essential bit file, is essential. Every bit marked with a 0, is non-essential (if it flipped, it would NOT cause any problem at all)." However the essentail bit file is significantly shorter than the full bitstream file. For example for XC6VLX240T, the essential bit file contains 57,700,544 bits while full bitstream contains  73,8408,96 bits. How do I find out which bits are ommited from the essential bit file?  I dont need to know what individal bit does, just how to find out if particular bit in bitstream is essential.

 

Greg

0 Kudos
Highlighted
Scholar
Scholar
10,759 Views
Registered: ‎02-27-2008

Greg,


The only frames that are essential are frames which contain configuration memory.  Thus, there are no BRAM contents in the file.

 

LUTRAM and SRL data are by definition, not essential (they are transient data).  These bits are marked as 0, non-essential (but they are there as the rest of the frame may contain essential bits).

 

That is why the file is shorter than the entire bitstream (no BRAM contents frames).

 

 

Austin Lesea
Principal Engineer
Xilinx San Jose
0 Kudos
Highlighted
Visitor
Visitor
10,751 Views
Registered: ‎05-18-2012

Austin,

Thank you for this information.  I suspected something like this might be the case.  I applied this info to 6vlx240tff1156 bitstream and I came up with some unusual results.

The full bitstream for 6vlx240tff1156 contains: 21552 CLB_I/O_CLK frames, 6912 BRAM content frames, 24 pad frames, total of 28488 frames. 

Then total number of bits in the CLB_I/O_CLK frames  is 21552*81*32 = 55862784 ~ 55.8 milion bits.

The .ebd file contains 57700512 ~ 57.7 milion bits.

The difference between the two is 1837728 bits or exactly 709 frames where the ebd file contains more data than is should.



I repeated this analysis with with 6vlx130tff1156:

The full bitstream contains: 12360 CLB_I/O_CLK frames, 4480 BRAM content frames, 24 pad frames, total of 16864 frames. 
Then total number of bits in the CLB_I/O_CLK frames  is 12360*81*32 = 32037120 ~ 32.0 milion bits.

The .ebd file contains 33128352 ~= 33.1 milion bits

The difference between the two is 1091232 bits or exactly 421 frames.



Could you provide some insights as to why the ebd file is longer than expected?



Thank you,



Greg

 

0 Kudos
Highlighted
Scholar
Scholar
10,747 Views
Registered: ‎02-27-2008

Greg,

 

No.  Like I said, it is for use with the IP provided.  How it works (the gruesome details), is not something we discuss.

 

If you have a specific case, of a bit that is critical, but is not marked critical in the file, then I am willing to analyze the impact.bin readback files from you, so we may correct the mis-classification.

 

 

Austin Lesea
Principal Engineer
Xilinx San Jose
0 Kudos