1.[UVM源代码研究] 如何定制一款个性化的码目打印格式
2.如何跑通《UVM实战》书上的例子?
3.[UVM源代码研究] UVM的field_automation实现的print()函数如何灵活控制打印数组元素的数量
4.[UVM源代码研究] 聊聊寄存器模型的后门访问
5.[UVM源代码研究] 谈谈uvm中的浅拷贝(shallow copy)与深拷贝(deep copy)
6.UVM factory机制如何重载带参数的object
[UVM源代码研究] 如何定制一款个性化的打印格式
文章总结:定制UVM的打印格式并非直接使用默认设置,而是码目涉及到UVM类库的深入理解。首先,码目`uvm_info`等宏的码目执行过程实际上是通过`uvm_report_enabled`函数,这个函数实际调用的码目是uvm_root的单例模式下的uvm_report_object的uvm_report_enabled方法,因为uvm_root支持这种模式。码目童虎家政源码宏中的码目verbosity值会与预设阈值进行比较,同时还会检查action设置,码目以决定是码目否执行打印。打印格式的码目定制关键在于`compose_message`函数,它由uvm_report_server类定义,码目可以通过继承并重写此函数来自定义输出格式,码目比如使用`__FILE__`和`__LINE__`这些编译时指令。码目
实现个性化打印的码目步骤包括:创建一个自定义的report_server子类,重写`compose_message`函数,码目然后在测试环境中设置这个自定义的server。这样,无论执行`uvm_info`等宏,都会按照我们定制的格式显示,适用于所有四种severity(uvm_info/uvm_error/uvm_warning/uvm_fatal)。
通过上述方法,你就能为UVM的打印格式定制出符合自己需求的样式,让输出信息更加直观和易于理解。
如何跑通《UVM实战》书上的例子?
在求职过程中,面试官常会询问关于UVM实战的学习情况,特别是易语言自动获取磁盘源码是否实践过书中的例子。我最近抽空按照《UVM实战》书中的指导进行了实践,现在已经能够成功运行书中的例子。以下是关键步骤和注意事项:
首先,确保你的虚拟机上安装了VCS和Verdi工具,可以从华章网站获取《UVM实战》的源代码。在虚拟机设置中,将共享文件夹指向代码目录,以便于访问。将example_and_uvm_source_code文件夹复制到你的工作目录下。
在代码中,有两个部分需要修改。一是setup_vcs脚本,用于设置VCS和Verdi的路径。你需要根据你的实际工具路径进行调整,可能需要修改export语句格式。二是run脚本,需要添加必要的命令,如"–full",这对于位Linux系统至关重要,否则可能会遇到VCS_HOME路径错误。
为了便于debug和波形dump,我增加了dump波形相关的代码,并在top_tb文件夹中添加了输出仿真信息到test.log的命令。这样,你就可以跟踪仿真过程,安卓常用知识源码分析查找关键信息。
经过这些步骤,你应该就能成功运行《UVM实战》中的例子了。如果你觉得这些信息有帮助,请别忘了点赞支持!我是不二鱼,祝你在学习和求职路上顺利。
[UVM源代码研究] UVM的field_automation实现的print()函数如何灵活控制打印数组元素的数量
实际工作中,我们常遇到需打印包含多个数组或队列元素的transaction时,仅默认显示开始5个和最后5个元素。若需查看更多元素值或完整内容,可考虑两种方法:一是重写transaction的do_print()函数,自定义打印内容与格式;二是探索现有UVM源代码,修改相关设定以实现打印更多元素。
首先,分析can_txrx_transfer的注册方式,发现其默认仅显示特定数量的元素。通过查看源代码,发现实现打印机制的关键在于UVM_FIELD_QDA_INT宏与UVM_FIELD_UTILS_BEGIN宏的结合,它们共同调用_m_uvm_field_automation函数,该函数根据指定的what_参数(如UVM_PRINT)调用相应的打印函数。
在调用print()函数时,最终调用_m_uvm_field_automation,进一步调用uvm_print_array_int3宏。该宏通过uvm_print_qda_int4宏实现打印逻辑,体育赛事比分源码系统对静态或动态数组、队列元素的打印格式进行统一处理。在uvm_print_qda_int4宏中,定义了uvm_printer与uvm_printer_knobs变量,用于接收打印参数与配置信息。
uvm_default_printer作为全局变量,其配置决定了打印格式。在打印数组时,通过设置uvm_printer_knobs中的begin_elements与end_elements变量,可以灵活控制打印元素的数量。具体配置方法可将uvm_default_printer配置在test_base的build_phase中,实现对打印数量的精确控制。
通过上述分析,我们了解了UVM源代码实现打印机制的原理,并掌握灵活配置数组/队列元素打印数量的方法。这种方法不仅提供了更为灵活的打印控制,还能根据实际需求调整打印内容与格式,增强代码的可读性和实用性。
[UVM源代码研究] 聊聊寄存器模型的后门访问
本文将深入探讨UVM源代码中寄存器模型的后门访问实现,尽管实际工作中这种访问方式相对有限,但在特定场景下其重要性不可忽视。后门访问有助于简化验证流程,特别是在检查阶段需要获取DUT寄存器值时。
在UVM源代码中,后门访问的鹤壁客户外呼系统源码实现主要围绕write任务展开,核心方法是do_write(),它包括获取uvm_reg_backdoor句柄、等待访问权限和更新期望值等步骤。uvm_reg_backdoor类是用户自定义后门访问的入口,允许通过派生类实现定制化的访问方式。
获取uvm_reg_backdoor句柄的过程会遍历寄存器模型的层次,如果没有自定义backdoor,就会从顶层寄存器模型开始查找。在默认情况下,寄存器模型使用sv语法的DPI方式访问,但可以通过自定义类实现其他形式的访问。
源代码中的get_full_hdl_path函数负责获取寄存器的完整HDL路径,这涉及到uvm_hdl_path_concat和uvm_hdl_path_slice等结构,它们用于描述寄存器的物理信息。通过配置或add_hdl_path操作,可以在寄存器模型中存储和管理多个HDL路径,对应不同的寄存器实例。
后门读写操作会调用uvm_hdl_read()函数,它是一个通过DPI-C实现的外部函数,根据编译选项的不同,可以选择使用C语言访问HDL路径。写操作成功后,会更新寄存器的镜像值并写入实际寄存器。
总结来说,实现寄存器模型后门访问的关键步骤包括设置寄存器的HDL路径,配置单个寄存器的物理信息,并确保与HDL中的实际结构对应。需要注意的是,如果寄存器在HDL中被拆分为多个字段,需正确配置这些字段的访问路径以避免警告。
[UVM源代码研究] 谈谈uvm中的浅拷贝(shallow copy)与深拷贝(deep copy)
在探讨UVM(Universal Verification Methodology)中的浅拷贝(shallow copy)与深拷贝(deep copy)之前,我们先对相关概念进行简要介绍,以便于理解以下讨论。浅拷贝和深拷贝是对象编程领域中基本概念,不仅限于系统Verilog(SV)和UVM(Universal Verification Methodology)。
浅拷贝:这一概念涉及的是拷贝对象的指针,即浅拷贝只复制指向对象内存空间的指针,使得目标对象与源对象共享同一内存空间。浅拷贝的局限性在于当内存空间被销毁时,所有指向该空间的指针必须重新定义,否则会导致野指针错误。
深拷贝:与此相反,深拷贝确保源对象和拷贝对象完全独立,两者之间互不影响,包括内存空间内容也被复制一份。例如,基本类型如Int、Double,以及结构体(struct)、枚举(Enum)会自动执行深拷贝,而类类型的对象则需区分浅拷贝与深拷贝。
在UVM中,`uvm_object`类提供了`copy`与`clone`函数来实现对象的拷贝。
`copy`函数为非虚拟、无返回值的函数,不能被重写,但`do_copy`函数为虚拟函数,可以通过重写`do_copy`函数实现对`copy`函数的间接重写。调用`copy`函数前,目标对象需先创建,以实现源对象内部对象的深拷贝赋值,而不会对目标对象本身分配空间。
`clone`函数为虚拟函数,返回`uvm_object`类型,可以被重写。由于返回值类型限制,`clone`只能通过`$cast`来实现目标对象类型的转换,而不能直接赋值。`clone`函数返回一个指向源对象类型的`uvm_object`句柄,因此目标对象类型必须与源对象一致(通过`$cast`检查),以确保成功执行`clone`操作,且目标对象不需要事先分配空间,因为`clone`会自动分配新空间。
`copy`函数的实现中,除了`do_copy`之外的第行的`__m_uvm_field_automation(rhs, UVM_COPY, "")`完成了在`field_automation`中的配置实现。如果未重写`do_copy`函数,则所有拷贝行为依赖于`__m_uvm_field_automation`函数。
`uvm_object_defines.svh`文件在第行实现了将`copy`传入参数转换为局部变量`local_data__`,该变量类型为通过`uvm_object_untils_begin`传入的参数类型。`local_data__`在后续的`uvm_field_automation`宏中根据传入的标志位进行相应操作,以`uvm_field_object`为例。
在`uvm_field_object`中,关于`UVM_COPY`的具体操作表明,调用`copy`的源对象不能为空。如果`FLAG&UVM_NOCOPY`位为1,则直接结束代码执行。如果`FLAG&UVM_REFERENCE`位为1,或者`local_data__.ARG == null`,则将目标对象的`ARG`对象句柄指向源对象的`ARG`句柄。这种做法对于未分配空间的对象赋值,以避免错误。`UVM_REFERENCE`的应用场景主要针对`uvm_component`类型的对象注册,确保在进行`copy`和`clone`时执行浅拷贝,避免深拷贝导致的问题。
`uvm_component`类型在`copy`时默认执行深拷贝,而`UVM_REFERENCE`标志位则实现浅拷贝。例如,在`apb_env`中,`bus_monitor`和`bus_collector`被例化为`master`中的`monitor`和`collector`,同时`cfg`对象也传递给`master`。通过`field_automation`的修改,可以观察到`uvm_top`在打印树型结构时,`apb_monitor`和`cfg`对象的打印信息。
总结而言,UVM中的默认拷贝/克隆操作为深拷贝,`UVM_REFERENCE`标志位用于实现浅拷贝。理解这些概念对于在UVM中进行对象拷贝时避免错误至关重要。
UVM factory机制如何重载带参数的object
深入理解UVM factory机制与parameterized class的关系
UVM factory机制无法直接重载parameterized class,因此,尝试通过此方法实现的功能往往无法达到预期效果。
factory机制实质上是一个映射表与一系列映射函数的组合,主要映射uvm object与字符串。如函数ahb_monitor所注册,映射表中为ahb_monitor对象与字符串"ahb_monitor"。factory基于字符串创建uvm_object,即是通过查找表找到对应object后创建。
此理解可以从源代码注释中得到证实。映射表的关键在于类名本身,即字符串映射。
此外,factory还存在重载机制,基于字符串映射字符串。例如类A继承自类B,并通过宏`uvm_component_utils`注册,实际上将A、B与字符串"A"、"B"映射至factory。当尝试创建B时,实际上查找B对应字符串"B",进而找到"A",再找到"A"对应的对象,完成cast操作。
然而,存在一类特殊的uvm_object,即带参数的对象。此类对象中,两个相同对象可拥有无数不同写法,导致无法保证相同对象对应相同字符串,整个机制无法正常运作。UVM明确指出不支持此类操作。
在带参数的object注册时,映射字符串均为“”,这表示UVM内部处理此类情况的方式。尝试使用`set_type_override_by_type`方法,运行结果验证了UVM处理此类问题的方法。