验证到每一种情况，不知天高地厚的人

zlyld

我这边做一个动态仿真的总结。
以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年
所以要遍历一遍需要的时间是非常惊人的，不知道用神威太湖之光要跑多久。

之前楼上有位大神说用形式验证可以做到，因为我没有涉及过形式验证，所以无法就此种方法做个总结。
有人有兴趣的话可以给大家科普一下。

jimbo1006

这是功能验证吗？如果是，不需要用穷举法，除非你怀疑设计人员故意在某个特殊的case设个陷阱。
解法是用随机策略，另外关注下边界情况就可以了。例如你说的“每次都错16bytes,每个byte的每个bit都错”，可以先把情况分为错误是连续和不连续，然后对于错误是连续的又有几种情况：
1.开始的1~16bytes出错
2.随机N~N+15bytes出错（随机一定次数）
3.最后的250~255bytes出错
通过这样不断的约束，就可以很快验证完这个模块而且还能保证很高的完整性。
如果不仅仅是功能验证，比如说你怀疑综合后众多的nand gate中的某一个gate有问题，这种时候可以靠功能仿真+形式仿真（不仅仅是时序验证）来验证。总之，穷举法只适合简单的设计，少量的输出输入，不然别说FEC，就算一个高位的乘法器，几亿的电脑+几个世纪都跑不完。

qyxu1979

哈哈，这个问题有意思，想知道楼主说能遍历的那个人用的是什么方法呢。
还有楼主你计算的是一个进程跑的用例数，可以多进程同时跑。

zlyld

哈哈，这个问题有意思，想知道楼主说能遍历的那个人用的是什么方法呢。
还有楼主你计算的是一个进程跑的用 ...
qyxu1979 发表于 2017-9-15 11:02

                               
登录/注册后可看大图

想知道楼主说能遍历的那个人用的是什么方法呢?>>> 他只是嘴上随便说说，然后就没有然后了。
   
还有楼主你计算的是一个进程跑的用 ...
>>>这个测试我只有了一个服务器单线程， #12的高手说的方法以及答案我个人认为是正解。

luyuan_0922

不是很了解这个帖子的业务，记得多年前看过一个文章说遍历验证某些时候可以减少复杂度，尽可能的做到balance，不知道算法的同学有没有什么好建议。

qyxu1979

哈哈，吹牛就算了，不要当真。边界，等价与随机是常规测试方法，屡试不爽，能发现99%的问题。但问题是那隐藏的1%最难被发现，要根据测试结果随时调整策略。

设计人员不会故意埋雷的，因为他自己都不知道会错，在验证前一般都很自信。一般我会在设计出错比较多的地方加强验证，哪怕就行局部遍历。

不想起的猪

做这种操作的意义是什么，如果没什么意义也就没人去研究穷举了。
比如说我们去验证32位加法器是不是对的本身就没什么意义，所以给个做的理由嘛。
我们做验证一般都是功能性验证，即使是做也会加32位加法拆成其他的进行迭代验证。

nativeda

回复 4# A1985

用形式验证来证明一个FEC RTL模块正确实现了算法？好奇现在哪家的形式验证工具的性能有这么强悍。只听说证明浮点乘除法，FFT这种规模的