路科验证的个人空间 https://blog.eetop.cn/1561828 [收藏] [复制] [分享] [RSS]

空间首页 动态 记录 日志 相册 主题 分享 留言板 个人资料

日志

验证背锅是一种宿命

已有 2420 次阅读| 2018-6-14 21:15 |个人分类:验证前沿资讯|系统分类:芯片设计

当验证做的足够好的时候是否就可以拿去流片了?

 

对于全球的工程团队来说,验证是困扰他们的巨大挑战,他们想知道怎样的“足够”是“好的足够”,是“足以进行流片”的“足够”。答案并不简单,它包含了比以往更多的变量,特别是在功耗方面

 

Mentor Graphics的首席验证科学家Harry Foster指出,当使用“测量”这个术语时,这意味着存在一些度量标准,这就有了难度,因为在实际的功能验证中,通常只使用两个度量标准——代码覆盖率和功能覆盖率,以及一个新兴的标准——统计覆盖率

 

Foster说:“代码覆盖率是一个自动的衡量标准,去量化输入激励的准确性,因为它能够激活设计中的一行代码或一条指令。这是非常重要的,因为我实际上可能会激活一个有错误的代码行,而我以前从来没有发现它。所以这里的精准性只是我的输入激励做的怎样,这就是告诉我们的。”

 

另一个度量准确性的标准是功能覆盖率。但是与代码覆盖率(自动指标)不同,功能覆盖率手动的指标。必须创建一个功能覆盖率模型,告诉我们输入激励能够激活设计中的关键功能,通常这个功能是通过创建一个功能覆盖率模型来找到一个测试计划。在代码覆盖率是自动的情况下,在准确性方面存在着挑战,功能覆盖率本质上跟代码覆盖率不一样,你面临的风险是功能覆盖模型的准确性不好,这意味着你会错过了你需要检查的东西,而你永远不会知道。

 

覆盖率模型现在已经开始在融合统计覆盖率这一指标了。后来我们使用代码覆盖率和功能覆盖率作为衡量我们IP测试环境“优点”的一个指标,但是当转向SoC系统时这些指标开始崩溃,因为这些类型的指标在那里不再“完美”了。而统计覆盖率则完全不同,它还需要你手动创建这个覆盖率模型,它做的是跨越IP层次和仿真场景,根据系统应用场景来构建这个覆盖率模型。换句话说,设计中有一些方面,是无法单独通过查看单个IP来验证的,因为那样远远不够。你必须查看IP群并且基于仿真场景进行它们之间的交互分析,这一要求无论对于测试编写还是统计覆盖率模型都是复杂的。例如,如果我在设计和多处理器(在大型系统/ SoC中执行)中有多个高速缓存,传统的代码覆盖率和功能覆盖率开始在这里崩溃。再者,它在准确性方面会遇到同样的问题。有一句话说的好,如果你不问这个问题,你就不会得到答案。这些覆盖率模型,功能覆盖率或统计覆盖率是同样的事情。如果你不考虑你要检查的内容,你就不会去检查它

 

Cadence系统开发套件产品营销部门总监Frank Schirrmeister表示,从这些方面看来,我们工作的驱动力就是做出不会被遗忘的产品。首先,当然希望尽可能地将设计变得没有缺陷,这种愿望会使产品的质量得到提高。但毫无缺陷常常会在一些领域如军事,安全或汽车安全方面转换为安全问题,汽车刹车就不会变成不可调动,因为那样人们就会死亡。

 

其次,常常被掩盖却令人困惑的问题是我们的设计什么时候准备好去流片了。在衡量验证的时候,我们一直在验证方面主要采取着所谓的“指标驱动验证”,本质上是说,“这是我想要验证的验证计划。然后,我使用从代码到功能到断言的各种方法来追踪。然后,这个指标说:“我有我的目标,所以我目前正在获得需要的覆盖率,这使我获得了一定的验证信心。”,然后自动化部分能够定向测试来覆盖尚未被检查的未覆盖的空间。

 

可以流片的标准有很多部分构成,但是如果你一直去等待验证的完成而什么都不干,那么任何人都不能完成流片。Schirrmeister说,验证本身是一个相对自由不受约束的部分验证是永无止境的,关键在于你对某一个部分所做的工作有多少信心。因为这个自由性,你需要决定不去验证什么。“我正在为我要验证的东西构造一套定义好的场景,但是我也需要能明确有什么是没有做的,以便之后有人在使用并没有验证的模式而出现问题时不会感到太惊讶,因为验证可能并没有覆盖到它”。

 

他强调,提高验证准确性所需要的是自上而下的方法。在这一点上,我所认为的IP级验证,也许还有更小的子系统验证,在UVM等的帮助下,可以在块级别上帮助解决问题。但这是一个自下而上的观点,需要改变的是将其自下而上的观点转变为自上而下的观点。而这正是缺少的。“我有150个IP块正在集成,20个新块正在生成,其中一些是高级综合生成的,其中一些手动编码的。该如何确保一切工作是自上而下的,这就是目前缺少的而我们要去实现的目标。

 

比覆盖率更重要的

 

Foster强调验证的准确性比覆盖率更重要。你看我们今天的验证方式,往往是降低了准确性来提高性能的。我们是故意冒这个险的。例如,在RTL模型中,我们通过抛弃时序和功耗来降低准确性以加速模拟。这意味着我们冒着设计方面的风险,甚至无法在RTL中建模。一个很好的例子是跨时钟域的亚稳定性(meta-stability)。这就是你已经看到的有很多像跨时钟域验证一样的技术出现的原因。

 

他指出,另一个很好的例子是功耗。“如今功耗是非常有趣的话题,这是我们10年前甚至没有的问题。我们有多个不同电源域的IP,准确性通常是这样被降低的,但是我们已经到了不能再这样做的地步了,我们不能再用RTL来建模。这引发了UPF的出现,使我们能够描述功率,并使我们能够进行功率感知类型模拟来获得更多的准确性,但看看我们在做什么?有趣的是,我们使用技术来加速仿真,但突然之间准确性更差了,所以我们使它回归到之前。

 

Synopsys公司验证营销高级总监迈克尔·萨尼(Michael Sanie)指出,当进入系统层面时,仿真和形式验证所使用的工具是另外的。你开始做一个很高层次的架构探索或性能分析,甚至是在RTL之后。你也开始着眼于做模拟,在那里你运行了一大堆真正的软件。最终你也可能会做FPGA原型。人们也将覆盖率的概念引入到这些工具中。

 

他预计该行业将开始展示如何跟踪模拟环境中的覆盖率,但对于工具信息则不会太具体。

 

在某些时候,我们需要开始考察性能覆盖率,因为当您查看一个系统时,就有了一个度量标准,您需要以一定的速度执行这个度量标准。 否则,就会成为无用功。你做了多少测试来达到性能指标?当然,这并不会变得容易,但也许在那个时候,将会有其他方式来提升验证的信心,而不仅仅是覆盖率。也许,我们会把它带到实验室,并运行一大堆测试。

 

他认为整个验证领域正在变成一个越来越大的无边界问题。“我们对于一个行业的理解有多少,我们不知道。不过,我们会迸发出出新的想法和新的技术。”


路桑说

路粉们新年好!新年工作第一天,终于可以不做家务不带小孩来写一点东西了,神清气爽啊。


之所以标题说verifier背锅是一种宿命,通俗来讲,“做好那是你们应该的,做不好那是你们应背的”。文中谈到的代码覆盖率和功能覆盖率在系统级场景上的“measurement”不够准确,换个角度来讲的话,是要大家能够“佛系”一些,首先承认这个世界是不完美的,没有什么芯片是没有bug的。我经常给大家讲,verifier运气好一点和差一点的区别在于那些个影响系统运行的bug是不是在流片之前被发现了,但运气好可不是拜一拜就能得来的,它还是需要有一个正确的策略配合着各种验证量化的手段


这里的策略需要逐渐从自下而上改为自上而下,这个转变的过程是伴随着芯片的复杂度增加而形成的。UVM和形式验证可以在模块一级很好地完成任务,但在系统一级即便可以使出本领,但在量化手段上需要有改变。这指的是系统一级的验证应该自上而下地传达测试场景和指标,所以文中的统计覆盖率,路桑认为它谈的是“场景覆盖率”。系统一级的verifier需要知道,哪些场景是真实的场景,它们需要将接近于真实的软件应用场景移植到硬件验证中来,完成硅前(pre-silicon)验证可以真实覆盖硅后(post-silicon)的软件应用。而场景覆盖率的提出也带来了一些问题,它们包括了仿真性能的限制、验证思维的更新以及验证场景的覆盖率模型制定

  • 要在硅前完成软件级的测试,就需要克服仿真性能的限制,这一点可以考虑虚拟机建模、模拟器或者FPGA来协助完成验证过程。

  • 以往的专注于特定模块,测试特定功能的线性思维需要朝着系统级功能、软件级应用的非线性思维转变, 并且创造条件,桥接复用SW engineer的测试代码。

  • 场景覆盖率的模型不同于传统的覆盖率模型,它自上而下的思维方式可以成为HW与SW在系统覆盖率测试上的统一覆盖率桥接。目前便携激励标准(portable stimulus standard)的制定和其自有的覆盖率模型是朝着这一方向迈进的。


如果你已经行走在验证的路上多年,那么你是否一点体会,觉得验证的大坑永远填不完呢?负重前行吧,因为“看门人”(gate keeper)就是verifier的宿命啊。




原文来自于Semiengineering, Ann Steffora Mutschler “Measuring Verification Accuracy”

https://semiengineering.com/measuring-verification-accuracy


谢谢你对路科验证的关注,也欢迎你分享和转发真正的技术价值,你的支持是我们保持前行的动力。





点赞

评论 (0 个评论)

facelist

您需要登录后才可以评论 登录 | 注册

  • 关注TA
  • 加好友
  • 联系TA
  • 0

    周排名
  • 0

    月排名
  • 0

    总排名
  • 0

    关注
  • 253

    粉丝
  • 25

    好友
  • 33

    获赞
  • 45

    评论
  • 访问数
关闭

站长推荐 上一条 /1 下一条

小黑屋| 关于我们| 联系我们| 在线咨询| 隐私声明| EETOP 创芯网
( 京ICP备:10050787号 京公网安备:11010502037710 )

GMT+8, 2024-3-28 19:05 , Processed in 0.025006 second(s), 12 queries , Gzip On, Redis On.

eetop公众号 创芯大讲堂 创芯人才网
返回顶部