1. Home
  2. Field-Programmable Gate Arrays
  3. on FRAME_ECC_VIRTEX4 functionality

on FRAME_ECC_VIRTEX4 functionality

Hi all, I have two questions:

1.- On the meaning of the syndrome word: Virtex-4 Libraries Guide for HDL Designs says that syndrome(11) = 0 means there is a one bit error and that syndrome(10 downto 0) indicates the error position (pag 94). However, Virtex 4 FPGA Configuration User Guide (pag 75, latest version, april 2008) says that syndrome(11) = 0 means there is more than one bit error and that syndrome(10 downto 0) is meaningless. Does anybody knows which one is correct? 2.- If my design uses LUTRAMs, I am suppose to set the GLUTMASK_B bit to 0 for active readback. By doing this I'll readback all 0's from the bits corresponding to LUTRAMs and I'll avoid any kind of corruption while performing an active readback. This means that whatever I'll be reading back will not be the original bitstream data since the LUTRAM bits are masked. Thus FRAME_ECC_VIRTEX4 will signal an error with every frame readback. Am I right in this assumption? Does anybody have had an experience with this? Any comment would be appreciated, Thanks, Alonzo.
Reply to
rha_x
Loading thread data ...

From pages 75, and 76:

formatting link

S[11] = 0, S[10:0] = 0: no error.

S[11] = 1, S[10:0] ? 0: single bit (SED) error; S[10:0] denotes location of bit to patch (indirectly).

S[11] = 1, S[10:0] = 0: single-bit error; syndrome bit is in error.

S[11] = 0, S[10:0] ? 0: double-bit error, not correctable.

So, if the MSB (bit 11) equals 1, there is a correctable error (and the bits 10:0 are the indirect location of the bit to flip, or if bits

10:0=0, the error bit itself is in error [ bits 10:0 defined as from 704 = first bit of frame, to 2047 the last bit in the frame]).

If the MSB is 0, and the location bits 10:0 are non-zero, then there is a multiple bit hit (uncorrectable).

So, for example:

100000000001 -> 640 (bit 0 of syndrome in error) 100000000010 -> 641 100000000100 -> 642 100000001000 -> 643 100000010000 -> 644 100000100000 -> 645 100001000000 -> 646 100010000000 -> 647 100100000000 -> 648 101000000000 -> 649 110000000000 -> 650 100000000000 -> 651 (bit 11 of syndrome in error)

all indicate an error in a syndrome bit (there are 11 syndrome bits, which you can correct, too).

Austin

rha snipped-for-privacy@yahoo.com wrote:

Reply to
austin

If a LUTRAM is used for SRL 16/(32) or for LUTRAM (LUTROM), then the GLUT_Mask bit is set for that LUT, and FRAME_ECC will not include those LUT contents (masked for readback). All other bits in that frame are part of the FRAME_ECC, however.

And, yes, the bitstream you read back is not the bitstream you put in.

Austin

Reply to
austin

And,

I did note inconsistency with the software manual (and reported it to tech pubs).

Since I am a "hardware guru" and I know that we write the manuals (first), I have to think the software guide is incorrect.

Perhaps that isn't fair, I also know that a '1' in bit 11 indicates an error when the syndrome is non-zero with the location of the bit in error offset by 704.

Austin

Reply to
austin

Hi Austin, Interesting. I tough FRAME_ECC takes in consideration the ECC bits created during the bitstream generation. If the LUTRAM bits are not taken into account, wouldn't the ECC calculation by FRAME_ECC fail (signal an error). Anyways, I am testing the idea just now. Let's see what happens. I'll post my results.

Thank you for your answer. Alonzo.

Reply to
alonzo

From the expert:

"To simplify and clarify:

1) S[11] = 0, S[10:0] = 0 | No error 2) S[11] = 1, S[10:0] = X | Single bit error, S[10:0] is the correction ptr. 3) S[11] = 0, S[10:0] != 0 | Double bit error, uncorrectable

1 & 3 are obviously very simple because there is no decoding to be done.

2 requires syndrome decoding, and there are a lot of exceptional cases - the documentation of which can be a bit confusing and lead to errors, as we see in the V5 config UG."

True for both V4 and V5,

Austin

Reply to
austin

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.