突发纠错的ECC（纠错码）如何工作（磁盘驱动器样式）？
这可能是诅咒或祝福，但我的大脑常常试图在梦中解决技术问题。有时确实如此。就像昨晚一样，我的大脑要求了解如何设计ECC算法（软件程序，但最终可能是FPGA电路），以实现适合磁盘驱动器的ECC。适用于这些设备的ECC类型似乎是＆＃34;突发错误检测＆＃34;。
据我所知，磁盘驱动器出错的原因是磁盘表面的缺陷（规格或划痕）。当磁头读取数据位并经过一个狭窄的划痕时，电路会在＆＃34;突发＆＃34;上生成正确和错误位值的随机混合。可能是1到64位。因此，据我所知，磁盘驱动器ECC的目标是能够纠正任何一个随机错误突发中的所有错误位。
顺便说一句，我不自然地在数学和＃34;中思考，所以请不要指我数学论文！我已经花了几个小时试图阅读维基百科关于里德 - 所罗门和其他各种计划，但这些文章中的数学对我来说是完全不可理解的（除非我花了几个星期研究它们......如果我很幸运）。此外，从文本中我不认为任何这些方案适用于磁盘驱动器（但可能是CD / DVD）。无论如何，我将描述我的大脑在睡梦中想到的是什么，并要求任何人解释这种ECC实际应该如何完成，以及传统方法有多好。我确信我的计划效率必须低于知道他们正在做什么的人所做的技术，甚至可能在他们清醒时设计！在我醒来之前，我试图弄清楚如何处理每个轨道的两次连发，但是醒来时失败了。所以我也问如何实现这一点。
我的心理图像是一个4096字节的扇区，我精神上分成512个块，每个64位（因为我常常用64位块思考，因为我猜测64为了实际目的，-bit突发错误就足够了。在我的应用程序中，每个数据流肯定是4096到8192字节。
我的方法是从4096字节的数据中计算10个64位ECC代码。因此ECC我的方案将在4096字节数据的最后一个之后写入10个64位代码== 80个字节，这只是2％的开销。我将这十个64位ECC代码称为＆＃34; code0＆＃34; to＆＃34; code9＆＃34;，每个扇区在处理完每个扇区之前都清零。每个64位（8字节）数据序列我都会称之为＆＃34; chunk＆＃34;因为没有任何更好的术语。
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的流中，错误突发发生了什么？
现在我试着解释为什么我的梦想（？噩梦？）认为这10个64位ECC代码可以在4KB == 32Kb流中的任何地方检测到高达64位长的任何一个错误位突发
让我们慢慢开始并考虑一个简单的例子。让我们假设当磁盘驱动器回读一个扇区时，512＆＃34;块中的一个位＃0;错了==倒置。
ECC code9能告诉我们什么吗？好吧，code9是扇区中每个64位块的XOR。因此，code9的第0位是写入扇区的每64位数据块的位＃0的奇偶校验。因此，当我们读回扇区时，任何一个64位数据块的＃0位错误都会产生一个错误，我们只能用64位代码9来检测（不需要代码8，代码7 ...代码0） 。如果任何64位数据块的第0位不正确，则从磁盘读回的ECC中的第9位＃0将与我们从回读数据计算的第9位第0位不一致！
尼斯！我们检测到一些64位块的第0位错误，只有code9。但是，我们不知道511个数据块中的哪一个在其＃0位中包含错误。
这是其他八个ECC代码的用途（以某种方式说）。
其他八个ECC代码让我们缩小了＃34;这个错误在哪里。
所以我们问自己，代码能告诉我们什么？嗯，那是非常明显的！ code8仅考虑块256-511（扇区的后半部分），因此如果位＃0错误位于块000-255（扇区的前半部分）中的任何位置，则code8将不会检测到任何错误。可是等等！如果我们知道位＃0中的错误不在块256-511中，那么它必须位于块000-255（扇区的前半部分）中的某个位置。所以现在我们知道错误是在块000-255中的某个地方，而不是在块256-511中。优良！
现在我们问问自己，代码可以告诉我们什么？好吧，在我们感兴趣的区域（块000-255）中，code7仅检查块128-255。因此，如果我们从磁盘读回的code7 ECC的第0位与我们从读取数据计算的code7 ECC不同，我们知道位＃0错误在块128-255中的某处。甜！我们再次将错误的可能位置切换到范围的一半。
现在代码可以告诉我们什么？这是如何工作的。和以前一样，code6只检测我们知道错误所在区域的一半的错误。在区域中我们将错误缩小到（块128-255），code6只检查后半部分（块192-255）。因此，当我们在code6的第0位找不到错误时，我们知道位＃0错误不在块192-255中，因此必须在块128-191中的某处。
当我们在code5的第0位发现错误时，我们知道错误必须在块160-191中。
当我们在code4的第0位发现错误时，我们知道错误必须在块176-191中。
当我们在code3的第0位找到错误时，我们知道错误必须在块184-191中。
当我们在code2的第0位找到NO错误时，我们知道错误必须在块184-187中。
当我们在code1的第0位找到NO错误时，我们知道错误必须在块184-185中。
当我们在code0的第0位发现错误时，我们知道错误必须在块185中。
!!!!!完成!!!!!
我们现在确切地知道错误在4096字节扇区中的位置---在64位块＃185的第0位。
并且块185 == 0x0B9 == 0 1011 1001
嗯。很有意思！错误的块＃中的每个零位都是代码＃，其中没有发现错误，错误的块＃中的每一位都是代码＃，其中我们做了发现错误。这意味着，我们在检查代码块的过程中自动获取包含错误的块＃。当回读ECC中的位与我们从读取数据计算的ECC中的相同位匹配时，我们生成0，否则我们生成1（回读-ECU XOR计算-ECC）。这有多简单？ !!!
稍加思考，我们发现数据块和ECC块中的每个位＃都是独立。换句话说，ECC组块中的位＃0正在检查每个64位数据块的位＃0，而ECC组块中的位＃1正在检查每个64位数据块的位＃1，依此类推。 ECC值和数据块中的相邻位完全相互独立。没有比彼此更接近64位的位以任何方式相互作用。该方案将扇区视为64个独立扇区，每个扇区仅为1/64。
啊哈！这就是为什么这种技术可以检测和纠正高达64位长的任何错误位的原因 - 因为每个位完全独立（在ECC块中）来自距离64位以外的任何位。
那就是它。至少在我的梦境中，这解释了它是如何工作的。
上述内容并未解释如下（我的问题）：
＃1：这是在磁盘驱动器等上执行突发ECC的方式吗？
＃2：如果这种技术不常规，这种技术是新的吗？
＃3：这种技术对于软件而言比传统技术更容易吗？
＃4：常规例程是否有更多或更少的开销（4K数据包中的64位突发为1.8％）？
＃5：如何扩展以纠正两次爆发？
PS：我的ECC应用程序与磁盘驱动器无关，但具有类似的特性和要求。至少在最初，我的应用程序将在软件中完成所有工作：在软件中计算ECC，附加到数据流（数据包），发送数据流（数据包），接收数据流（数据包），以及执行上述过程检测并修复数据流（数据包）中的任何错误。我想有一天它也可能变成FPGA中的电路，但是......今天不行。