【DVCon-US-2020】基于UVM的集群级测试平台的硬件加速

简介: 【DVCon-US-2020】基于UVM的集群级测试平台的硬件加速

论文概述


 本文题目是 Hardware Acceleration for UVM based CLTs,作者是Intel和Synopsys的印度工程师,发表在DVCon2020上,提出了一种基于UVM的集群级测试平台(CLT)的硬件加速方法。




研究目的


 随着SoC设计复杂度的提升,完备验证变得越来越难。尤其是对于Cluster级别的仿真,仿真跑得是真慢啊,一个仿真要仿到天荒地老。是的,本文的目的:仿真加速。




新方法


方法提出


 由于emulation平台对UVM支持上的限制,基于emulation的加速方法不能直接应用于使用了UVM的CLT验证平台。通常在emulation平台上跑RTL及C++的验证平台。


 考虑到在IP / Sub-system / SoC级别已经基于UVM做了很多验证工作,复用之前的case需要用软件平台跑仿真, 我们承担不起Cluster级软件仿真的巨大耗时。想要跑得快,就需要用到emulation平台,就需要用C++把UVM那一套重新实现一遍,重复造轮子,费时费力还不一定能造好。怎么办?


 本文提出了一种兼容UVM和emulation的方法,稍微花个一两周改一改UVM的环境,用simulator和emulator进行软硬件协同仿真。对于较小的case,仿真速度有3~5倍的提升;对于较大的case,仿真速度能够提升20倍以上。


 新方法:simulator+emulator软硬件联合仿真。UVM部分在simulator上跑,RTL部分在emulator上跑。示意图如图1。


35bee40ab6084a0588320c126aed1e9c.png


图1 CLT setup in Simulator Accellerator



方法实现


 对原有环境的修改:


  1.    DUT coding方式要支持emulation。既有的部分RTL在simulation中是没问题的,但部分写法对emulation不友好,需要修改。(本文未举例,我没玩过emulation,不太清楚。)


  1.    确定哪些设计是要放在emulator上跑。一般是指定hierarchy,某hierarchy以下全部部署在emulator上跑,其他的放在simulator上。


  1.    在正式编译和仿真之前,确保完成以上加速更改后CLT在simulator上仍然是可行的。确保相关问题已经debug过且fix已经合入,不要等到我CLT上再发现低等bug,我这时间可耗不起。


  1.    simulator仿真验证差不多后,对应RTL就要作为model应用到加速平台啦。



 采用以上方法对功能进行验证后,大概能提速4、5倍,但这似乎还不够,需要进一步提升model的性能。之前的CLT在配置的时候是用于simulation的,多多少少对emulation不太友好,因此可以稍微修改以下, 进一步提升model性能:


  1.    优化HW/SW接口。simulator和emulator的软硬件接口中,存在一些“冗余”的port,导致了额外的软硬件同步开销,因子可以进一步清理这些port。这一步大概可以提升3倍性能。


  1.    在emulator中产生clock。在常见simulation环境的时候,往往是在软件这一侧生成clock然后传递到硬件(图2)。这样硬件在工作的时候,每次都会产生一个时钟同步时间,极大影响效率。因此,建议把生成clock的事情让emulator来做。


  1.    第2步中把clock生成放在emulator中,这就导致了一个新的问题,就是软件在用clock的时候需要跟硬件做同步,这同样会影响性能。因此,需要在硬件侧做些逻辑,把clock传到SW侧,来减少同步及其对性能的消弱(图3)。


ebe1421546984d0e995d52fdb3e1a195.png


图2 Clock setup in traditional simulation

bab8a2378e1e43e49afb3e6e036f0e27.png


图3 Clock setup in simulation acceleration




 这样一来,对于长时间的仿真而言,仿真加速大概有20倍。




讨论


 采用本文所述仿真加速的方法,能够提供波形、断点、单步调试、TB/DUT同步调试等debug能力,跟传统的simulation相差无几,仿真速度还快。


 这个方法也有缺点:


   simulation支持增量编译,放在emulation中就不支持增量编译了,改点东西就要全部编译;


   本方法采用了信号级加速,采用这种方法不需要对 CLT 环境进行任何类型的重新设计或更改,但同时引入了SW/HW port上信号同步的开销,使得仿真无法达到最大性能。为了进一步提升性能,可以采用事务级加速,利用事务器task/function来驱动DUT。事物级加速能够减少SW/HW的接口信号数量,从而减少同步开销。 事物级加速请移步另一篇文章 DVCon2020】以接口为中心的软硬件协同SoC验证仿真加速



 本文集UVM与emulation与一体,方法是个好方法,值得一试。






目录
相关文章
|
15天前
|
Kubernetes 测试技术 Perl
混沌测试平台 Chaos Mesh
混沌测试平台 Chaos Mesh
34 1
|
1月前
|
传感器 数据采集 监控
LabVIEW电池管理系统测试平台
LabVIEW电池管理系统测试平台
29 4
|
7天前
|
运维 Kubernetes 监控
|
2月前
|
人工智能 分布式计算 DataWorks
首批!阿里云 MaxCompute 完成中国信通院数据智能平台专项测试
2024年5月31日,在中国信通院组织的首批数据智能平台专项测试中,阿里云数据智能平台解决方案(MaxCompute、DataWorks、PAI)顺利完成测试。
166 5
首批!阿里云 MaxCompute 完成中国信通院数据智能平台专项测试
|
14天前
|
分布式计算 大数据 Hadoop
最快方式搭建docker大数据 测试集群
【8月更文挑战第5天】快速搭建Docker大数据测试集群可采用预构建镜像与Compose文件、利用云服务如AWS的ECS、自动化工具如Ansible或参考在线教程。只需简单配置如内存分配及路径,运行`docker-compose up`即可启动含NameNode、DataNode等组件的Hadoop集群。根据需求与资源选择合适方法。
|
1月前
|
传感器 存储 数据采集
LabVIEW阀性能测试平台
LabVIEW阀性能测试平台
24 0
|
2月前
|
消息中间件 Kubernetes Kafka
AutoMQ 自动化持续测试平台技术内幕
Marathon 是一个针对流系统 AutoMQ 的自动化持续测试平台,旨在在模拟生产环境和各种故障场景中验证 SLA 的可靠性。设计原则包括易拓展、可观测和低成本。平台采用分布式架构,Controller 负责资源管理和任务编排,动态调整 Worker 数量和配置,而 Worker 是无状态的,用于生成负载和上报数据。系统基于 K8S,利用服务发现、事件总线和 Spot 实例降低成本并提高弹性。测试场景以代码形式描述,支持不同流量模型和断言,提供丰富的可观测性和告警功能。未来,Marathon 有望泛化为适用于各种分布式系统的测试平台。
38 0
AutoMQ 自动化持续测试平台技术内幕
|
2月前
|
jenkins Java 测试技术
电商返利平台的测试与持续集成
电商返利平台的测试与持续集成
|
2月前
|
分布式计算 Shell Linux
Spark-集群安装、部署、启动、测试(1.6.3)稳定版
Spark-集群安装、部署、启动、测试(1.6.3)稳定版
43 0
|
3月前
|
数据挖掘 测试技术 网络安全
LabVIEW开发卫星测试平台
LabVIEW开发卫星测试平台
39 3

热门文章

最新文章