从芯片验证说起，不合理的输入应该得到何种输出

本来想从芯片验证的事情说起，但是行文开始后反悔了，还是从过年放假开始说起吧，不然不好酝酿情绪。过年对于我们这种社交匮乏、无所事事、游手好闲、不知道玩点什么好的家庭蛀虫而言，最舒服的放松方式可能躺着玩手机看新闻刷短视频了。当然刷也不能干刷，偶尔也得让脑子转一转（去年转出来的结果就是局外人思考），所以今年转出来啥了呢。
不知道这几年大家有没有一阵阵的刷到类似的视频或者热搜，不知道啥时候就会批量冒出来一段然后销声匿迹很久。为了公平起见防止争吵我多放几家的吧，没放上来的也不要着急，都有份。





萝卜的出镜率真的很高啊，还有火腿肠、辣条等都是这类视频和文案的常客。大部分人看到这类视频可能都没啥心情波动，或是感觉生气那可能是粉丝，感觉爽的可能是对家粉丝吧。我刷到的时候基本态度就是，这也值得称为一个新闻吗？算是比较中立觉得不好不坏的态度。
而后看第二件事，这个是几年前刷到的疫情时期的事情了，因为是重新搜出来的因此是文字版。



对于这件事当时刷到时的心理写照就是“ber有大病吧”，显然个人是完全的消极反对态度。

然后再说第三件事，这个不是网上刷到的是课堂上刷到的。大一C++第一堂课的时候，老师跟我们强调编程的健壮性要求时举了个例子。他的原话大抵是这样的：“之前你们一个师兄，很优秀。在我这课上第一次接触编程，学习非常的积极。那天他来我办公室说把布置的作业，用C++写一个计算器，完成了让我来试一下看看。于是我就输入了一个5+5计算结果没有问题，又输入了一个5+a，然后计算器就‘炸了’...”教室里大家哄堂大笑，在笑声里也领会到了老师说的程序需要强大稳健性的指导。
这三件事虽然千差万别，但是总结其共通之处均是一个不合理、预期外的输入导致系统/软件/产品产生了一个不合理的输出。而对于这三件事我的态度分别是：中立无所谓、消极反对、积极支持，不知道有没有朋友是类似的想法。以合理的输入和合理的输出为两个维度做表，可以得到：

	合理的输出	不合理的输出
合理的输入	理所应当√	不合格×
不合理的输入	？	？

显然，合理的输入得到合理的输出是理所应当的，而得到不合理的输出时那直接就是质量不合格没啥可说的。问题出在不合理的输入场景下，什么是不合理输入呢？即对于某个系统而言，不符合其要求的输入或使用情况，比如把智能手表戴在萝卜上测心率血氧这种。即使产品没有在屏幕上提示（有些会有提示比如紧戴于腕部xx位置并静止xx时间），大家（包括产品、设计、测试以及脑洞不太大的使用者）也默认这东西应该是戴在人的手腕上来进一步使用的，所以戴萝卜上是一种不合理或者非预期的输入。而此时合理的输出是什么呢？最合理的应该是测不出来或者告警要求正确使用，不合理的输出是真的测出来数了（显然萝卜没有心跳血氧啥的哈，就算千年萝卜也不能成精了吧）。啰嗦的太多了，提炼一下刚刚这段就是，不合理的输入的场景下应该得到何种输出？兜兜转转终于回到了主题，那用之前芯片验证时的一段经历做一下思考。在之前的一篇文章【芯片验证】聊聊配置寄存器的动态改配测试与等级里提到了这样一件事，就是对于寄存器“空洞”地址的测试：

简单讲就是系统的寄存器地址存在很多的空洞，在正常的使用场景下这些地址压根就不会被访问到。而作为补充验证，必须要去主动的访问一下这些地址以备不测，毕竟“你也不知道用户到底能做出啥事来”。在测试前问了下leader，对于这些区域的访问，应该有个什么结果反馈呢？回复给我的是不挂死寄存器访问总线+读回值应该为全F（记得当时的寄存器访问总线好像没有error否则我也不会去问合理的结果是什么）。而后测试起来之后发现，虽然均能保证不挂死，但是确实有些空洞读回值是X态或者随机值而非全F，这个SOC还挺大的一个用例跑了我好几天。于是就拿着结果去找leader问一下是否要提RTL bug单来修改。最后决策的结果就是既然没有挂死总线，那读回值不符合约束的问题就不进行RTL修改，毕竟空洞地址本身就“没有意义”。我自己估计可能是因为时间点太靠后了（毕竟都已经进行这种补充测试了），每一次RTL的修改都可能把后端的时间延后一截，因此对于这类“非法”访问的反馈合理值也没有拘泥。所以从那次之后我锚定了一个标准：不合理的输入可以有，但是不能影响合理输入的正确性。后面在进行芯片设计工作时，也遇到过很多这样的场景。比如一个模块会上报几十种“例外”上去，这些“例外”都是针对输入指令或者配置的不合理而设置的。这些思路也差不多，在使用规范和约束已经明确和详尽的前提下，系统能处理的一些不合理输入那尽可能处理，处理不了的但是能发现那就尽可能提醒上位机或使用者，如果发现的代价都很大那你就不能苛责更多了，毕竟使用规范和约束已经明明白白在这了。就像文西的手电筒，告诉你有光照才能亮，那没有光就不亮有什么问题呢？！

所以最后我的态度就是，在产品已经明确了什么是合理的输入什么是不合理的输入，并且使用规范和约束都已经讲清楚的前提下，一个错误的输入，无论引发的是正确的输出还是错误的输出，只要不影响其对正确输入的正确判断和输出，那么就是一款合格的好产品。在此基础上如果能识别错误的输入甚至纠正，那自然是更为优秀的产品。那么把刚刚的表拿过来补上：

	合理的输出	不合理的输出
合理的输入	理所应当√	不合格×
不合理的输入	who care?	who care?

	合理的输出	不合理的输出
合理的输入	理所应当√	不合格×
不合理的输入	who cares?	who cares?

毕竟产品和研发的精力是有限的，而可以优化提升的方向是无限的。最后想说的是，如果有两款智能手表产品，打出的标语分别是：

A：测心率测得特别特别准

B：没有心率的东西一定不会测出数
那我会毫不犹豫选择A。如果两款产品分别是：

A：测心率测得特别特别准

C：测心率测得特别特别准，同时没有心率的东西一定不会测出数
那我会选择便宜的那款。个人观点，仅供参考。

系列文章入口
【芯片设计】SoC 101（一）：绪论【芯片设计】FIFO漫谈（零）从无处不在的FIFO开始说起【芯片设计】计算机体系结构（一）虚拟内存【芯片设计】深入理解AMBA总线（零）绪论
【芯片设计】握手协议的介绍与时序说明【芯片设计】复位那些小事 —— 复位消抖【芯片设计】快速入门数字芯片设计（一）Introduction【芯片验证】UVM源码计划（零）下定决心读源码前的自测环节
【芯片设计】异步电路碎碎念（一） 到底什么是异步电路
【芯片设计】从RTL到GDS（一）：Introduction
【芯片设计】系统中的可维可测状态记录寄存器设计
其他文章链接
【芯片验证】sva_assertion: 15道助力飞升的断言练习【芯片验证】可能是RTL定向验证的巅峰之作【芯片验证】RTL仿真中X态行为的传播 —— 从xprop说起【芯片验证】年轻人的第一个systemVerilog验证环境全工程与解析

【芯片设计】verilog中有符号数和无符号数的本质探究

【芯片设计】论RTL中always语法的消失术

【芯片设计】代码即注释，注释即代码

【芯片设计】700行代码的risc处理器你确实不能要求太多了

入职芯片开发部门后，每天摸鱼之外的时间我们要做些什么呢

如何计算系统的outstanding 和 burst length？

芯片搬砖日常·逼死强迫症的关键词不对齐事件

熟人社会里，一群没有社会价值的局外人