Algorithm 突发错误纠正的ECC是如何工作的？

突发错误纠正的ECC（错误纠正代码）如何工作（磁盘驱动器类型）

这不是诅咒就是祝福，但我的大脑经常试图解决梦中的技术问题。有时的确如此。就像昨晚一样，我的大脑需要了解如何设计ECC算法（软件程序，但最终可能是FPGA电路）来实现适合于磁盘驱动器的ECC。适合这些设备的ECC类型似乎是“突发错误检测”

据我所知，磁盘驱动器出现错误的原因是磁盘表面的缺陷（规格或划痕）。当磁头读取数据位并通过一个狭窄的划痕时，电路会在1到64位的“突发”上生成正确和错误位值的随机混合。因此，据我所知，磁盘驱动器ECC的目标是能够纠正任意一个随机突发错误中的所有错误位

顺便说一句，我不会自然而然地“用数学思考”，所以请不要让我看数学试卷！我已经花了几个小时阅读维基百科上关于里德·所罗门和其他各种计划的文章，但这些文章中的数学对我来说是完全不可理解的（除非我花几个星期研究它们……如果我幸运的话）。此外，从本文中，我不认为这些方案适用于磁盘驱动器（但可能是CD/DVD）

无论如何，我会描述我的大脑在睡眠中梦到了什么，并请任何人解释这种ECC实际上应该如何进行，以及传统方法有多好。我敢肯定，我的计划的效率肯定比那些知道他们在做什么的人所做的技术要低，甚至可能是在他们醒着的时候设计的！在我醒来之前，我试图弄清楚如何处理每条赛道两次爆发，但醒来时失败了。所以我也问如何实现这一点

---

我的脑海中的图像是一个4096字节的扇区，我在脑海中把它分成512个64位的块（因为我习惯用64位的块来思考，而且我猜64位的错误突发对于实际用途来说已经足够了。在我的应用程序中，每个数据流肯定是4096到8192字节）

我的方法是从4096字节的数据中计算出10个64位ECC代码。因此，我的方案在4096字节数据的最后一个字节之后写入的ECC代码将是10个64位代码==80字节，这刚好是2%的开销。我将这10个64位ECC代码称为“code0”到“code9”，在处理每个扇区之前，每个扇区都被清除为零。由于没有更好的术语，我将每64位（8字节）的数据序列称为“块”

code9 = XOR chunks 000 to 511 == 000 to 1FF : every chunk
code8 = XOR chunks 256 to 511 == 100 to 1FF : every chunk # with bit #8 == 1
code7 = XOR chunks 128 to 255 == 080 to 0FF : every chunk # with bit #7 == 1
        and chunks 384 to 511 == 180 to 1FF
code6 = XOR chunks 064 to 127 == 040 to 07F : every chunk # with bit #6 == 1
        and chunks 192 to 255 == 0C0 to 0FF
        and chunks 320 to 384 == 140 to 17F
        and chunks 448 to 511 == 1C0 to 1FF
code5 = XOR chunks 032 to 063 == 020 to 03F : every chunk # with bit #5 == 1
        and chunks 096 to 127 == 060 to 07F
        and chunks 160 to 191 == 0A0 to 0BF
        and chunks 224 to 255 == 0E0 to 0FF
        and chunks 288 to 319 == 120 to 13F
        and chunks 352 to 383 == 160 to 17F
        and chunks 416 to 447 == 1A0 to 1BF
        and chunks 480 to 511 == 1E0 to 1FF
code4 = XOR chunks 016 to 031 == 010 to 01F : every chunk # with bit #4 == 1
        and chunks 048 to 063 == 030 to 04F
        and chunks 080 to 095 == 050 to 07F
        and so forth
code3 = XOR chunks 008 to 015 == 008 to 00F : every chunk # with bit #3 == 1
        and chunks 024 to 031 == 018 to 01F
        and chunks 040 to 047 == 028 to 02F
        and so forth
code2 = XOR chunks 004 to 007 == 004 to 007 : every chunk # with bit #2 == 1
        and chunks 012 to 015 == 00C to 00F
        and chunks 020 to 023 == 014 to 017
        and so forth
code1 = XOR chunks 002 to 003 == 002 to 003 : every chunk # with bit #1 == 1
        and chunks 006 to 007 == 006 to 007
        and chunks 010 to 011 == 00A to 00B
        and so forth
code0 = XOR chunks 001 to 001 == 001 to 001 : every chunk # with bit #0 == 1
        and chunks 003 to 003 == 003 to 003
        and chunks 005 to 005 == 005 to 005
        and so forth

好的，我应该解释这种方法的目的。算法产生的ECC必须以某种方式编码以下信息：

#1：每个位的正确状态是什么（所有4KB==32Kb）

#2：在4KB==32Kb的流中，哪里发生了错误突发

现在，我将尝试解释为什么我的梦（？噩梦？）相信这十个64位ECC代码可以检测4KB==32Kb流中任意一个长度高达64位的错误位突发

让我们开始慢速并考虑一个简单的例子。假设磁盘驱动器读取扇区时，512个“块”中的一个比特“0”是错误的=反转。 ECC代码9告诉了我们什么吗？好的，代码9是扇区中每个64位数据块的异或。因此，代码9的位0是写入扇区的每个64位数据块的位0的奇偶校验。因此，当我们读回扇区时，任何一个64位数据块的位0中的错误将生成一个我们可以用64位bi检测到的错误仅t code9（不需要code8、code7…code0）。如果任何64位数据块的0位不正确，则从磁盘读回的ECC中code9的0位将与我们从读回数据计算的code9的0位不一致

很好！我们检测到一些只有代码9的64位数据块的0位有错误。但是，我们不知道511个数据块中的哪个数据块的0位有错误

这就是其他八个ECC代码的用途（从某种意义上说）

其他八个ECC代码允许我们“缩小”此错误的范围

所以我们问自己，code8能告诉我们什么？这是非常明显的！code8只考虑块256-511（扇区的后半部分），所以如果位#0错误在块000-255（扇区的前半部分）中的任何位置，code8将不会检测到任何错误。但是，等等！如果我们知道位#0中的错误不在块256-511中，那么它必须在块000-255（扇区的前半部分）中的某个位置。因此，现在我们知道错误在块000-255中的某个位置，而不是块256-511中。非常好

现在我们扪心自问，代码7能告诉我们什么？好吧，我们感兴趣的区域（块000-255），code7只检查块128-255。因此，如果我们从磁盘读取的code7 ECC的位0与我们从读取数据计算的code7 ECC不同，我们知道位0错误在块128-255中的某个位置。好极了！我们再次将错误的可能位置削减到范围的一半

现在，code6能告诉我们什么？这是如何工作的越来越明显。和以前一样，code6只在我们知道错误所在的区域的一半检测错误。在我们将错误缩小到（块128-255）的区域中，code6只检查下半部分（块192-255）.因此，当我们在代码6的位0中没有发现错误时，我们知道位0错误不在块192-255中，因此必须在块128-191中的某个地方

当我们在代码5的位#0中发现错误时，我们知道错误一定在160-191块中的某个地方

当我们在代码4的第0位发现错误时，我们知道错误一定在176-191块中的某个地方

当我们在代码3的第0位发现错误时，我们知道错误一定在184-191块中的某个地方

当我们在代码2的位0中没有发现错误时，我们知道错误一定在184-187块中的某个地方

当我们在代码的#0位中没有发现错误时