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

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

日志

芯片验证全视之六: 验证的周期(中)

已有 2230 次阅读| 2016-7-1 08:48 |个人分类:验证系统思想

我们这节内容将带着大家深入验证周期的一些细节,目的在于更详细地帮助大家了解认知清楚每一个阶段的具体任务和值得注意的地方。



功能详述

对于一个芯片,大到芯片自身,小到可以细分下来的模块,都需要系统工程师给出功能详述文档。我们这里举出较小颗粒度的模块功能详述文档,来看看一个基本大小的模块,是如何依靠功能详述文档来实现硬件设计和功能验证的。一份模块功能详述文档,一般会包含这几方面的信息:

  1. 接口信息。是否是标准接口,是标准接口的哪一个版本,或者从上到下支持什么接口版本。如果接口是标准接口,那么功能详述中,不需要详尽列出接口的时序信息、各种命令、数据传输的情况分类,而只需要给出基本的时钟、复位、接口信号名列表信息,对于标准接口,设计人员和验证人员可以通过下载标准接口文档来更详尽的了解接口信息。如果接口是公司内部定义的接口(暂时没有被商业推广到整个业界,但仍然有标准接口的风格和对称的详尽描述内容),那么这时也需要参照内部定义的接口文档。如果是自定义接口,这种接口并没有被常规化下来,那么这个时候功能详述文档中就应该尽可能周全地描述完所有需要给出的信息,因为日后设计人员和验证人员双方依照的接口标准就是功能详述文档了。

  2. 结构信息。结构信息会将模块进一步细分为各个功能组件,以及功能组件之间的逻辑关系。细分下来的功能组件对于设计人员而言可以对应的设计出该RTL模块文件,其后可以自底向上进行集成;对于验证人员而言,他也可以考虑将不同组件的功能检查归入到不同的比较器当中,这一点尤其方便设计人员与验证人员从无到有做设计的过程,因为基本上设计和验证工作可以同时展开,从设计组件A和验证环境VA,再到组件B和验证环境VB,再到组件C和验证环境VC,最后集成出模块M(A+B+C),并且利用已有的验证环境V(VA+VB+VC),就可以完成整个模块M的集成和验证了。

  3. 交互信息。由于模块稍后会被集成到更高一级的子系统当中,所以在功能详述文档中,就会有模块M同外界模块交互的示意图,有必要的时候,这些交互信号之间也会给出准确的时序信息,确保在做高层集成的以后,两个模块之间的交互会按照预期定义的情况执行。比如一对握手(handshake)信号,需要交代输入信号的频率、是否需要考虑同步、是电平信号还是脉冲信号、大致维持几个时钟周期,而相应的输出信号也要有类似的考量,满足输出信号接收方的要求。

所以,功能详述文档是硬件设计和功能验证的基础部分,也是共同参考依照的标准。设计人员会通过自己的理解,将其实现成RTL文件,而验证人员也会按照自己的理解,为设计构建出验证环境。尽管看起来,验证人员又重复了一次功能上的理解,但正也是因为这个部分,二次确保了功能描述文件可以被设计和验证双方都能理解一致,这样验证人员自己设计的参考模型(reference model)才也会按照功能详述文档做出正确的行为给出理应的数据输出。这一参考模型对应硬件设计,会通过结果比对,来检查出是否有不符合预期结果的情况。通过这种方式,我们可以更好的让功能详述文档的逻辑内容变得更加易读清晰,也进一步保证了设计人员的理解和硬件翻译没有歪曲。



制定验证计划

验证计划是为了完成验证目标的,因此它本身就是去回答两个两题,验证对象是谁?以及如何去验证它?对于制定验证计划的主体,不同公司可能会有不同的情况,例如公司A中是由系统人员来制定验证计划的,而公司B是验证人员来制定验证计划的。不过可以肯定的一点是,在最后回顾验证计划的时候,我们会将系统人员、设计人员和验证人员组织到一起一同来回顾,检查可能存在的验证漏洞。验证计划也是存在颗粒度的,是跟模块大小、处在系统什么层次相关的,这里我们仍然拿出模块M来举例,考虑我们验证计划中需要的检查事项:

  1. 验证方法:是采用直接验证、随机约束验证、形式验证还是其它的方式。

  2. 验证工具:选择需要的验证工具来支持验证方法。

  3. 验证完备标准:量化出一些参数可以衡量验证任务是否完成。

  4. 验证资源:包括人力、时间、硬件、软件等所有跟项目预算有关的内容。

  5. 验证的功能点:需要给出验证的功能点,以及在什么层次去验证它,更具体的包括生成何种激励,检查设计的何种状态和数据输出。



开发验证环境

验证环境的开发应该是验证人员花费时间最多的部分了。验证人员会从搭建搭建开始,经历激励产生器(stimulus generator)和参考模型(reference model)的设计,而后到数据比较器(data comparator)。验证环境的工作需要软件工具的支持,目前的主流仿真工具均可以对仿真验证提供广泛的支持。当然,制定验证计划的时候就会考虑采取何种验证方法,随后才去开发验证环境,不同的验证方法会决定不同验证环境的结构和使用的验证软件。而伴随着设计缺陷的发现以及可能出现的设计理念修改,验证环境也需要保持持续更新,最终同硬件设计一样趋于稳定,最后可以到达验证的下一个阶段。



调试环境和HDL文件


这里我们从Wilson 2014年的调查数据可以看到,验证人员在调试上面花的力气是最大的,因为环境的建立可能是80%的内容需要一次建立好的,而环境和HDL文件的调试确实一步步向前推进的。对于验证刚开始的阶段,验证人员调试的对象主要集中在环境的协调整合上面,一旦等到环境基本稳定,验证人员会递交测试,进行仿真验证。要知道,针对每一个功能点的验证均需要给出一个或者多个激励向量,在激励给入以后,我们会将参考模型和实际输出做比较,当发生比较错误的时候,我们需要进一步定位问题产生的原因在于:

  1. 环境是否有瑕疵

  2. 测试序列是否合理

  3. 参考模型是否遵循功能详述文档

  4. 硬件设计本身是否存在功能缺陷

在定位问题的过程中,我们一般建议验证人员先从环境着手,试图去稳定环境部分,因为这一部分是我们可以控制的,一旦让环境趋于稳定以后,我们再去定位问题是否来源于硬件设计。在最终判定设计是否存在缺陷的时候,验证人员自身需要了解设计,定位到缺陷的位置,最终提交给设计人员,得到设计人员的反馈。当设计缺陷被修复以后,我们会重复递交同一个测试用例,用例中产生的测试向量也不应该改变,如果我们使用的是随机约束方式,就应该记住上一次仿真出错的时间位置和随机种子(random seed),在后面重新递交时,应该采用同一个随机种子去产生同样的测试向量,确保外部激励的场景是一致的。这种方式采用的逻辑是,在调试过程中,应该尽量减少变量的数量,理想的情况下是只有一个变量,对于上面的场景,这个变量就是硬件设计的缺陷本身在修复前和修复后的功能表现。至于如何设定随机种子,在仿真器的用户使用文档中,我们可以找到相应的仿真传递选项和使用方法。


下次内容我们将会结束验证周期的部分,完成《验证周期(下)》。


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

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



点赞

评论 (0 个评论)

facelist

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

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

    周排名
  • 0

    月排名
  • 0

    总排名
  • 0

    关注
  • 253

    粉丝
  • 25

    好友
  • 33

    获赞
  • 45

    评论
  • 访问数
关闭

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

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

GMT+8, 2024-3-29 19:06 , Processed in 0.014148 second(s), 11 queries , Gzip On, Redis On.

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