当前位置：首页 > news >正文

UVM学习总结

news 来源：原创 2025/7/16 5:15:27

问题1：同时出现几个相同的uvm_config_de()哪个有效？

UVM中的配置对象是通过uvm_config_db类实现的。uvm_config_db类使用一对名称和值来存储配置信息。当多个uvm_config_db.call()调用同时提供相同名称的配置时，最后一个调用将覆盖之前的调用。

因此，在同时出现多个相同的uvm_config_db.call()调用时，最后一个调用将是有效的，并将覆盖之前的调用。

在UVM中，每个组件都有自己的配置空间。当多个组件同时出现多个相同的uvm_config_db.call()调用时，每个组件内的调用都是独立的，不会相互影响。

因此，在不同组件内同时出现多个相同的uvm_config_db.call()调用时，每个组件内的调用都是有效的，并且不会相互干扰。每个组件内的调用将覆盖之前的调用，只影响该组件内的配置设置。其他组件的配置设置则不受影响。

问题2：在uvm的环境中，怎么启动sequence？

在UVM中，序列是用于生成和控制交易或操作序列的对象。UVM序列可以通过不同的方式进行启动，包括：

使用动态调用：可以通过直接在测试中实例化和启动序列来使用动态调用。这种方式适用于需要在运行时动态选择和启动序列的情况。通常使用uvm_config_db来为序列配置参数，然后使用uvm_factory中的create_object_by_type()或create()方法动态实例化和启动序列。
在环境中启动：在UVM中，通常是在测试环境的build阶段创建和配置序列，然后在run阶段启动它们。这种方式适用于将序列的启动逻辑集中在环境中进行控制的情况。在环境中，您可以使用uvm_config_db来将配置设置传递给序列，并使用uvm_sequence_base中的start()方法启动序列。
在test中启动：另一种启动序列的方式是在测试中直接启动它们。这种方式适用于一次性或简单的测试，其中可以直接通过调用序列的start()方法来启动序列。在测试中，您可以通过实例化序列并调用其start()方法来启动它们。

无论使用哪种启动方式，UVM序列的执行都是由UVM运行时环境控制的。UVM运行时环境会根据各个序列的各种优先级和约束来决定序列的调度和执行顺序。

当使用uvm_sequence_base的start()方法启动序列时，需要实例化序列并调用其start()方法来开始执行。下面是一个例子，以说明如何使用start()方法启动序列：

首先，定义一个继承自uvm_sequence类的序列，例如my_sequence：

class my_sequence extends uvm_sequence #(my_transaction);// 构造函数function new(string name = "my_sequence");super.new(name);endfunction// run_phase方法task body();// 执行序列中的交易生成和控制逻辑// 可以使用uvm_do_with()生成交易，也可以使用uvm_send()发送交易endtask
endclass

复制插入

然后，可以在测试中实例化该序列并调用start()方法来启动它：

class my_test extends uvm_test;// ...function run_phase(uvm_phase phase);super.run_phase(phase);// 实例化my_sequencemy_sequence my_seq = new();// 调用start()方法启动序列my_seq.start(m_sequencer);endfunction
endclass

复制插入

在上述示例中，my_test是一个继承自uvm_test的测试类。通过在run_phase方法中实例化my_sequence对象，并将其传递给start()方法，可以将序列与一个特定的sequencer关联起来。

start()方法在内部执行以下步骤：

确定当前的运行阶段（例如，运行阶段run_phase）。
检查sequencer是否已经准备好接受序列，并抛出错误，如果不满足先决条件。
调用uvm_sequence_base中的pre_start()方法，进行任何必要的准备工作。
将序列添加到运行阶段的活动队列中。
调用uvm_sequence_base中的start_item()方法，标记序列的启动。
调用uvm_sequence_base中的wait_for_grant()方法，等待sequencer授权。
一旦获得授权，调用uvm_sequence_base中的main_phase()方法，开始执行序列的主要逻辑。
在序列运行时，可以调用uvm_sequence_base中的wait_for_item_done()方法，等待当前交易完成。
完成序列后，调用uvm_sequence_base中的post_start()方法，进行任何必要的清理工作。

总结起来，调用uvm_sequence_base的start()方法可以启动序列并将其添加到活动队列中，然后通过授权和序列的主要逻辑执行来执行该序列。这是一种使用UVM中的start()方法启动序列的常见方法。

问题3：代码覆盖率、功能覆盖率和断言覆盖率的区别

代码覆盖率——是针对RTL设计代码的运行完备度的体现，包括行覆盖率、条件覆盖率、FSM覆盖率、跳转覆盖率、分支覆盖率，只要仿真就可以收集，可以看DUT的哪部分代码没有动，如果有一部分代码一直没动看一下是不是case没有写到。
功能覆盖率---与spec比较来发现，design是否行为正确，需要按verification plan来比较进度。用来衡量哪些设计特征已经被测试程序测试过的一个指标

首要的选择是使用更多的种子来运行现有的测试程序；
其次是建立新的约束，只有在确实需要的时候才会求助于定向测试，改进功能覆盖率最简单的方法是仅仅增加仿真时间或者尝试新的随机种子。
验证的目的就是确保设计在实际环境中的行为正确。设计规范里详细说明了设备应该如何运行，而验证计划里则列出了相应的功能应该如何激励、验证和测量

断言覆盖率:用于检查几个信号之间的关系，常用在查找错误，主要是检查时序上的错误，测量断言被触发的频繁程度。

问题4：芯片验证的流程

1、芯片规格
根据市场产品需求，规定芯片需要达到的功能和性能，产品和架构师根据客户提出的规格spec，商定出具体设计解决方案和实现的架构，划分出各个模块的文档。

2、测试点分解
根据spec文档，分解出具体的测试点。可以分为场景类、功能类、性能类等等，分解的颗粒度尽量细致，直到完备无漏，一个测试点被一个case覆盖的原则分解

3、验证方案
整个芯片的验证方案一般由验证负责人规划，将设计分成多个子系统，再将子系统分成多个模块：具体验证策略、EDA工具和IT资源、项目进度安排、未覆盖的功能，风险评估

4、验证计划
定制验证策略，评估验证计划，细化testbench搭建、debug、case开发等时间，大概分为：
spec阅读和测试点分解时间
开发环境和调试冒烟测试时间
开发case，完成全部case时间
回归测试和验证报告的时间

5、搭建验证平台
一般由激励生成器、驱动器、采样器、参考模型和计分板组成
从简单的功能开始，测试可以通过验证环境之后，再扩展其他功能
经常遇到编译报错、语法错误、预期错误，需要逐一解决
分析报错是由验证环境引起的，还是设计代码错误造成的

6、测试用例开发
冒烟测试：基本的寄存器读写测试，确保数据流已通
直接用例：根据spec中program流程配置的典型测试
随机用例：用于变量随机，覆盖更多边界，注重约束条件的配置
增补用例：以提高覆盖测试点为目标，增补相应的测试用例

7、回归测试
基本功能回归：基本功能与基本场景覆盖
高级功能回归：高级功能和边界测试覆盖
覆盖率收集回归：高级功能测试完成之后，开始收集覆盖率

8、覆盖率分析
行覆盖率
条件覆盖率
跳转覆盖率
分支覆盖率
断言覆盖率
状态机覆盖率
功能覆盖率

9、验证报告
应用场景验证
模块复用说明
覆盖率分析
风险评估
待改进方案

10、后仿
慢慢跑着就行了，基本signoff了。

问题1：同时出现几个相同的uvm_config_de()哪个有效？

问题2：在uvm的环境中，怎么启动sequence？

问题3：代码覆盖率、功能覆盖率和断言覆盖率的区别

问题4：芯片验证的流程

相关文章：