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

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

日志

基于快速启动软件驱动的硬件验证框架

已有 955 次阅读| 2016-7-31 16:32 |个人分类:验证前沿资讯

软件驱动硬件验证在当今复杂的SoC开发中变得越来越重要,硬件验证效率已经从像UVM这样验证框架中受益匪浅,但是在嵌入式软件驱动测试中, 还没有这样的框架来提高效率。本文介绍有SVF这样一个框架的好处,并提出了验证框架(针对软件驱动的硬件验证)的关键特性和基本组成。


一.  软件驱动验证面临挑战

对于一个软件驱动的验证环境来说,创建的测试被期望在各种环境下都能运行,而大多数其他测试,无论是面向软件或硬件,都旨在能在一种,至多两种环境下运行即可。软件驱动测试通常需要在虚拟模型中运行,像在RTL仿真,加速RTL仿真,FPGA模型,以及首次硅中,而这些环境有根本不同的性能和显著特点。

一个软件驱动的验证方法中,测试与设计的软件部分一起执行,而这是一个挑战,因为测试的执行可以改变设计的软件部分的执行过程,例如,发出大量的调试信息的测试可能会减慢驱动软件的执行,从而导致假故障或掩蔽与硬件驱动集成相关的问题。


二.  软件驱动的验证框架主要组成

我们提出的方案能缓解上面提到的挑战,下面我们介绍一下我们的验证框架,其中描述的部件借鉴了OVM和UVM组件模型和环境建设概念,以及SystemC的知识。


A. 组件模型

SVF所使用的组件模型大量借鉴了UVM库中的组件模型,组件实例有实例名,组件结构有层次,有关联,并通过三个步骤启动:

  • 建立: 在对象的层次结构中构建组件

  • 连接: 在对象的层次结构中连接组件

  • 启动: 载入任何所需的线程


图1显示了SVF组件模型的一个例子。在这个例子中,consumer组件调用get_data()从producer组件获取数据。

  • 在顶层组件中通过build()实例化 producer和 consumer 组件,并且底层组件的build()方法都在顶层build()方法之后执行。

  • 当所有build()方法执行完之后,顶层组件的connect()方法就开始被SVF 库调用了,在这个时间点上,所有子组件都保证构成,所以consumer可以连接到producer。

  • 最后,每个组件的start()方法开始执行,在这个case里,只有 consumer 组件需要启动一个线程。


B. 抽象通信

一些现有的框架提供API接口,虽然一定程度给用户增加了复杂性,一个软件驱动的框架必须提供类似的方式以让组件可以导出API,再被别的组件使用。SVF提供了一个双向API端口,使软件模块能提供或使用API。


图2用个简单的例子(使用API端口实施中断驱动数据传输)示出了双向API端口结构。在这个例子中,组件driver实现了硬件IP块传输数据的驱动程序,多种测试程序将使IP模块传输数据,并且当传输完成后必须发出通知。组件 transfer_gen使irq_if API生效,当传输完成时,组件transfer_gen就会被通知;组件driver使data_transfer_if API 生效,使得 transfer_gen 可以请求传输数据。当传输完成后,通过hw_irq()方法,组件driver通过调用连接组件的irq_event()方法告知组件transfer_gen。


C. 线程基体

如今,软件帮助验证复杂的系统,几乎都是多线程的。SVF框架提供面向对象的线程基体,库提供线程API的几个实现是:

  • 与ARM内核协作的裸机(Bare-metal )线程

  • 在Linux操作系统顶层运行的POSIX线程

  • 针对虚拟原型环境的SystemC线程


D. 记录

图3显示了SVF 记录框架的结构,测试代码使用log句柄发出消息,log句柄允许测试代码得到当前日志记录级别。这使得测试代码只能在当前冗余级别或以上级别生产信息。VF日志框架提供了一种机制,以预先定义消息的格式和参数,此功能显著提升了记录效率。消息是由两个数据类组成的,消息-格式数据永远不会改变,而消息-参数数据会变,它们被分别定义,而不是作为一个整体定义的。


E. Island-Bridging结构

软件驱动的验证环境往往比硬件验证环境中更加分散,每个处理器核可被认为是独立的,执行自主的,但可能希望与在另一个处理器核心上运行的测试活动交换数据。有一个通用的通信方式是有益的,不管是源或者传输目的地数据,也不关心数据实际上是怎么传递的。SVF桥结构提供了用于基于消息的多通道,双向通信的方法,其结构如图5所示,在这个例子中,嵌入式软件环境里的一个桥(bridge)和运行在主机工作站环境上的一个桥(bridge)通信,一个桥管理多个消息渠道。

不同的桥方案支持不同类型的测试平台环境的通信,下面列出了一些桥方案:

  • 基于仿真器的共享内存桥,在仿真中连接主机和嵌入式软件。

  • 仿真内存处理桥,运行在仿真器上,连接主机和嵌入式软件。

  • Unix插槽桥,连接主机工作站和基于以太网的连接,以及嵌入式软件环境。


三.  结果

软件驱动的验证框架不必是资源密集型的。目前SVF实现相当轻巧,编译一个32位的ARM目标仅仅需要大约16KB,相比之下,GNU libc实现 printf 就要消耗8KB,这使得 SVF可以被用在所有资源最受限的系统中。


四. 结论

验证框架对与提高硬件验证工程师的效率至关重要,通过简单的重用验证组件和IP,通过集成自动化工具到测试平台环境;嵌入式软件驱动验证在SOC验证中也越来越重要,验证框架主要致力于解决这方面挑战,即软件驱动硬件验证可以提供类似于UVM的便利,通过提供预建的基础库来创建部件,提取部件之间的通信,以便复用。这种在基础层次的复用技术和方法确实可以在软件驱动的硬件验证中提高效率。



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

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


Jump-Start Software-Driven Hardware.pdf(88.5 KB)


点赞

评论 (0 个评论)

facelist

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

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

    周排名
  • 0

    月排名
  • 0

    总排名
  • 0

    关注
  • 253

    粉丝
  • 25

    好友
  • 33

    获赞
  • 45

    评论
  • 访问数
关闭

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

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

GMT+8, 2024-4-25 13:11 , Processed in 0.022861 second(s), 11 queries , Gzip On, Redis On.

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