How can I use the SEM IP error report to look up essential bit error locations using the EBD (Essential Bit Data) file?
An EBD file is an ASCII text file that has an informational header, followed by a number of lines, where each line has 32 characters that are either zero (0) or one (1).
Each line represents the classification of 32-bits, or one word of CRAM. Zero means non-essential and one means essential.
The Least Significant Bit (LSB) of a word, which is sequentially considered its first bit, is on the far right.
In the 16nm UltraScale+ family, each CRAM frame is 93 words. As each line in the EBD represents a word, You can visualize it by counting off groups of 93 lines in the EBD file.
Each group of 93 lines of data in the EBD file holds the essential bits data for a configuration frame. It is ordered by incrementing Linear Frame Address, or LA.
The initial group of 118 lines consist of the 25 dummy words and one dummy frame. The next group of 93 lines is for LA = 0, followed by the next group of 93 lines for LA = 1 and so on.
Let:
Where is the classification for the CRAM bit located at LA, WD, BT?
The allowed range for LA is from zero to the maximum frame of the device.
If in the EBD, you call the first data line (after the informational EBD header) "line zero" and the first character on each line "character zero", then:
Seek line = (93 * (LA + 1)) + WD +25
(+25: For UltraScale+ devices, there are 25 dummy words on top of a dummy frame (93 words). So there are a total of 118 dummy words at the beginning of the .ebd file.)
Seek character in line = (31 -BT)
It is an index into an array. Based on the file's ASCII text representation of the data, the file is very easy for a person to read.
I expressed the "seek line" and "seek character in line" in two steps instead of a single computation to seek a character in the file because potential differences in size between DOS and UNIX line end markers would complicate it.
The downside to ASCII text representation, where one ASCII character represent a one-bit binary value, is that the file is eight times larger on disk than if it were stored in a binary data file.
Xilinx provides a Tcl script with the SEM IP core which is an example of how to transform data represented in ASCII text into binary.
This is what we do when preparing to store the Essential Bits Data in an SPI flash. If the representation is changed, the equation for the index into the file/array must also be adjusted to match.
Below is part of a 1-bit SEU detection and correction report from a SEM UltraScale+ device (see (PG187) for full format):
O>
RI 00
SC 04
ECC
TS 0000C8BC
PA 0004B602
LA 00003302
COR
WD 54 BT 0B
END
FC 00
SC 08
CLA
WD 54 BT 0B LV 01
END
FC 40
SC 02
O>
The CRAM location is LA=00003302, WD=54, BT=0 (all values are in Hexadecimal format).
Below are the first twenty-five or so lines of an Essential Bits Data file, or EBD file, for a ZU9EG device.
EBD files for any device in the 16nm UltraScale+ family looks similar, they only differ in the file length.
Xilinx ASCII Bitstream
Created by Bitstream 2017.3 SW Build 2005028 on Wed Sep 20 16:34:48 MDT 2017
Design name: my_ip_example_design;UserID=0XFFFFFFFF;COMPRESS=TRUE;Version=2017.3
Architecture: zynquplus
Part: xczu9eg-ffvb1156-2-i
Type: essential
Date: Thu Sep 21 10:23:12 2017
Bits: 143015456
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
{and so on}
AR# 70684 | |
---|---|
日期 | 03/26/2021 |
状态 | Active |
Type | 综合文章 |
器件 | |
IP |