谈谈数字验证场景的“边界”和“异常”

在IC验证者进行测试点评审的时候，或者在和DE（数字设计工程师）、SE（系统工程师）进行验证场景讨论的时候，常常会听到“边界”“异常”这俩词。他俩就像是一对形影不离的好朋友，同时出现在验证者的耳畔和DE、SE的嘴边。

就像丑媳妇早晚要见公婆，验证者也注定要面对它们，无论何时何地。

其实，在每一位丑媳妇的心中，多多少少都有一些公婆的威严形象。对于“边界”和“异常”，验证者也有咱们自己的理解。

其一、边界场景。

“边界”是与随机验证方法强相关的概念。

每一个随机参数和变量都有各自的随机范围，有范围，就有边界。此其一也。

随机验证的底层逻辑是把DUT（Design Under Test）当成一个“黑盒子”，验证者向其输入随机的激励，随机的去撞DUT内部的各个逻辑功能。每一次run随机用例之前，验证者都不知道会撞到哪部分DUT的逻辑功能。而在DUT内，不同的逻辑区域承载不同的功能特性。分了区域，就有边界。次其二也。

若把DUT比作一个硕大的枣树，随机验证用例就是一根棍子。验证者仰头望着繁茂的枝头，要把手上这根棍子握紧。有枣没枣，打几杆子。

通常IC验证者认为，配置变量、输入数据的合法的取值范围的“边界”值，是一种边界场景。这主要针对可由单个变量构成的场景，对于多个变量构成的场景，则要考虑每个变量的取值。通常，0x0，0xFFFF_FFFF（全F），Max-Value，Min-Value等被认为是“边界”值。

“边界”场景的变量数据必须是合法的（合理而有效的取值）。合法的则是“边界”，非法的则可能是“异常”。

相比于“边界”场景，“异常”场景在验证者和DE、SE之间偶尔会存在一些争议。

比较典型的是，软件的错误配置是否要当做异常场景在数字验证中进行覆盖。

认为“是”的人（大概率是DE/SE），通常觉得这种错误配置是有可能发生的，为什么不验呢？

认为“否”的人（大概率是验证者），回怼：汽车出厂检验的时候，是不是也要在河里开几圈啊？

窃以为：要判断一个错误配置是不是“异常”场景，关键是要看芯片的方案和数字逻辑是否做了相关的“设计”。即，硬件电路是否支持这种软件的错误使用。若支持，则应该作为异常，必须在验证中进行覆盖。若不支持，则不验证。这也是为什么非法的数据可能是异常：若支持，则是异常；若不支持，则啥也不是。

此处的“设计”，不是只在DUT中有相关的逻辑电路，而在FS中缺失相关的描述。更不是只有SE/DE的空口白牙的说说而已。异常场景必须要在FS（Feature SPEC）中进行描述，并且数字逻辑也要支持。无文档，不验证，尤其是验证者面对“异常”场景之时。

举个例子，某芯片的一个配置参数范围是1~127。如果在FS中写了：若是配置0，则认为是软件错误配置，芯片记录错误配置信息并上报中断。那么，配置参数=0是典型的“异常”场景，验证者需要构造这种激励，覆盖该场景。若是FS中没有相关的描述，则不覆盖。若是FS没有写，但是SE口头要求验证者构造该场景，数字逻辑行为不可知，这时，验证者可大胆的跟他说NO。

因此，异常场景的关键所在，还是FS中的相关描述。关于该场景，SE们在FS中至少要说清两点：

软件对硬件不能做什么。此其一也。

软件若是做了不该做的事情，硬件会怎样。此其二也。

站在软件和应用的角度看“异常”，它更应该是DUT的某种业务功能在执行期间，发生了错误或非预期的情况后，硬件逻辑的一系列相关动作，以帮助软件更好的获取信息，定位错误，拨乱反正，恢复正常。而不是业务开始之前就可知的配置错误（软件本身的错误）。当然，硬件逻辑针对软件错误做的这些所谓的“保护设计”，也能在某种程度提升芯片的问题定位效率和应用的鲁棒性。但是这些“保护设计”都是实打实数字电路，会占芯片面积，也会消耗功耗。如何在提升芯片应用的鲁棒性和降低冗余设计优化芯片整体PPA之间，寻找到最佳的平衡点，是摆在每一位SE、DE面前的大题目。

题外话：

“认清生活的本质之后，依然热爱生活。”最近对这句话有了深刻的认识。生活之于每个人都或多或少有些许不易，不能因为这些而丧失对生活的热爱。苏轼说他看世间无一个不好的人。那估计他看世间的事也无一件不好的事。某件事咋一看去不甚好，换个角度再看，再看，总有好的一面。诸位明公，共勉之。

审核编辑：刘清