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

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

日志

芯片验证全视之四: 验证的任务和目标

已有 3986 次阅读| 2016-6-30 07:18 |个人分类:验证系统思想

对于一名验证师而言,他的工作就是完成分配给他的任务,这个任务可能是模块级(module level)、子系统级(subsystem level)或者系统级(chip level)的。准确来讲验证的目标,就是“按时保质低耗”完成目标硬件设计的验证工作,这句话实际也包含了要完成验证目标需要考虑到的三个方面:

  • 按时:需要按照项目预先的进度来考虑验证的时间节点(milestone)。验证师需要在项目一开始的时候就将时间的概念记挂在心上,我们之前提到的验证师的五种能力维度,在具体面对项目进度的时候,也需要考虑哪个维度为主,哪个维度为辅。例如针对硬件设计的验证计划、验证环境的复杂度和复用性、大概需要用多少测试用例来尽快达到基本验证工作量的80%这些都是要与项目进度一同考虑的。要知道“一个都不能少”在芯片流程中的重要性,没有一款芯片可以因为其中一个模块的验证延迟而有信心去流片,所以整支验证队伍纵向自上到下,横向覆盖各个功能模块的每一位验证师都应该有这种意识,无论何时,时间总是第一位的,时间就意味着客户的耐心和市场的窗口。

  • 保质:指的是尽可能少地将缺陷暴露在流片以后,至少要尽可能少地暴露在客户和市场面前,因为从成本的角度来看,由于缺陷的暴露在不同阶段造成的损失是指数递增的。而且,如果芯片交付给客户以后才被反馈出一些大的缺陷,那么芯片设计方就会背负很大的压力,除了要同客户一起进行高密度的对话、联调以外 ,也需要芯片设计方整个产品链都要为这个缺陷付出更大的人力物力成本;如果芯片是在客户一侧通过却被市场发现自身性能不如预期的话,那么会对芯片设计公司和客户双方都造成消极的影响,无论是从市场反馈,还是用户对品牌的认知度上面都是如此。

  • 低耗:低消耗有两方面,用更短的时间、更少的人力来完成芯片设计任务,这对于芯片设计公司而言,是一笔前期看得见的可以预期可以控制的成本。同时,也有一些成本是突发的,其中一个就是缺陷的暴露问题。从下图可以看出又缺陷造成的额外成本是怎么在不同被暴露的阶段来影响芯片项目成败的。


可以看到的是,硅前验证中RTL验证发现的缺陷带来的影响要明显小于Gate验证带来的影响,因为RTL阶段发现的缺陷,只需要修改RTL,而Gate验证发现的缺陷需要同时做RTL修改和网表手动修改,更是要后端的一系列环节的重复。硅后测试中,如果发现了缺陷,那么就需要考虑这个缺陷是否是致命性的,所谓致命性的就是它会无法使能一些重要功能,甚至本身会影响一些重要功能的失效和错误行为,并且没有办法通过软件层面来做修复。


这样的致命性缺陷就意味着芯片要做第二次流片,而且也要针对致命缺陷做出修复、功能验证、后端流程,通常这样的过程会在三个月以上。如果一个致命缺陷等到被交付给客户以后才发现,那么造成的损失则是双方的,对于客户来讲,他们需要为这个致命缺陷买下产品延迟上市的单,对于芯片公司来讲,恐怕这可能是最后一次双方合作的机会了。


进一步来看,如果我们将硅前流程、硅后流程同客户反馈联系在一起的话,就能够对芯片流程有一个更清晰的认识。


从上图我们也可以发现,一旦芯片在出片以后被检测出的严重缺陷会直接导致芯片的二次流片,这对于成本控制是一种额外的损失,同时也会将时间和人力资源消耗在本可以避免的二次流片上面。所以功能验证是唯一可以用最低成本在硅前流程就可以将上述目标三个因素“按时、保质、低耗”完成的方法。也正因为如此,对于功能验证而言,验证经理会通过量化图标来衡量验证的进度和产出,而用来衡量的两个标准,一个是时间,一个是发现的缺陷数量



通过缺陷数量在时间线上的记录,我们可以绘制出缺陷数量的增长曲线。一般来讲,缺陷数量的增长曲线是逐渐逼近变缓慢的,作为功能验证阶段应该需要保证的就是将缺陷数量曲线的增值(至少是致命缺陷数量)保证在硅前阶段,不应该让其发生在硅后测试阶段。而且针对缺陷的类型,我们一般会遵循先易后难的验证方法,这表现在了两个方面:

  1. 我们给出的激励向量应该是先易后难,先从简单的测试向量给出来测试目标设计的基本功能,这一点我们在之前的《验证能力的五个维度》中有提到随机约束域的宽窄设定和验证阶段之间的关系。当验证已经将基本功能测试完毕以后,我们的测试向量再朝着更复杂的情景着手去测试其它功能。

  2. 我们发现出的缺陷也应该是先基本后高级。关于这一点有两方面的好处,当一开始的激励向量是基本态的时候,这有助于设计本身在基本激励缺陷报告反馈中逐步稳定,同时也留出了一定的时间用来帮助设计师和验证师针对设计细节交换意见,在硬件描述上面统一理解。这种缓冲会使得在其后的复杂测试中,设计师和验证师双方会就复杂情形中的硬件输出结果快速达成一致,因为之前已经就设计思想和原理达成一致了。而对于验证师自身而言,这么做也符合验证的曲线,也就是前期的缺陷曲线斜率较高,是因为设计本身容易被发现一些基本设计问题,而随着验证周期,缺陷曲线率也会慢慢变小,这说明设计自身的稳定和功能完备情况趋于最终的设计目标了。



所以对于一名验证经理而言,如果他有习惯追踪缺陷率曲线,那么一般建议他可以检查两个地方:

  1. 缺陷率的曲线是否在收敛,或者说斜率是否在变小,这一定程度上可以说明验证的状态是否接近于验证目标。

  2. 此外也需要注意整个过程中的发现的缺陷种类,应该是从基本缺陷再到高级缺陷。假如到了后期缺陷率尽管在收敛,然而却发现了一两个基本缺陷,那么到了这时候就应该对整个验证质量打一个问号了,有必要的话还需要同验证师一起回顾验证计划、验证环境和测试序列,因为越到后期越不应该出现基本缺陷的发现,否则验证经理无法对于整个验证任务的完成有足够的信心。



至此,我们已经带大家了解了验证的任务和目标,下一次验证全视的话题将是《验证的周期》。


您可以在手机移动端同步关注订阅号“路科验证”。

如需转载请联系路科验证,并注明出处“路科验证”。


点赞

评论 (0 个评论)

facelist

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

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

    周排名
  • 0

    月排名
  • 0

    总排名
  • 0

    关注
  • 253

    粉丝
  • 25

    好友
  • 33

    获赞
  • 45

    评论
  • 访问数
关闭

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

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

GMT+8, 2024-4-19 18:40 , Processed in 0.019180 second(s), 11 queries , Gzip On, Redis On.

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