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

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

日志

为什么我的SystemVerilog测试平台如此慢?

已有 1993 次阅读| 2016-11-6 21:32 |个人分类:验证前沿资讯|系统分类:芯片设计

(一)硬件工程师编码的性能
对于转到SystemVerilog编码的任何工程师,最重要的一点就是要问“当规模变大时,它依旧能快速运行吗?”。这是指导原则,它能促进高效的初始编码,并能在性能分析过程中快速地调试发现的性能问题。
  • 循环不变性
循环不变性是指循环里的程序每次都执行,但值却不发生变化。移除循环不变性潜在的好处决定于不变性算法的复杂度,循环体,以及循环里的周期数。

下面两段代码,第二段要比第一段执行得快,因为循环条件里边界值之前已经被计算:l_end = length * count,而第一段代码每次循环都有计算length*count,降低了速度。
  • 短路加速
一个常见的编译器优化是执行分支条件数量最小就做出判断。比如下面两个条件语句:
第一个条件语句只要判断到任何一个term为1,就能知道条件成立;而第二个条件语句则要确定三个term都为真,才能判断条件成立。

先后顺序也很重要,再看下面这段代码,虽然功能上正确,但执行起来会很慢,原因就在于条件里排序不对,应该将nearly_everytime()这种发生频率高的放在最前面,而不是最后面。
  • 重视宏
毫无疑问,过量的使用宏会造成问题,包括富有挑战性的调试和代码扩展(消耗内存),但适量地使用可以大大加速循环计算。下面的例子中,reverse()函数在所有1百万个数据点被调用,每次调用所需的堆栈帧可能影响缓存命中(当循环代码和数据工作在cache memory里时,仿真执行最快),从而显著减慢仿真。而宏版本运行速度更加迅速。
  • 重视静态类
静态分配是面向对象扩展到宏的总体规划概念。宏替代了分级执行流程,静态类取代动态产生类。同一组类反复被newed(分配内存)和de-allocated(释放内存),仿真器通过内存管理反复循环,而如果是静态定义的类,仿真的整体内存占用保持一致,但执行速度会增加。

(二)减负以变快
内存可能是减慢速度的最大神秘来源,在硬件上,最大的内存问题是建模物理内存和内存占用通常是非常明显的,然而在SystemVerilog TB里,这可以被隐藏。

  • 性能取决于掌握完整的继承层次
数据对象应该只能通过一种API方法获得,以避免意外的访问;接口应该被用来清晰地界定API,以便冗余结构并不在子类中加入;通过仔细研究
基类和规划派生类,可避免与隐藏数据相关的问题。
  • 丢失的句柄使性能下降
丢失句柄是暗藏险机的,如果一个数组的计数范围被置错,那句柄就不能正确地被清除,因此建议在代码里加入检测器以监视溢出。全局数组是尤其危险的,因为多个进程都可能对其操作,以产生不期待的效果。工程师通常会规划创建这些SystemVerilog对象,但同时要规划销毁它们。
  • 最好让数据和进程一直都在
有一个进程是创建,销毁,回收数据对象,除了为每个数据对象请求操作系统外,执行效率取决于操作系统能不能容易地找到大小合适的内存块,全局回收可以维持更大的内存块,但是对象被创建和销毁地更多,进程工作量也会更多。另一种方案是把对象存储在保持(回收)数据结构里,而不是销毁它们。在仿真时,数百万的包被创建和销毁,然而进程操作的数量一直维持在几千而已,这种数据回收结构能给性能带来显著提升。

这里的讨论也适用于在所创建的并行线程测试平台环境。在非常大的case里,额外的接口可能需要管理线程以优化性能。
  • 谨防意想不到库的开销
像UVM库提供了方法让我们快速创建验证环境,从性能角度看,确实需要牢记类推荐的分层方法的作用。但挑战在于缩放比例,比如,如果数据包很大,但通过接口的数据流很小,和接口关联的进程必须在每个时钟周期操作,看起来没有很多代码,但问题是如此简单的进程可能通过继承关系拉动更复杂的类层次。另一种方法是让数据在突发或DMA模式下传输,内存子系统有更多方法在驱动器/监视器层使用使用时钟沿。

因此,什么时候需要使用这些标准接口库?这对于开发者和集成者来说真的是一个问题。最简单最容易入门的方法就是使用它们,然而,当团队着眼于性能时,就会基准测试环境,寻找和缩放相关的瓶颈,找更有效地算法。
  • 随机化
建立有效的约束集的主题是很大的,这有简单的代码和此主题关联。例如,在通过它们进入约束之前,预先计算值的范围将提高性能。如下所示:
(三)总结
分析器对于衡量仿真环境性能是一个宝贵的工具,硬件背景的验证工程师可能将分析器视为调试仿真器性能的工具,而软件背景的验证工程师将分析器理解为用于每几天调整他们算法的工具。简单和可重用的代码是迄今为止最好的,所有的算法都应该这样开始。然而,每个系统都有物理限制,而分析器是工具,借助它,你可以优化你验证环境性能,以使其在物理限制范围之内。

本文中的案例将被张贴在UVM世界共享区域,使得整个社区可以加速他们的SystemVerilog仿真。


点赞

评论 (0 个评论)

facelist

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

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

    周排名
  • 0

    月排名
  • 0

    总排名
  • 0

    关注
  • 253

    粉丝
  • 25

    好友
  • 33

    获赞
  • 45

    评论
  • 访问数
关闭

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

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

GMT+8, 2024-5-8 13:45 , Processed in 0.015704 second(s), 12 queries , Gzip On, Redis On.

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