UVM知识点4

uvm_transport_port和 uvm_analysis_port

在 UVM(通用验证方法学)中,uvm_transport_portuvm_analysis_port 是两种不同类型的接口,用于在 UVM 组件之间进行通信。它们的主要区别在于其用途和通信模式:

  1. uvm_transport_port

    • uvm_transport_port 用于实现请求-响应型的通信,通常用于发送事务(transactions)和接收响应。
    • 源组件(发送方)通过将事务发送到 uvm_transport_port,然后等待目标组件(接收方)处理该事务并发送响应。
    • 这种模式适用于需要请求和响应之间紧密协作的通信,例如通过总线传递请求和等待从设备接收响应。
  2. uvm_analysis_port

    • uvm_analysis_port 用于实现发布-订阅型的通信,通常用于向订阅者发送事件或数据。
    • 源组件(发送方)通过将事件发送到 uvm_analysis_port,不需要等待接收方的响应。
    • 接收方(订阅者)可以选择性地订阅事件,然后在需要的时候处理接收到的事件。
    • 这种模式适用于需要在组件之间松散耦合的情况,例如收集统计信息、记录日志或实现监视功能。

综上所述,uvm_transport_port 适用于请求-响应型的通信,而 uvm_analysis_port 适用于发布-订阅型的通信。这两种类型的接口在 UVM 中都有其重要作用,用于构建复杂的验证环境和实现不同组件之间的通信机制。

uvm1.1d转uvm1.2注意事项

uvm从1.1d到1.2再到IEEE1800.2,有了很多变化。尤其是从1.1d到1.2,在objection的使用上有了一些关键性变化。

在uvm进入到1.2后,starting_phase不在推荐使用。更为重要的是,不仅仅是不再推荐,而且如果以default sequence的方式启动以后,default sequence被启动以后,starting_phase依然会是null,如果沿用以前的代码,整个平台就起不来了

task body()
if(starting_phase != null)
starting_phase.raise_objection(this)
//do something
if(starting_phase != null)
starting_phase.drop_objection(this)
endtask

尽管starting_phase不推荐使用,但是这个类并没有被uvm删除,如果想要继续使用,那么需要在使用之前进行如下赋值。

starting_phase=get_starting_phase()

get_starting_phase的原型如下

image.png
如果不想这么麻烦,也可以使用1.2的新方法,

uvm_sequence_base::set_automatic_phase_objection
image.png

链接:https://www.jianshu.com/p/f3ee1861f7b4

寄存器模型

前言
ralgen是VCS工具自带的脚本,用于uvm中生成寄存器模型,本文主要介绍uvmgen脚本。首先,介绍在uvm中,利用ralgen脚本,生成寄存器仿真模型RAL model的命令;然后,列出了ralgen -full64 -h帮助中的内容,供查阅。

UVM Register Abstraction Layer (RAL)的主流生成工具有如下几种:

  1. SystemRDL: 这是一个用于描述硬件寄存器的规范语言。存在多个工具可以从SystemRDL描述生成UVM RAL模型。

  2. IP-XACT: 也可以用于描述硬件接口和结构,然后从中生成UVM RAL。

  3. 其他第三方工具: 很多EDA公司和其他供应商提供了工具来生成UVM RAL模型。例如,Cadence的VManager工具、Synopsys的VC VIP等。

ralgen’是一种通常用于生成UVM (UniversalVerification Methodology) 寄存器抽象层(RAL)模型的工具。这个工具通常是 EDA (Electronic Design Automation) 工具套件的一部分,比如 Synopsys的VCS,Cadence 的Incisive 或 Mentor Graphics的 Questa等。
在这个具体的命令中:
自山中
~-t qspi:指定目标(通常是顶层模块或者顶层存器容器)的名字为qspit
-uvm:指定生成的模型应遵循UVM方法论。
qspi.ralf:这通常是一个描述寄存器模型的 RALF (Register Abstraction Layer File) 文件。RALF文件通常是XML或其他格式,包含了寄存器的详细信息,如地址、位宽、权限等
执行这个~ralgen”命令后,工具通常会生成一组SystemVerilog 文件,这些文件实现了UVM RAL模型,包括寄存器的各种属性和行为。这样,验证工程师就可以用这个模型进行更高级别的验证,而无需关心底层硬件的细节。

一、uvm寄存器模型的生成命令

生成RAL model的命令:
ralgen [options] -t topname -I dir -uvm {filename.ralf}

-t topname
RALF文件中顶层模块或者系统的名称,生成的RAL model文件名称为ral_topname.sv
-I dir(注意是i的大写,不是L的小写)
ralgen搜索源文件的可选目录列表
-uvm
声明是UVM方法学
filename.ralf
.ralf后缀不是必须的。对于多个文件的情况,指定顶层的RALF文件,在这个文件通过source来包含其他文件。
options

-all_fields_rand
允许你配置所有可写字段为rand (is_rand_bit设置为1),而不需要指定约束块。生成的代码只标记字段,默认情况下这些字段的约束定义为rand。
-b
为声明了完整hdl_path的reg和mem生成后门访问代码
-B, gen_byte_addr
生成具有字节级地址粒度的RAL模型。
-c a
-c b
-c f
-c表示覆盖率coverage,上面三个依次表示“Address Map” “Register Bits” “Field Values”功能覆盖率模型。
-c s
为只读bit位生成单独的仓,以便为ralgen生成的bit级覆盖,读取只读寄存器的1和0。在-c s选项旁边指定-c b选项会导致错误。
-e
为每个抽象类生成空约束
-f < filename >
在一个文件里声明ralgen选项
-gen_html
生成RAL模型及其HTML UVM文档。它的相关文件被转储到ral_top_path_name_doc目录下。如果指定此选项而没有使用-uvm选项,则会出现错误。
-top_macro < string_which_overrides_default_macro >
允许您使用不同的宏而不是name_TOP_PATH来指定对应于RAL模型的DUT实例的绝对路径。

二、ralgen -full64 -h 帮助命令

通过ralgen -full64 -v和ralgen -full64 -h这两个命令,可以查看ralgen的版本和帮助,具体内容如下,供查阅。

hefei@ubuntu:~/Desktop/proj/top_env/run$ ralgen -full64 -v
ralgen version 1.17.0 (Requires RAL Version 1.16.0 or above)
hefei@ubuntu:~$ ralgen -full64 -h

Usage:
======
ralgen -h
ralgen -v
ralgen -l <lang> [-gen_c] -t <top> -f <file> [-top_domain <domainname>] [-B|-gen_byte_addr] [-I <dir1>:...:<dirN>] [(-e|-ext_ud)] [-b [-p <top_path>] -gen_vif_bkdr] [-q] [-qf <pattern_file>] [-R <dirname>] [-no_bkdr_cb] [-gen_html] <RALF-file>
ralgen -ipxact2ralf <ipxact-file>

Where
       <lang>                   = Target Language. Currently, supported are 'sv', 'ov' and 'c'.
       <top>                    = Name of top-level block/system
                                  of your RALF spec.
Options:
        -h          : prints this help message.

        -v          : prints ralgen version info.

        -t  topname : name of top-level block or sytem in the RALF file

        -f  file    : A file containing different ralgen options

        -l  sv|ov|c : specifies target language of the RAL Model.

        -uvm        : generates UVM RAL model.

        -o fname    : Output file name. By default, uses ral_topname.
                      A language-appropriate suffix will be automatically appended.

        -g, -gen_c  : generates C interface to the RAL model. Invalid with <lang> == 'c'.
                      Not yet supported.

        -b          : triggers/activates backdoor code generation.
                      By default, backdoor code is not generated.

        -gen_vif_bkdr
                    : Generates backdoor access using virtual interface reference.
                      This option can only be used with option '-b'.

        -no_vif_self_inst
                    : Omits generating initial block inside interface for self registering.
                      This option can only be used with option '-gen_vif_bkdr'.

        -c  b|s|a|f|F : generate the specified coverage models.
                        b: bit-level, generates single bin for 1/0 for RO bits
                        s: bit-level, generates separate bins for 1/0 for RO bits
                        a: address map
                        f: field values, only if 'cover +f' is specified in RALF spec
                        F: field values, even if 'cover +f' is not specified in RALF spec
                      'b' and 's' coverage models cannot be specified at the same time
                      Other combination of coverage models can be specified at the same time

        -single_plan
                    : generate the hvp as single plan.
        -q          : executes ralgen in quiet mode where all warnings are
                      suppressed.

        -qf <pattern_file>
                    : This option can be used whenever user wants to ignore a 
                      bunch of known (kind of accaptable for a given RALF) 
                      command line messages (typically used with warning messages).
                      <pattern_file> will need to contain the list of messages (1 per line)
                      or regular expressions (supported by egrep) of the list of 
                      messages (1 per line) that should not be showed by ralgen.

        -e, -ext_ud : Add undefined (external) constraint declarations in block and system classes.

        -I <dir1>:...:<dirN>
                    : list of folders to sequentially search 'source'd RALF files.

        -flds_out_reg  all | none | no_uniq:
                    : controls the field handle generation in blocks.
                        all : generates all field handles in blocks (same as not providing -flds_all_reg)
                        none : generates no field handles in blocks
                        no_uniq : generates no field handles for uniquely named in blocks
        -d, -top_domain
                    : When the <top>-level block/system has multiple domains, 
                      you must specify the top level domain name for which you need to 
                      generate RAL C Model/Interface. Note: This option is valid only when 
                      RAL C Model/Interface is generated.

        -p <top_path>, -top_path <top_path>
                    : Specifies the absolute top level XMR backdoor path of the DUT instance.
                      This switch is used only for supporting VHDL backdoor.

        -top_macro <top_macro>
                    : Specifies the top level macro to be used in backdoor access.
                      when -top_macro is not provided, ralgen uses <uppercase_topname>_TOP_PATH as the top level macro.

        -full64
                    : Executes ralgen in 64 bit mode.

        -R <RTL_dir_name>
                    : Specifies the directory in which RTL files will be generated.

        -B, -gen_byte_addr
                    : Generates RAL model with byte-level address granularity.

        -ipxact2ralf <ipxact-file>
                    : Generates RALF file from the specified IPXACT file.

        -no_bkdr_cb : With this option, backdoor pre/post_read/write callback invokation code
                      is not genereated. This option can only be used with option '-b'.

        -a, -auto_mirror
                    : Generate code required for automatic mirror update.

        -gen_html   : Generates HTML doc for the register model.
                      This option can only be used when generating UVM RAL model.


原文链接:https://blog.csdn.net/hh199203/article/details/118612011

UVM中功能覆盖率和代码覆盖率收集

  • UVM中功能覆盖率
    在UVM(Universal Verification Methodology)中,功能覆盖率(functional coverage)是用于确保已经验证了设计的所有功能部分。覆盖率可以在多个UVM组件中定义,但最常见的是在uvm_covergroup中定义,然后在uvm_testuvm_sequenceuvm_monitor组件中对其进行采样。

以下是一个简单的例子,演示如何在UVM中定义和采样功能覆盖率:

  1. 定义一个uvm_covergroup:
class my_coverage extends uvm_subscriber #(uvm_object);
   covergroup cg_example;
      coverpoint cp_data {
         bins low  = {[0:10]};
         bins mid  = {[11:100]};
         bins high = {[101:255]};
      }
   endgroup

   function new(string name, uvm_component parent);
      super.new(name, parent);
      cg_example = new();
   endfunction

   virtual function void write(uvm_object transaction);
      // 此处进行采样
      cg_example.sample();
   endfunction
endclass
  1. uvm_monitor中对其进行采样:
class my_monitor extends uvm_monitor;
   uvm_analysis_port #(uvm_object) ap;

   function new(string name, uvm_component parent);
      super.new(name, parent);
      ap = new("ap", this);
   endfunction

   virtual task run_phase(uvm_phase phase);
      // 伪代码 - 当你的事务发生时,进行采样
      while (1) begin
         wait_for_transaction();
         ap.write(transaction);
      end
   endtask
endclass

上述例子中,uvm_covergroup定义了一个覆盖点cp_data,此覆盖点有三个区间作为bins。然后在my_monitor中,每次事务发生时都会对其进行采样。

  • 代码覆盖率

在UVM中,代码覆盖率与功能覆盖率略有不同。代码覆盖率(code coverage)通常是由仿真工具提供的,并基于设计的硬件描述语言(如Verilog或VHDL)代码。它不是在UVM组件中明确定义的,而是在仿真时自动或配置地由工具收集的。

代码覆盖率主要包括以下类型:

  1. 行覆盖率:每行代码是否执行过。
  2. 条件覆盖率:逻辑条件的每个结果(真/假)是否都被测试过。
  3. 分支覆盖率:代码中每个分支是否执行过。
  4. 路径覆盖率:代码中所有可能的路径组合是否都执行过。
  5. 切换覆盖率:信号从0到1和从1到0的转换是否都触发过。
    … 等等。

虽然你不会在UVM的某个组件中明确定义代码覆盖率,但你可能需要在仿真脚本或仿真工具的配置中指定收集哪种类型的代码覆盖率。

举一个简单的例子,考虑以下的Verilog代码:

module simple_logic(input a, input b, output y);
    assign y = a & b;
endmodule

为了获得完全的代码覆盖率,你需要确保ab的所有可能组合都被测试过。

但是,你如何知道哪些组合被测试过了呢?

这就是代码覆盖率工具的作用。当你使用如Cadence的Incisive、Synopsys的VCS或Mentor Graphics的ModelSim等工具运行仿真时,你可以配置它们来收集代码覆盖率信息。

例如,对于VCS,你可以使用以下命令行选项来收集覆盖率:

vcs +cover=bcesx -debug_all my_testbench.v

然后,运行仿真并查看覆盖率报告来确定哪些部分的代码已被覆盖,哪些部分尚未覆盖。

  • 0
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值