| ||
那么进入到更深的开发层面,Pangu是如何开发的,需要哪些知识技能和商业资源呢?从下面这张图可以看到,Pangu的脚本开发离不开一些底层资源,它们包括:
uTB common package:这包括了uTB master、uTB slave、uTB command等公共类的定义实现。
可用的VIP资源:商业VIP或者自研发的VIP。
HAS(Hardware Architecture Specification):硬件结构描述文档,该文档随着DUT的不同而不同,verifier需要从该文档中提取必要的输入参数交给Pangu。
在Pangu有了上面这些静态的和动态的底层资源之后,就能够生成不同结构的uTB。
从具体实现层面来看,使用Pangu时需要如何操作呢?Pangu脚本本身的结构如何?从技术层面上而言,Pangu的数据结构解析、操作、逻辑和用户界面由Python/tkinter实现,而文件自动化生成则是由Python/Mako来实现。关于基于Python的Tk和Mako用户可以在下面的网址中得到更多的信息。
https://wiki.python.org/moin/TkInter
对于基于Python的用户界面编程和模板语言,开发者实际上有更多的选择,而Pangu开发的原则则是尽量选择简单地、稳定地、易学习和维护的开发库,毕竟好的木匠和好的瓦工专业有很大的差别,但选择一款足够开发的Python库,将我们需要的特性都能实现,就达到了开发一款工具的目的。
从Pangu的使用流程来看,用户可以通过GUI界面方式、或者表格(或文本)的方式将必要的结构信息作为验证环境参数给入Pangu,继而Pangu会将这些参数解析为内在的数据形式DataPool。在拥有了必要的数据信息之后,各个模板部分(配置模板、环境模板、寄存器模型模板和测试用例模板)会从中心化的数据资源中提取需要的数据,再结合各自以后的Mako模板,在顶层的模板生成调度器(main template generator)的控制下生成所有需要的uTB文件。
在设计验证参数、Pangu Python脚本和Mako模板的帮助下,生成的uTB文件可以覆盖下面的内容:
所有需要的VIP资源的链接
寄存器模型文件
uTB顶层环境文件,它例化了各个uTB master、uNet、uTB slave、register model和VIP agent,完成了它们之间的TLM接口连接,同时还例化了virtual sequencer,将各个VIP的sequencer传递到给组件。
结构化的配置文件,它包含了各个uTB中组件的配置对象,协助中心化的功能配置。
基本的测试文件,例如设置时钟、发起复位、访问寄存器、读写数据的基本测试用例会相应生成,供读者参考。而为什么可以直接生成基本测试用例,这与测试用例的复用离不开,我们将在下面的部分介绍。
自动连接的testbench,将DUT同各个VIP interface连接。
makefile脚本。该脚本提供了DUT、TB的编译和测试用例的调用命令,还包括覆盖率收集等后期应用。
在开发Pangu脚本和uTB测试平台结构原型的时候,这两者之间存在既是独立开发,又是有开发节点的依赖关系。首先,只有在前期可以证明uTB的结构化和可行性,才能够接下来开发Pangu脚本。而当Pangu脚本开发到一定的时间节点,又可以利用Pangu来生成更多与DUT相关的uTB,从而在反向来证明uTB结构的合理和适用,而在Pangu使用的过程中也可以从用户那里得到反馈,进一步修改uTB的结构和Pangu脚本。
因此Pangu同uTB之间是一个相互依赖和促进的关系。下面的这张图给出了Pangu开发和uTB自动化测试平台的层级关系:
在最底层,uTB指令集和uNet通信网络构成了测试标准化的基础,而Mako模板和HAS参数则用来生成结构化的uTB环境。
在上一层中,商业VIP、自开发VIP、和用户自定义的VIP用来提供底层的驱动组件。
通过生成的uTB和复用的VIP,更高一层的中心化配置方法和由通用测试指令构成的测试用例实现了uTB环境的灵活配置和测试用例的标准化。
基于底层的这些资源,Pangu便可以自动生成uTB。
谢谢你对路科验证的关注,也欢迎你分享和转发真正的技术价值,你的支持是我们保持前行的动力。