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

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

日志

我跟你谈SV接口类,你却以为我跟你谈接口?

已有 3624 次阅读| 2018-6-14 21:27 |个人分类:验证前沿资讯|系统分类:芯片设计

这个话题已经积郁在胸口很久了,然而各种事情每天都在侵占着路桑的大(ling)脑(hun),关于接口类(interface class)的介绍和应用一拖再拖,直到今天无意间翻出一篇很好的文章,来自于ARM公司Stan Sokorac。

SystemVerilog Interface Classes - More Useful Than You Thought (2nd place best paper award)


在发表这篇论文的时候,他已经是ARM的senior principle...看了他的LinkedIn,虽然在论文上面不多产,但是他的另外一篇,也是我特别想介绍的,就是2017年US DVCon的最佳论文。

Optimizing Random Test Constraints Using Machine Learning Algorithms (1st place, best paper award)


从他的计算机工程背景和技能树来看,做验证如果想要突破,必须得从软件开发入手,重新学习设计模式,继而在UVM的结构平台上面做定制化开发,不然也只能吃UVM标准的套餐了。Stan Sokorac先生已经从ARM离职,到一家Tenstorrent开发深度学习处理器去了...不得不说,SoC模式限制了我的想象力啊。


接下来那我主要就Sokorac先生的这篇论文来谈接口类在验证平台中的实践


概述

interface在SV中已经被“接口”即通信连接所指的语义所占领了。而在软件世界中,例如Java、C#、Swift、D等语言都支持另外所指的interface软件编程方式。所以诸君请对这篇文章中的interface(接口)加以辨别,即我们会谈到SV标准中的interface class的用法。不过由于接口类的概念是在SV 2012标准中提出,而在OVM、UVM的标准制定已经更早,因此SV与UVM在这一有用的接口类推广上面失之交臂。


实际上,这一影响要更加深远,由于缺少UVM标准的助力,而大多数verifier又直接面向UVM而非SV的验证平台,所以接口类这一新的特性并没有被很好地推广开来,甚至被低估或者不被喜爱。而对于习惯软件思维模式的资深verifier,例如Sokorac先生,接口类简直是任其在UVM接口中冲浪的帆板,别提多自由了。我们有幸得到这份非常高质量而又语言简明易懂的论文,可从中窥得ARM公司在处理器验证时的一些定制化使用方式。


实际上路桑所在的公司也有基于UVM深度定制的一些验证平台和软件包,其中一些已经在或者将在DVCon、SNUG这些会议中发表,一些仍然还身处深闺人未识。有兴趣的童鞋,可以在路桑的个人网页下载路桑以及其它的优秀论文。路桑的个人网址如下:

www.rockeric.com



接下来路桑将参考论文,给出四种接口类的典型使用方式。尽量取其精华(实际上全部都是精华,很难再分割摘取),使诸君认识或者重新认识接口类的蓝筹地位,也希望好学的童鞋可以下载此文,多加阅读几遍,在接下来的大型UVM结构模式中,如果你发现uvm_event或者uvm_analysis_port的使用让你代码增多、维护变得繁重的时候,希望你可以想起来还有接口类这样一种清爽的框架实现方式。


A. 观察者(subscriber)模式

在以往monitor检测到数据需要发送至各个checker或者scoreboard,甚至多个的情况下,需要进行如下操作:

  • 在更高层环境的connect阶段就确定连接关系,即monitor(publisher)与其它收听组件(listener)的关系,例如checker或者scoreboard。

  • 在连接时,需要使用uvm_analysis_port完成“一对多”的数据传送要求,并且在各个收听组件侧,需要实现相应的write()方法



不过这样做也有一些限制,例如对于由SV而非UVM搭建的测试平台无法很好地实现一对多的数据传送,同时由于连接关系是“静态”的,使得无法在run的阶段随时添加数据传送管道,并且也只有uvm_component才可以参与到TLM端口连接关系当中,因此如果是sequence与test或者driver之间发生事件控制的订阅关系,那么sequence只能通过其p_sequencer延伸到组件层次关系,再利用p_sequencer与其它组件完成通信,非常地掣肘。


另外一个不方便的地方在于,每次通信只能先于一种单一的事务,如果想要传递两个以上不同种类的事务,则需要将一个事务作为成员,封装在另一个事务中,也不方便,所以这是由于write()方法的单一参数所带来的不便。


那如果我们使用了接口类,世界会不会变得有序而灵活呢?来看下面这个例子,首先声明一个接口类resolve_listener,接下来,所有需要从monitor接收数据的组件在定义时,需要使用声明“implements resolve_listener”,即表示它们的定义中会实现new_resolve()方法,即处理从monitor接收到数据的方法。那么monitor呢?它只需要将所有的listener声明为队列m_resolve_listener[$],因为它也不知道会有多少个监听它的组件,而在run阶段,当它每次广播的时候,它就会利用foreach每次轮询调用各个监听组件的new_resolve()方法。




那么monitor与所有监听组件例如resolve_checker的联系发生在哪儿呢?

  • 凡是监听组件创建时,需要调用m_config.monitor.add_listener(this),添加其到monitor的广播列表里

  • 凡是monitor在广播时,将会对收听列表中的所有组件一一广播其事务arm_txn_resolve。


再来看,通过接口类实现了什么帮助呢?

  1. 不再依赖于UVM的uvm_analysis_port,即在任何SV环境中都可以完成一对多的广播-收听(publish-listen)软件设计模式。

  2. 不再要求所有的连接需要发生在UVM的connect阶段,也不需要广播方或者收听方必须是uvm_component,这大大提高了实现便利性,脱离了UVM的组织结构限制。例如sequence与test或者driver可直接实现通信,不再需要间接通过sequencer来周折完成。

  3. 对于广播的方法,不再限定于其内容和参数个数,因此当需要传递多个参数时,利用接口类将比TLM传送事务更加方便。


B. 伪多继承(pseudo-multiple-inheritance)

SV无法直接实现多继承,使得不少从specman或者软件世界迁移过来的人产生遗憾。多继承是AOP的典型特性,可以查看我们之前的一篇文章:

OOP(面向对象)的硬件设计思路就够头疼了,还搞什么AOP?


这篇文章中提到了在处理器的指令验证中,难免有一些“复合”指令,即C指令的特性可能是由A指令和B指令的合集。例如Load、Store与DMB的类型指令是在继承树上是分开的,但是Load-Acquire(LDAR)或者Store-Release(STLR)则是由之前两种指令类型的组合



在实现LDAR的指令定义时,按照SV的局限,我们可能依然继承于Load指令,而采用代码“拷贝”的方式,将另外一部分指令代码从DMB类从完全拷贝过来,但这难免会给代码维护带来麻烦。或者也可以将它们之间的公共代码放在公共文件内,继而凡是使用到这些方法的类,例如DMB或者LDAR都采用`include的方式来完成代码编辑工作,不过这还是会让代码不那么直接,曲径通幽。


而我们可以利用接口类,将这一共同部分抽象出来,再分别由LADR和DMB指令类“implement barrier”,并实现预定义的方法。对于LADR,它的定义形式则变为了“class ladr extends load implements barrier”,实现了从分别继承于load和barrier的目的。





点赞

评论 (0 个评论)

facelist

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

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

    周排名
  • 0

    月排名
  • 0

    总排名
  • 0

    关注
  • 253

    粉丝
  • 25

    好友
  • 33

    获赞
  • 45

    评论
  • 访问数
关闭

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

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

GMT+8, 2024-3-29 14:02 , Processed in 0.016649 second(s), 12 queries , Gzip On, Redis On.

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