验证到每一种情况，不知天高地厚的人
以FEC(255，223)为例做介绍。
FEC(255，223)可以在255bytes中纠正任意(1~16）bytes的错误。
（（1～16）bytes可以是1～16任意选一个数，下面（1～8）意思相同）
每个bytes可以是（1～8）bits的错误。
有人认为他有能力把每一种情况都验证到，我真不知道是他的数学能力不行还是对自己太有自信了，居然能把每一种情况都验证到。
大家有兴趣可以计算一下这是一个什么样的数据。（提示一下，我的服务器上跑一种情况要0.074s, 你要觉得你们公司的服务器比这快很多的话，你就适当的修改一下这个参数）
“FEC(255，223)可以在255bytes中纠正任意(1~16）bytes的错误”
这句话是准确的吗?感觉有点夸张啊。会不会使下面2种情况之一?
1.任意的16bytes
2.任意的连续的（1~16）bytes
任意的，连续，不连续都可以。只要错误在16bytes以内就可以。
这种方法，用穷尽形式验证小模块，理论上可以全部覆盖到。应该是你眼观只在动态仿真上，少了数学理论的验证知识。不要用自己的眼界去决定别人所做的可能性。还是要虚心请教别人。
还是一句话：IC没啥前途，早改行才是出路。
你说的没有错。
我这边只讨论一下动态的验证，那个人没有那么牛，只是太自负了而已。
因为我们这边没有人做过形式验证，所以我这边有一个疑问请您帮忙解答一下。
前仿真，（假如时间限制不考虑的话）我可以保证每一种都能验到，并确定其算法是对的。
如果前仿真不做，只用穷尽法形式验证，是可以的遍历每一种情况，时间肯定会比动态仿真用的少，但他怎么保证其每一种都是正确的呢?
https://baike.baidu.com/item/形式验证/10075710?fr=aladdin
现实的形式验证本身就是“不完整”的验证，所以自然没办法保证每一种情况都是对的。
首先，假设验证的所有功能点是一个圆：
1.正常的验证就是在这个圆里面一个点一个点的验，虽然慢但是只要时间够，迟早可以验完这个完整的圆
2.形式验证就是借助各种方法，将这个点变成一个矩形（这个矩形必须被圆包含）。虽然验起来快多了，但是不管矩形的宽在小，不管你用多少个矩形，你都填不满这个圆。
我这边做一个最后结论吧。
以RS(255,223)为例。 FEC有能力纠错任意16bytes的错误。
其中一种组合（即每次都错16bytes,且每个byte的每个bit都错）结果有C(255,16)=9448829626895919257468625 ≈9.4e+24，
如果每种错误都要遍历一遍的话，那结果会远远大于9.4e+24个。
FEC RX 验证环境跑100个codeword 用时7.4s（关掉了dump fsdb , 打印信息也关掉了）。
粗略估计，
一天能跑1167568(116万)个codeword.
一个月能跑35027027(3502万)个codeword.
一年能跑420324324≈4.2e+8(4.2亿)个codeword.
全部跑完需要的时间是 9.4e+24 / 4.2e+8 ≈2.2e+16年
所以要遍历一遍需要的时间是非常惊人的，不知到用咱们国家的神威太湖之光要多久才能完成。
之前有楼上有位大神说形式验证可以做到，因为我没有涉及到形式验证，所以也没有办法告诉大家怎么去完成。有兴趣的人可以给大家科普一下。
我这边做一个动态仿真的总结。
以RS(255,223)为例。 FEC有能力纠错任意16bytes的错误。
其中一种组合（就是每次都错16bytes,每个byte的每个bit都错）的结果有C(255,16)=9448829626895919257468625 ≈9.4e+24种，
如果每种错误都要跑到的话，那结果会远远大于9.4e+24个codeword。
FEC RX 验证环境跑100个codeword 用时7.4s（关掉了dump fsdb , 打印信息也关掉了）。
粗略估计，
一天能跑1167568(116万)个codeword.
一个月能跑35027027(3502万)个codeword.
一年能跑420324324≈4.2e+8(4.2亿)个codeword.
全部跑完需要的时间是 9.4e+24 / 4.2e+8 ≈2.2e+16年
所以要遍历一遍需要的时间是非常惊人的，不知道用神威太湖之光要跑多久。
之前楼上有位大神说用形式验证可以做到，因为我没有涉及过形式验证，所以无法就此种方法做个总结。
有人有兴趣的话可以给大家科普一下。
我这边做一个动态仿真的总结。
以RS(255,223)为例。 FEC有能力纠错任意16bytes的错误。
其中一种组合（就是每次都错16bytes,每个byte的每个bit都错）的结果有C(255,16)=9448829626895919257468625 ≈9.4e+24种，
如果每种错误都要跑到的话，那结果会远远大于9.4e+24个codeword。
FEC RX 验证环境跑100个codeword 用时7.4s（关掉了dump fsdb , 打印信息也关掉了）。
粗略估计，
一天能跑1167568(116万)个codeword.
一个月能跑35027027(3502万)个codeword.
一年能跑420324324≈4.2e+8(4.2亿)个codeword.
全部跑完需要的时间是 9.4e+24 / 4.2e+8 ≈2.2e+16年
所以要遍历一遍需要的时间是非常惊人的，不知道用神威太湖之光要跑多久。
之前楼上有位大神说用形式验证可以做到，因为我没有涉及过形式验证，所以无法就此种方法做个总结。
有人有兴趣的话可以给大家科普一下。
这是功能验证吗?如果是，不需要用穷举法，除非你怀疑设计人员故意在某个特殊的case设个陷阱。
解法是用随机策略，另外关注下边界情况就可以了。例如你说的“每次都错16bytes,每个byte的每个bit都错”，可以先把情况分为错误是连续和不连续，然后对于错误是连续的又有几种情况：
1.开始的1~16bytes出错
2.随机N~N+15bytes出错（随机一定次数）
3.最后的250~255bytes出错
通过这样不断的约束，就可以很快验证完这个模块而且还能保证很高的完整性。
如果不仅仅是功能验证，比如说你怀疑综合后众多的nand gate中的某一个gate有问题，这种时候可以靠功能仿真+形式仿真（不仅仅是时序验证）来验证。总之，穷举法只适合简单的设计，少量的输出输入，不然别说FEC，就算一个高位的乘法器，几亿的电脑+几个世纪都跑不完。
哈哈，这个问题有意思，想知道小编说能遍历的那个人用的是什么方法呢。
还有小编你计算的是一个进程跑的用例数，可以多进程同时跑。
想知道小编说能遍历的那个人用的是什么方法呢?>>> 他只是嘴上随便说说，然后就没有然后了。
还有小编你计算的是一个进程跑的用 ...
>>>这个测试我只有了一个服务器单线程， #12的高手说的方法以及答案我个人认为是正解。
不是很了解这个帖子的业务，记得多年前看过一个文章说遍历验证某些时候可以减少复杂度，尽可能的做到balance，不知道算法的同学有没有什么好建议。
哈哈，吹牛就算了，不要当真。边界，等价与随机是常规测试方法，屡试不爽，能发现99%的问题。但问题是那隐藏的1%最难被发现，要根据测试结果随时调整策略。
设计人员不会故意埋雷的，因为他自己都不知道会错，在验证前一般都很自信。一般我会在设计出错比较多的地方加强验证，哪怕就行局部遍历。
做这种操作的意义是什么，如果没什么意义也就没人去研究穷举了。
比如说我们去验证32位加法器是不是对的本身就没什么意义，所以给个做的理由嘛。
我们做验证一般都是功能性验证，即使是做也会加32位加法拆成其他的进行迭代验证。
用形式验证来证明一个FEC RTL模块正确实现了算法?好奇现在哪家的形式验证工具的性能有这么强悍。只听说证明浮点乘除法，FFT这种规模的