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

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

日志

验证的计划篇之二: 计划的内容

已有 1642 次阅读| 2016-10-7 20:22 |个人分类:验证系统思想|系统分类:芯片设计

在制定验证计划的具体过程中,我们会将技术部分项目部分都考虑进来。从技术角度而言,我们需要考虑的有验证的功能点、验证的层次、测试用例、验证方法和覆盖率要求,从项目部分来看,我们也需要考虑使用的工具、人力安排、进度安排和风险评估。接下来,我们逐个分析技术部分和项目部分。

技术部分

验证的功能
需要验证的功能点主来自于功能描述文档,设计和验证人员在阅读文档的过程中,会将设计的功能、参数、性能从自然语言拆分转化为一个个可以单独验证的功能点,并且需要用定性定量的语言限定描述这些功能。
我们可以将功能点按照优先级分为:
  • 基本功能:通常包括时钟、电源、复位、寄存器访问和基本特性,这些可以在模块级完成验证。
  • 互动功能:一些需要同其它模块互动的特性,需要在更高层次的子系统级或者芯片级完成验证。
  • 次要功能:通常这些功能没有要求必须在流片之前完成验证,例如性能验证、效能验证。它们没有通过验证,并不会造成芯片的功能错误。

验证的层次
结合验证的功能点,需要清楚该功能点是否可以在较低的层次完成验证。从验证效率和激励自由度来看,我们应该尽量在较低的层次验证更多的功能点。在较高的层次,例如芯片级,应该侧重于系统集成测试。

验证方法
需要考虑采取何种验证方法,动态仿真、形式验证还是硬件加速?采取什么样的透明度,黑盒、白盒还是灰盒?采用直接测试还是随机约束激励?在之前的验证方法篇中,我们对比了不同方法适用的场景。

测试用例
有了带验证的目标功能,选择合适的层次和方法,在完成了验证平台搭建以后,我们就需要考虑如何利用现有的验证平台给出适当的激励,检查测试结果。

覆盖率要求
覆盖率是衡量激励生成种类和设计功能点验证的量化指标,无论通过何种验证方法,我们都需要采用覆盖率来确保给出了足够多的想要的激励类型,以及设计边界和内部穷历了可能的状态。除了给出合法的激励之外,也需要考虑给出一些错误的激励,来测试设计的稳定性和纠错能力。

项目部分

工具选择
对于项目而言,需要通过验证计划中选择的方法,来考虑选择相应的工具,它们包括:
  • 仿真工具
  • 形式验证工具
  • 验证IP
  • 断言IP
  • 调试器
  • 硬件加速器
  • 高层次验证语言(High-level Verification Language,HVL)

选择了不同的验证方法和工具,接下来就需要考虑安排有合适技能的验证人员完成工作。

人力安排
在确定下来验证方法以后,验证经理就可以考虑投入的人力了。由于不同验证方法存在显著差别,除过考虑个人的实际经验以外,也需要考虑他们是否熟悉该模块,知识和技术背景越贴合,越倾向于选择这样的验证人员。一般在同一个项目完整周期内,我们会考虑让固定的人员跟踪同一个设计模块,从搭建环境开始,经历模块级、子系统级和芯片系统级验证过程,这样对于项目的风险较低,人员的成长也更快。

进度安排
在安排人力的过程中,我们同时也将进度考虑了进来。一般而言,进度是从上向下传达的,验证经理事先会有一个大致的时间表,通过简单的计算:
  • 工作量 = 人力 x 时间 
来安排合适的人力投入到验证中去。而往往陷入的境地是,人力不够充分,或者时间不够宽裕,面对这样的困难,时间是没有弹性的,更多地需要在人力角度上考虑如何恰当地安排人力,做好动态的人力分配,实现高效的资源配置。那么对于验证经理而言,进度是否是不可修改的,必须严格遵循呢?这样的问题可能难以给出一个是或者否的答案,但是如果可以在计划中将设计的交付时间、验证的验收时间、不同模块的集成时间等等重要信息拆分开来,做到更细致的量化和评估,那么项目执行中的风险就可以在早期发现,同时朝着按时交付的目标共同迈进。

风险评估
在项目执行中,无论是设计人员、验证人员还是项目经理
,都会面临诸多不确定的因素:
  • 芯片结构不稳定因素。如果在项目执行后期,突然面临结构的变化,这肯定会给对应的设计和与它关联的设计带来很大影响,而验证任务量和时间也需要发生改变。
  • 工具的不稳定因素。在新的项目中,我们倾向于使用更新的工具版本,因为它们会带来新的性能提升和特性,而在新版本工具使用中也会有适应期,并非一帆风顺。如果我们需要替换工具,那么面临的工具替换成本、环境流程更新、技术培训都要更大一些。
  • 人力的不稳定因素。我们都希望在项目中人员结构可以稳定,这样就不会出现模块的验证人员被临时替换,加大验证风险的问题。同时,如果一个人投入到两个以上的项目,那么他在不同项目中的精力分配也需要考虑进来。
  • 模块交付时间的不稳定因素。由于验证的展开与设计的交付时间密不可分,所以HDL设计的交付时间对于验证进度的影响非常大,所以在计划初期,验证经理应该从设计团队那里获取清晰的交付时间,然在在此基础上做进度和人力安排。


在清楚了一份验证计划中需要包含的各项因素之后,我们接下来就需要考虑如何在项目初期准备这样一份关键的计划,以及在项目执行过程中怎样针对不确定因素的相应更新计划,确保项目的进度受到最小的影响。下一篇我们为你带来《计划的实现感谢你对路科验证的关注。

点赞

评论 (0 个评论)

facelist

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

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

    周排名
  • 0

    月排名
  • 0

    总排名
  • 0

    关注
  • 254

    粉丝
  • 25

    好友
  • 33

    获赞
  • 45

    评论
  • 访问数
关闭

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

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

GMT+8, 2024-5-11 21:46 , Processed in 0.016138 second(s), 12 queries , Gzip On, Redis On.

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