谎言、该死的谎言与硬件验证
谎言、该死的谎言与硬件验证
会议: SNUG Europe 2008 作者: Mike Bartley (Test and Verification Solutions) 页数: 23
摘要
本文调查围绕硬件验证行业的传说和迷思，并考虑它们对你的硬件验证策略的影响。例如以下说法的真相是什么？ - 验证占开发成本/时间/资源的70% - 有了伪随机策略就可以放弃定向测试 - 这个设计已经过形式验证，不需要仿真 - 缺陷发现率已降至可接受水平，为什么不能交付？
基于这些说法制定验证策略可能对所需的验证工作量和质量、首次硅成功的概率以及公司的商业成功产生广泛影响。本文将帮助你在真相和错误信息的雷区中找出途径，制定最适合你情况的硬件验证策略。
1. 引言
牛津英语词典将"迷思"定义为"体现自然或社会现象流行观念的传统叙事"。换句话说，人们接受为公认真理的故事，尽管可能没有太多证据支持它们。
本文试图解构每个"迷思"并考察以下重要信息： - 该说法的来源是什么？ - 该说法的准确性如何？ - 对验证策略的潜在影响是什么？
2. 解构"迷思"
2.1 "一半的芯片开发需要重新流片，四分之三由于功能缺陷"
来源：Collett International Research对2002年和2004年芯片重流片的研究。
准确性：调查显示71%的重流片涉及功能缺陷的修复，而非由功能缺陷引起。Synopsys在2000年的调查（图1）显示功能逻辑错误仍然占最大比例(43%)，但具体数据因来源而异。
影响：功能错误在芯片中比任何其他问题都更普遍。"做更多的功能验证"的简单结论太天真了。主要启示是跟上有用的功能验证工具和方法论，将它们合并成针对你的芯片类型和可用资源最有效的验证策略。记住"验证永远不会完成，它只是结束"。
2.2 "验证占设计周期的70%"
来源：在EDA演示中常被引用，但难以确定原始来源。
准确性：EE Times 2004年调查显示功能验证占22%。EE Times 2006年调查显示验证占约29%。IBM/IBS数据表明验证是最大的成本组成部分，但不是70%。
如何解释70%的说法？ - 是否指验证在设计周期的70%时间内进行？ - 是否仅考虑RTL设计阶段？ - 验证是否包括调试？
影响：约30%的设计周期工作分配给功能验证是普遍共识。但这只是一个指导方针，会根据芯片细节有所变化。
2.3 "验证挑战以双指数速率增长"
准确性：这个说法的基础似乎是验证复杂性与晶体管数量呈指数关系。但验证工作不能用晶体管数量来衡量。例如，增加更多片上内存会增加设计规模但验证任务不会显著增加。Brian Bailey的加法器例子说明了这一点：4位加法器加倍到8位——门数加倍但复杂性几乎不变。然而，如果加倍门数的同时加倍了状态存储元素数量，那么状态总数翻了四倍，验证复杂性也可能翻了四倍。
影响：设计规模在增加，但验证更多与设计复杂性相关而非设计规模。设计IP复用加速了"验证瓶颈"。
2.4 "伪随机仿真已经取代了定向测试"
分析： - 伪随机测试平台需要自检查（独立运行无需用户干预） - 定向测试可以使用自检查但也可以是自包含检查 - 伪随机测试通常需要比定向测试更多的仿真次数才能命中目标场景 - 伪随机测试平台开发通常更耗时但测试生成随后更高效 - 伪随机命中许多最初未在测试计划中枚举的场景，经常发现定向方法遗漏的缺陷
块级结论：块级应采用伪随机仿真和形式的混合。如果需要定向测试，伪随机环境应该通过约束生成它们。
芯片级结论：芯片级将保持混合。各因素的平衡将随着技术进步而变化。
2.5 "形式验证最终将取代仿真"
分析：比较形式验证和仿真方法论需要考察以下要求： 1. 现实性：形式验证在成本、人员和工具容量三个重要资源方面存在问题 2. 透明度和信心：当应用形式验证时，精确了解已验证什么仍然是复杂的 3. 结构化：形式工具通常提供结构化方法论 4. 持续结果：形式验证中提供持续结果是常见的 5. 增量性和回归：如果形式验证需要了解设计内部才能实现证明，可能遇到问题 6. 自底向上和自顶向下：形式工程师通常将顶层属性分解为更小的属性
影响：形式验证不会取代基于仿真的验证，但随着设计复杂性的增加，形式验证不能被忽视。应该考虑如何混合形式和基于仿真的验证策略。
2.6 其他迷思
2.6.1 "我们不需要功能覆盖率和结构覆盖率——选一个就行" - 结构覆盖率（语句/分支/条件覆盖率）客观但只能覆盖存在的RTL - 功能覆盖率主观但能给出设计被所需刺激触发的信心 - 两者互补，应该同时使用
2.6.2 "我们的缺陷发现率已经下降——可以交付了" 缺陷发现率通常遵循经典的S曲线。但需要注意如果随机仿真在某种程度上被过度约束，移除过度约束可能导致缺陷发现率的突然增加。
2.6.3 "缺陷发现率已经下降且覆盖率高——可以交付了" - 即使严格的块级覆盖率目标已经满足，当模块被移到子系统或系统级测试平台时，刺激微妙地改变并开始识别新缺陷 - 当芯片仿真从硬件刺激转移到硬件/软件协同验证时，发现新缺陷
2.6.4 "信任我们的设计IP——它已经完全验证了" 应审计外部IP供应商执行的验证： - IP有多成熟？ - 检测到了什么缺陷？ - 审查验证策略和实际执行 - 有哪些验证支持？
3. 结论和建议
主要结论是要始终警惕携带统计数据的销售人员。块级伪随机仿真现在应该是常态。验证团队应该将形式验证加入工具包，因为工具变得更易用且与仿真更集成。芯片级IP复用方法论允许更易构建伪随机测试平台。
验证团队需要管理各种数据：结构覆盖率、功能覆盖率、缺陷统计等。验证工程师的一项主要技能是能够解读这些数据并为发布或流片决策提出建议。
4. 致谢
特别感谢Intel的Shalom Bresticker提供了许多参考文献和宝贵反馈。感谢Darren Galpin、Serrie Chapman和Tim Blackmore。
5. 参考文献
[1]-[21] 包括Collett International Research、EE Times调查、DAC会议论文、Intel形式验证方法论、Magellan案例研究等。
图片索引
本文共1张图片，存放于 SNUG_2008_Europe_Bartley_Lies_Verification_paper_images/ 目录。