今天偶然在群里看到有人分享了Mentor Graphics提供的一个UART的UVM验证环境代码,包含了UVM的基本使用以及进阶的UVM寄存器模型。这里也分享给大家。
今天我在有GPU的linux上执行 "nvidia-smi"命令,想查看一下nvidia 版本,但是被提示Failed to initialize NVML: Driver/library version mismatch。
此篇博客记录一下TLinux系统安装显卡NVIDIA驱动与CUDA10/11的艰难过程。
GPU:Geforce GTX1060 驱动版本:418.56 最开始打算装CUDA_10.1( nvidia与cuda需相匹配),但是在运行cuda.run后出现的用户许可证信息有问题,如图
从材料转行的IC验证工程师,材料人的一束微光,欢迎关注我,与我同行,愿你所有的努力都不被辜负。
嗨,屏幕前的你还好吗?我是不二鱼,一个不喜欢写技术博客的IC验证工程师,写这个系列,是需要很大的勇气的,因为,写得人很多,但写得好的不多,我也是如此。我一个菜鸡,敢写UVM(应该也不止UVM,我尽量把其他知识杂糅进去),我是疯了吗?至今能有比张强老师写得好的估计也没有,我之所以写,是为了促进自己进步,换了一个新的环境,使用UVM也是日常必备,所以,以写促学,写一写我眼中的UVM,也希望能和大家一起学习,相互成就,如有错误,欢迎私信我批评指正。
UVM中,component的task phase是消耗仿真时间的,各个components的task phase之间需要完成同步。只有在所有components的相同task phase结束之后,才能进入下一个task phase。
由于在工作中需要用到UVM仿真,就将自己的学习过程记录下来,写成了一个UVM学习的系列文章,文章中的绝大多数内容都来自《UVM实战》这本书,也从找了一些网上的公开资料,并从零开始搭一个UVM的验证环境,里面包含了UVM中许多功能的用法,相信能更好的帮助刚入门的工程师们理解UVM的工作机制。
Q哥在上一篇文章uvm_info高级技巧(1)中,跟大家聊了如何屏蔽那些刷屏的uvm_info信息。
UVM模型(二)之component Component与object是UVM中两个最重要的概念。 1.uvm_component中的parent UVM通过uvm_component来实现树形结
建议准备仿真软件,熟悉VCS的同学可以直接使用VCS,不熟悉的同学建议直接再win平台的Questa就行了。
就像微信的朋友圈一样,好友太多,各种微商信息、心灵鸡汤、养生谣言充斥,早已掩盖了最初的社交初衷。
UVM具有phase机制,由一组构建阶段,运行阶段和检查阶段组成。在run()阶段进行实际的测试仿真,并且在此phase中,每个组件都可以在开始时提出raise_objection和drop_objection。一旦所有组件都drop_objection,则run_phase完成,然后所有组件的check_phase执行,然后测试结束。
为了使用uvm_object方法(复制、比较、打包、解包、记录、打印等),所有变量都注册到uvm_field_*宏。
在UVM中,有几个和“name”有关的“小”函数, 如get_name(), get_full_name(), get_type_name() ,set_name ()。 长得这么像,分不太清楚啊?这都是怎么玩的?先收藏再说!
本篇文章是基于安装CUDA 9.0的经验写,CUDA9.0目前支持Ubuntu16.04和Ubuntu17.04两个版本,如下图所示(最下面的安装方式我们选择第一个,即runfile方式):
Accellera的便携式测试和激励标准提供了强大的验证功能,这些功能并不能代替UVM,而是可以增加现有的验证流程。这就是便携式激励和UVM相互作用的方式。
uvm_config_db机制支持在不同的测试平台组件之间共享配置和参数。用名为uvm_config_db的配置数据库启用该功能。任何测试台组件都可以使用变量,参数,对象句柄等填充配置数据库。
UVM提供了丰富的基类库和验证方法学,并且被主流的EDA工具、IP供应商和设计公司采用。现在,使用SystemVerilog基本上等同于使用UVM验证。
版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。
UVM模型(六)之uvm_component与uvm_object乐闻 为什么UVM中会分成uvm_component与uvm_object两大类呢? 自古以来,人类在搜索世界的时候,总是在不断的寻找规律,并且通过所寻找到的规律来把所遇到的事物,所看到的现象分类。因为世界太复杂,只有把有共性的万物分类,从而按照类别来识别万物,这样才能大大降低人类认识世界的难度。比如世界的生命有千万种,但是只有动物和植物两类。遇到一个生命的时候,我们会不自觉的判断它是一个动物还是植物,并且把动物或者植物的特性
virtual sequence是控制多个sequencer中激励生成的序列。由于sequence,sequencer和driver集中在单个接口上,因此几乎所有测试平台都需要virtual sequence来协调不同接口之间的激励和交互。virtual sequence在子系统或系统级别的测试台上也很有用,可以使单元级别的sequence以协调的方式运行。下图从概念上展示了这一点,其中virtual sequence具有三个sequencer的句柄,这些sequencer连接到driver,以连接到DUT的三个独立接口。然后,virtual sequence可以在每个接口上生成subsequence,并在相应的subsequencer上运行它们。
为了遵循验证计划完成不同的验证任务,用户可能需要扩展原始的通用验证环境。验证过程是动态的,可重用验证环境的开发人员无法预见未来每一个corner case验证的项目需求。
如果由于超出最大时间的某些错误而导致测试无法进行,那么仿真超时机制有助于停止仿真。在UVM中,set_global_timeout(timeout)是一个便捷函数,用于将uvm_top.phase_timeout变量设置为超时值。如果run()阶段在该这个时间内之前没有结束,则仿真将停止并报告错误。
本文基于questa 10.6c平台下搭建,questa 10.6c的安装方法在此不再赘述 ,上网查找即可,点击阅读原文提供安装包(忘了分享64位版本的了,可私信)。
UVM模型(五)之factory机制 factory其实就是一个宏,当设计set_override等操作时,才有必要去理解factory机制的原理。factory机制更多的是体现在内部编程应用
UVM(十)之config机制续1 1. 省略get的config config总是set和get成对出现的。在build_phase中,要写上如下的两句话才能把pre_num_max和pre_num_min的值更新为case的设置值: uvm_config_db#(int)::get(this,””,”pre_num_max”,pre_num_max); uvm_config_db#(int)::get(this,””,”pre_num_max”,pre_num_min); 这里只有两个变量,尚且还能忍
工厂是UVM中使用的一种特殊查找表,用于创建组件或事务类型的对象。使用工厂创建对象的好处是,测试平台构建可以在运行时决定创建哪种类型的对象。因此,一个类可以用另一个派生类替换,而无需任何实际代码更改。为确保此功能,建议所有类都在工厂注册。如果不注册到工厂,则将无法使用工厂方法::type_id::create()构造对象。
UVM testbench 是使用SystemVerilog(动态)类对象与SystemVerilog(静态)接口和结构化层次结构中的模块交互构建的。层次结构由功能层组成,testbench 的中心是被测设计(DUT)。
想象一种具有飞行能力的people,其他people都无法飞行。people肯定不想他们跳下悬崖摔个稀巴烂,才发现自己不会飞。所以在从悬崖跳下去之前,需要预警确保该people是否具有飞行能力。
testbench分析部分的第一个任务是监测DUT上的活动。和driver一样,monitor也是agent的组成部分。类似于driver组件,执行的也是实际信号活动和该活动的抽象表示之间的转换(接口上的信号变化翻译成环境中的transaction)。Monitor和Driver之间的关键区别是Monitor总是被动的,不驱动接口上的任何信号。当agent处于passive模式时,Monitor仍将执行。
UVM中的configure机制用来将一些对象(objects)和数据(data)传递到验证平台中的各种组件。
UVM 是 Universal Verification Methodology 的缩写,即通用验证方法学。它起源于 OVM(Open Verification Methdology),是由 Cadence, Mentor 和 Synopsys 联合推出的新一代的验证方法学。
sequencer产生transaction,而driver负责接收transaction。
典型的基于UVM 的验证平台(Testbench)通常会实例化DUT和UVM Testcase,以及完成DUT和UVM Testcase之间的链接。其中Testcase中的内容可以根据“静态”和”动态”两方面进行分类。
嗨,屏幕前的你还好吗?我是不二鱼,一个不喜欢写技术博客的IC验证工程师,写这个系列,是需要很大的勇气的,因为,写得人很多,但写得好的不多,我也是如此。我一个菜鸡,敢写UVM(应该也不止UVM,我尽量把其他知识杂糅进去),我是疯了吗?至今能有比张强老师写得好的估计也没有,我之所以写,是为了促进自己进步,换了一个新的环境,使用UVM也是日常必备,所以,以写促学,写一写我眼中的UVM,我希望将自己在工作当中遇到的困惑和思考,和大家分享。也希望能和大家一起学习,相互成就,如有错误,欢迎私信我批评指正。
在UVM testbench开始发送激励之前,必须构建其组件层次结构以及验证组件之间的连接关系。
UVM库定义了一组基类(base classes),这些基类有助于搭建模块化/可扩展/可重用的验证环境。
UVM模型(四) 1.常用到的uvm_component uvm_driver:所有的driver都要派生自uvm_driver。driver的功能就是向sequencer索要sequence
目录 前言 老黄和他的核弹们 开发环境一览 显卡驱动安装 下载驱动 禁用nouveau 安装驱动 安装CUDA8.0 参考 最后 ---- 前言 在Linux下安装驱动真的不是一件简单的事情,
设计可重用testbench的关键原则之一是使其尽可能可配。这就意味着testbench及其组成部分可以很容易地重用和快速修改(即重新配置)。在testbench中,有任意数量的值通常可以写成文本值,如for循环次数、字符串名称、随机权重、其他约束表达式值和coverage bin值。这些值可以用SystemVerilog变量表示,可以在运行时设置(和更改),也可以用SystemVerilog参数表示,但必须在elaboration时设置。由于它们提供的灵活性,应始终在可能的情况下构建存放这些属性的配置对象并使用 uvm_config_db API 访问。
在UVM中为了避免进行层次化操作信号,引入virtual interface,提高代码的复用性。
四十多年前,设计师从门级(gate-level)设计转向RTL设计,这种转变主要是由Verilog/VHDL RTL编码标准以及可用的RTL综合和实现工具支持的,其带来的好处是设计人员可以将更多的精力放在周期级(cycle level)行为设计上,不需要考虑太多门级因素。
UVM中的phase,按照其是否消耗仿真时间($time打印出的时间)的特性,可以分成两大类,一类是function phase,如 build_phase、connect_phase等,这些phase都不耗费仿真时间,通过函数来实现;另外一类是task phase,如run_phase等,它们耗费 仿真时间,通过任务来实现。给DUT施加激励、监测DUT的输出都是在这些phase中完成的。在下图中,灰色背景所示的是task phase,其他为function phase。
考虑构建一个用于验证SPI主机DUT的testbench作为模块级testbench的一个例子。在这种情况下,UVM环境有两个agent—APB agent在其APB从机端口上处理总线传输,以及SPI agent在其SPI端口上处理SPI协议传输。整个UVM验证环境的结构在框图中进行了说明。让我们穿过testbench的每一层,并描述它是如何从上到下组合在一起的。
在UVM中,我们不应该一直使用new()构造新的components和transactions,而应该从某个查找表中申请创建新的components和transactions,这种创建方式称为factory机制。
UVM产生激励是通过sequence sequencer以及driver三者配合实现的。生成激励的flow的框架是围绕sequence构建的,但是生成数据流使用sequence_items作为数据对象。由于 sequence_items 是构建sequence的基础,因此在设计时需要注意一些问题。Sequence_item的内容由driver在pin一级的时序决定的;通过支持随即约束,sequence item能够更加简单地生成新的item;此外,还包括了其他参数如用于分析的回调钩子。
UVM testbench对象不能直接连接到DUT信号来驱动或采样。driver和monitor组件对象与DUT之间的连接是通过一个或多个具有静态信号端口的BFM组件间接实现的。这些BFM组件以module或interface的形式实现,为了完成到UVM monitor或driver组件类的连接,我们使用虚接口句柄来引用静态接口的内容。
首先介绍一下generate的用法,generate用于减少verilog的重复语句,批量进行操作。
领取专属 10元无门槛券
手把手带您无忧上云