最近我们在做一款2000个核心的CPU验证，遇到了挺多麻烦事。跟大家聊聊这个过程中的一些感受，希望能给同行们提个醒。 第一类问题最明显，就是编译阶段就报错的那种，通常是少写个分号或者漏掉某个分支。这些bug就像红绿灯一样显眼，只要稍微用心一点的测试都能马上发现。其实我们团队遇到这类问题的时候，测试用例写得不够全面，有些功能根本没被覆盖到。所以现在我们决定测试用例一定要写全，设计团队也得严格按照规范来改代码。 第二类问题就比较隐蔽了，它们往往只在一些极端情况下才会出现。比如一条指令、一次中断和一次缓存行替换同时发生，时间差必须精确到毫秒级别。为了找到这些问题，我们的测试平台必须能够模拟各种延迟和事件交错。通过这样的方式，我们能把隐藏的漏洞逼出来。 第三类问题是最头疼的，它们经常被客户投诉或者是在内部加班时偶然发现。这说明我们现有的测试方法还不够全面。虽然我们用了随机测试，但是这些测试结果往往同质化严重。为了解决这个问题，我们给随机数生成器加了更多维度的约束，比如指令后缀、寄存器位宽还有异常类型。同时我们也引入了定向刺激，对关键路径和热点模块做针对性的测试。 第四类问题就更难了，有些漏洞在现实生活中根本不会被触发。比如调试器每周期改写字节或者U盘突然拔掉等等。如果客户不会遇到这些情况，我们就没必要浪费资源去验证它们了。 判断这些问题是否重要的标准很简单：后果对客户是否可见。如果USB控制器挂起导致数据丢失了，那就是个bug；如果用户自己把U盘拔掉导致文件损坏了，那就不算bug。我们不应该过度纠结这些“不可能发生”的场景。 面对这四类漏洞形态，Codasip采用了多组件测试平台、定向随机生成器还有事件交错引擎的组合方案。我们通过版本控制和每日构建来监控规范改动；对关键路径使用确定性随机和约束求解；对极端案例建立事件日历和延迟矩阵；对隐藏漏洞持续扩大测试空间并进行双倍覆盖回滚。 随着项目的推进，我们的验证技术也在同步迭代升级。这样就能让每一轮的测试都比上一轮更聪明、更全面了。Codasip的RISC-V处理器IP与工具链已经在全球几十款芯片中成功落地了，持续以开放标准助力客户把漏洞风险降到最低。