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

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

日志

跨平台移植复用篇之二:PSS工具集概览(上)

已有 1787 次阅读| 2018-6-10 13:43 |个人分类:验证系统思想|系统分类:芯片设计

在上一节我们提到过,主要的EDA厂商都开始了在PS这一个可能带来下一代行业验证效率提高和测试标准统一的方向上面布局。本节将为读者带来目前主要的PS工具,和它们提供的特性。首先,我们还需要进一步了解portable stimulus的概念和层次设置。无论对于SV/UVM的测试用例,还是系统级C的测试用例,verifier们关心的层次仍然是transaction level。transaction level是将一系列相关的事件结合到一起,构成一个在更宽泛时间意义上的大事件。例如一次寄存器的访问、一个数据包的传输。而PS将继续拔高这个传递的抽象级,因为它不想要拘泥于某一个特定VIP的控制,或者某一个寄存器的访问,而是想要在更高的层面完成操作,譬如一次将DMA寄存器配置为从memory搬运数据到另外一侧、又比如发送多少的数据量,而不关心这些数据量是花了多少时间来完成的。在这一层面上的操作,我们称之为scenario level。


例如下面这张图中,从测试的起点开始,我们可以看到一些scenario level(SL)不同于transaction level(TL)的地方:

  • SL中每一个元素更易读和维护。

  • SL中每一个元素应该包含更具体的TL操作,譬如一系列寄存器的操作和数据的传输。

  • 下图中的单个SL元素被称为action。借助于更高的抽象级,action的跨平台复用性更好。在实际中,不同的action也需要不同的输入和输出的数据和控制逻辑(下图中未标记)。

  • 一个scenario则是由一系列的action构成,同时action之间的跳转也需要数据流的调度限制。譬如modem receive何时跳转到DMA Xfer或者跳转到mem copy。


下面给出一个简单的例子,来介绍使用PS来实现SL的测试需要完成哪几步。在下面的图中有UART、DMAC、MEM还有外接的Data端口和Command端口。而利用这些资源可以实现这样一个scenario:

  • UART从Data端收发数据。

  • DMA可以并发从MEM发送/获取数据。

  • Command端口可以配置UART和DMA的寄存器,也可以从MEM读写数据。


这样一个典型的子系统,在实现SL的测试之前,我们先需要为各个模块定义将来会被应用的action。

  • 对于UART,需要定义读写数据的action,read_in和write_out。

  • 对于DMA,需要定义搬迁数据的action,从UART到MEM的u2m_xfer和从MEM到UART的m2u_xfer。

  • 而在这些基本的action之上,用户可以实现自定义的组合,构建自己的action。


实际上,PS在实现中不仅仅需要action,还需要其它辅助的资源定义,例如struct,lock,share,pool等。我们不在这里介绍它们的用法,路桑相信在不久的将来还会出一个专题来介绍PS的第一版标准吧。即便是依靠action这样一个高层次的概念,读者们也可以看到,这些更大的“宏”已经封装了内部的各种细节操作和使用的语言,这就使得操作更加模块化和方便移植。模块化的特点,更使得PS语言在应用时既可以用写的方式,也可以用画的方式。为什么会有画的方式呢?因为它除了方便阅读整个场景的流程,也便于拖拽绘制测试场景。这不禁让路桑想起了另外一个很有发展潜力的“积木”语言——RobotC。如果读者有玩过LEGO机器人编程的话,会知道一种语言如果用来绘制,来间接生成代码,也是挺有趣的一件事情。


待测试的系统如果扩展为更大的SoC级别,读者可以从下面的图中看到,我们仍然需要为各个系统模块定义好action。例如CPU的write、copy和read,Graphics SS的decode。接下来就是将这些action和更多的辅助资源、逻辑控制组合在一起,创建出各个特定的scenario。


到这里为止,上面关于action和scenario的定义,都是可以用PS语言来定义的。而PS语言目前也在PSWG(Portable Stimulus Working Group)积极筹备中。语言层面上用户可以在符合PS标准层面上自定义action来实现高层次的scenario。那么,有了PSS scenario之后就到了工具层面的事情了,即PSS工具需要将PSS model转换为特定的测试代码(例如SV/UVM或者C),或者调用特定的测试代码。那么从SL到TL的映射关系,需要在PSS中指定,同时对应的TL方法(SV或者C)也需要用户定义,或者由VIP自身实现。


那么可以预见到的是,verifier们需要关注SL的这几个方面,将不同于以往的TL验证:

  • 需要适当地划分出action粒度。在VIP层面,EDA公司将会把PSS的action定义绑定到VIP中,作为库的一部分。

  • 更需要关注芯片在应用时的场景,而不是仍然局限于物理层面。

  • 由于PSS的跨平台和范测试标准的特点,RTL verifier需要同其它平台和测试开发阶段的人员形成更紧密的合作关系,一致来定义应用测试的场景,定义大家一致认可的PSS scenario。这种方式将更好地整合资源,同时避免因为缺乏沟通造成的测试场景差异,从而进一步保证验证的场景即是将来会被应用的实际场景。

  • 在验证检视回顾的过程中,将分为SL层面和TL层面的两种检查。SL检查将由验证经理、系统工程师、post-silicon芯片测试工程师来从系统层面检查,TL检查将由验证经理和其它verifier们共同检查底层实现的代码。


那么在即将建立起新的测试标准之后,还需要关注哪些方面呢?一方面将是伴随PSS跨平台特性的TB结构组成,这一点将在下一节《跨平台的验证结构考量》中介绍;另外一方面,则需要关注在新的抽象级上面的新型覆盖率有哪些?

  • action coverage:是不是所有定义到的action都执行了?

  • scenario coverage:是不是所有合法的action执行序列所构成的scenario都执行过了?

  • datapath coverage:是不是在一个datapath上面所有合法的source端和target端都涵盖了?

  • value coverage:对于可能的配置寄存器和状态寄存器组合是否都覆盖了?

  • resource coverage:对于场景中借助的辅助资源,是否也都使用到了?

  • cross coverage:这一点同SV cross coverage一致,即仍然需要将关心的cross coverage列举出来。


对于这些新型的coverage,目前的simulator或者其它平台的工具无法提供,而可以借助于PSS工具来完成监视、收集和合并。上面提到的action coverage可以映射到TL级的一些function coverage的集合;而scenario coverage则是系统层面的覆盖率,可以对SoC集成测试的验证要求。


点赞

评论 (0 个评论)

facelist

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

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

    周排名
  • 0

    月排名
  • 0

    总排名
  • 0

    关注
  • 253

    粉丝
  • 25

    好友
  • 33

    获赞
  • 45

    评论
  • 访问数
关闭

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

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

GMT+8, 2024-3-29 16:25 , Processed in 0.021759 second(s), 12 queries , Gzip On, Redis On.

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