用Codex高效学习UVM：从环境搭建到核心机制实战

之前在做验证环境时一直想找一种更高效的方式学习 UVM。UVM 本身内容多、抽象概念多光是 component 树、phase 机制、sequence 通信就够让人理一阵子。网上资料虽然不少但零散不成体系很多问题要翻好几篇文章才能找到线索。后来接触了 Codex发现它不仅能写代码还能用来拆解 UVM 里的复杂概念、生成可运行的验证组件、解释编译报错。本文就把这套“用 Codex 学 UVM”的完整方法做一个梳理包含环境配置、常用场景、Prompt 思路、UVM 核心知识点拆解以及常见问题的排查清单。不管你是刚开始学 UVM 的学生还是已经入了验证门槛、想提升效率的工程师这篇文章都值得收藏。读完你会掌握两条线一条是 Codex 工具本身的安装、配置和日常用法另一条是围绕 UVM 学习场景如何设计提示词、如何让 Codex 输出可参考的代码、如何用它辅助排查编译和仿真问题。1. 为什么可以用 Codex 学习 UVM1.1 学 UVM 的典型痛点UVMUniversal Verification Methodology是 SystemVerilog 验证方法学的标准框架现在芯片验证岗位上基本绕不开它。但学习过程中有几个很现实的问题概念多且抽象例如 uvm_component、uvm_object、factory 机制、phase 机制、TLM 通信、sequence 与 sequencer 的交互方式。代码量大一个最小的 UVM 环境也需要 driver、monitor、agent、env、test 等多个文件协同工作初学者容易迷失在文件组织上。编译报错信息不够友好很多错误其实是类没有被正确例化或者 phase 方法拼写不对但报错信息往往指向深层代码新手很难定位根因。网上资料的质量参差不齐有的讲得太底层有的只是跑通 demo缺少能跟着一步步验证的完整代码。这些痛点恰恰是 Codex 这类 AI 编程助手比较擅长解决的。1.2 Codex 是什么Codex 是 OpenAI 推出的编程助手工具可以用来生成代码、解释代码、补充注释、排查报错、重构代码等。实际使用中Codex 可以通过 CLI、桌面应用或 IDE 插件的方式接入。开发者可以把 Codex 当作一个“随时在线、且对验证领域有一定知识储备”的结对编程伙伴。需要说明的是Codex 的能力会受模型版本影响在不同运行环境下可选的模型和 API 配置也有差异。本文重点聊的是使用方法和学习思路不会绑定某一款具体模型配置方式请以你本地安装的客户端实际显示为准。1.3 用 Codex 学 Verilog/UVM 是否靠谱很多初学者会问AI 生成 SystemVerilog 和 UVM 代码真的能跑吗我的观点是把它当作“辅助工具”而不是“唯一答案”。Codex 在以下几个场景非常有用生成标准组件的骨架代码例如 uvm_driver、uvm_monitor、uvm_scoreboard、uvm_test 的框架。解释某个类或某个 phase 的含义配合小例子说明。根据你的项目描述生成 TLM 连接、寄存器模型访问等常见代码片段。根据编译和仿真报错信息帮你定位可能的错误位置。但在最终落到仿真器之前代码必须经过自己的理解、修改和验证。AI 工具可以帮你缩短“从 0 到 1”的时间但不能替代你对 UVM 设计思想的理解。2. 环境准备与 Codex 安装配置2.1 本机环境说明本文的操作思路以常见开发环境为例重点演示配置思路不绑定固定版本。实际环境可能包括Windows 或 Linux 操作系统。使用的仿真工具可能是 VCS、Questa、Xcelium 或开源的 VerilatorUVM 支持取决于版本。Codex CLI 或桌面客户端。文本编辑器或 IDE例如 VS Code。如果你的机器上已经安装了以上部分工具直接跳过对应步骤即可。2.2 安装 Codex 并处理常见启动报错在安装和启动 Codex 的过程中很多用户会遇到一个高频报错unable to locate the codex cli binary. set codex_cli path or ensure the electron app can find it这个报错的意思是Codex 客户端尤其是一些基于 Electron 的图形界面找不到 codex CLI 的可执行文件。也就是说你已经启动了 Codex 的桌面端但是它的后端命令行工具没有安装或者安装路径没有被正确识别。排查思路如下先确认 codex CLI 是否真的已安装。在命令行执行codex --version如果能输出版本号说明 CLI 本身已安装。如果提示找不到命令说明需要先安装 Codex CLI。具体安装方式根据 Codex 官方文档操作一般情况下是把 codex 可执行文件放到系统 PATH 目录中或者安装时选择“添加到 PATH”。如果 CLI 可用但桌面端仍然报这个错则需要手动设置 codex_cli_path 环境变量指向 codex 可执行文件的实际路径。以 Windows 下设置环境变量的思路为例# 假设 codex.exe 所在路径为 C:\tools\codex\codex.exe set CODEX_CLI_PATHC:\tools\codex\codex.exe在 Linux 环境下export CODEX_CLI_PATH/usr/local/bin/codex注意具体环境变量名称以你使用的客户端版本为准。设置完成后重新启动 Codex 客户端一般就能正常进入主界面。如果客户端使用代理也可能会遇到类似 “cc switch local proxy failed while handling codex endpoint” 的报错此时需要检查客户端的代理设置是否指向了可用的本地代理地址或者关闭不必要的代理开关后重试。2.3 配置自定义模型接入部分用户希望在 Codex 中使用不同的模型服务比如接入其他模型能力来降低使用成本或适配本地环境。这一类的配置通常涉及两个关键项API Base 地址。模型名称。有的 Codex 客户端或 CLI 支持通过环境变量指定 API Base。参考配置思路如下export OPENAI_API_KEY你的密钥 export OPENAI_BASE_URLhttps://你的API服务地址此时需要注意一个常见报错the gpt-5.6-sol model is not supported when using codex with a...这类问题一般说明你当前配置的模型名称不是该服务支持的范围。解决方式是把模型名称改成服务商实际支持的模型 ID。例如在 Codex 的配置文件中搜索model关键字把它修改为目标服务支持的模型名称。需要强调的是不同 Codex 版本对自定义模型的支持程度不同有的版本只支持官方模型。请根据你实际使用的客户端版本和文档来调整不要盲从网上的配置模板。3. Codex 基础使用思路3.1 Codex 的交互方式Codex 常见的交互方式有命令行会话和桌面端聊天窗口两种。命令行方式适合快速执行小任务比如解释一段代码、生成一个函数。桌面端适合更长的对话可以粘贴报错信息、贴代码片段让 Codex 基于完整上下文分析。Codex CLI 的典型启动命令大致如下codex启动后就可以在会话中直接输入问题。例如请用 SystemVerilog 写一个最简单的 uvm_driver包含 build_phase 和 run_phase。3.2 如何写清楚 Prompt用 Codex 学 UVM最大的技巧不是记住命令而是学会描述需求。一个高质量 Prompt 通常具备以下特征说明角色。说明上下文。说明任务。说明输出格式。说明约束条件。示例你是一名资深芯片验证工程师精通 SystemVerilog 和 UVM。请帮我写一个 uvm_sequence 类在 body 任务中创建一个 item并通过 start_item 和 finish_item 发送给 sequencer。代码要完整包含类声明、构造函数和 uvm_object_utils 宏。这种 prompt 比直接说“写一个sequence”更容易得到可用代码。3.3 多轮对话的学习方式Codex 的优势在于可以多轮追问。学 UVM 的时候可以用这种节奏第一轮让 Codex 生成一个类的最小示例。 第二轮追问“这里为什么要 extends uvm_sequence_item而不是 uvm_component”。 第三轮让代码加入打印语句跑通后查看输出。 第四轮让 Codex 解释 factory 机制在这个代码里起到什么作用。这种多轮方式本质上是把学习目标拆解成一层层追问效果比一次性输出一大段原理要好得多。4. UVM 核心知识点拆解与 Codex 辅助实操下面我们以 UVM 中最核心的知识点为例演示如何用 Codex 辅助学习。4.1 uvm_object 与 uvm_componentUVM 中所有类都派生自 uvm_object而 uvm_component 是继承 uvm_object 的、具有生命周期和层次结构的类。初学者最容易混淆这两个概念。uvm_object没有 phase 机制没有 parent 概念例如 sequence item、sequence、config object。uvm_component是树形节点的基本单位有 phase 机制有 parent 参数例如 driver、monitor、agent、env、test。可以让 Codex 生成一个代码片段来体现区别// 文件路径src/uvm_basic/my_item.sv class my_item extends uvm_sequence_item; rand bit [7:0] addr; rand bit [7:0] data; uvm_object_utils_begin(my_item) uvm_field_int(addr, UVM_ALL_ON) uvm_field_int(data, UVM_ALL_ON) uvm_object_utils_end function new(string name my_item); super.new(name); endfunction endclass这段代码定义了一个 sequence item它继承自 uvm_sequence_item而 uvm_sequence_item 最终继承自 uvm_object。它代表的是在 sequencer 和 driver 之间传输的数据对象。接着看 component 的例子// 文件路径src/uvm_basic/my_driver.sv class my_driver extends uvm_driver #(my_item); uvm_component_utils(my_driver) function new(string name, uvm_component parent); super.new(name, parent); endfunction function void build_phase(uvm_phase phase); super.build_phase(phase); endfunction task run_phase(uvm_phase phase); my_item item; forever begin seq_item_port.get_next_item(item); $display([Driver] got item addr%0d data%0d, item.addr, item.data); seq_item_port.item_done(); end endtask endclass这里有两点值得注意构造函数多了一个uvm_component parent参数说明它必须挂到组件树上。代码中使用了uvm_component_utils而不是uvm_object_utils因为 component 不是通过 copy 方式使用而是通过工厂注册和层次查找。4.2 phase 机制的理解UVM 的 phase 机制决定了验证环境按照什么顺序构建、连接和运行。最常用的几个 phase 包括build_phase自顶向下执行用于创建和配置组件。connect_phase自底向上执行用于组件之间的 TLM 端口连接。run_phase并行运行用于驱动激励和采集数据。report_phase在仿真结束后打印报告。Codex 最常见的辅助方式是生成带打印信息的 phase 示例。例如// 文件路径src/uvm_basic/my_component.sv class my_component extends uvm_component; uvm_component_utils(my_component) function new(string name, uvm_component parent); super.new(name, parent); endfunction function void build_phase(uvm_phase phase); super.build_phase(phase); $display([%s] build_phase, get_full_name()); endfunction function void connect_phase(uvm_phase phase); super.connect_phase(phase); $display([%s] connect_phase, get_full_name()); endfunction task run_phase(uvm_phase phase); $display([%s] run_phase started at %t, get_full_name(), $time); #100; $display([%s] run_phase ended at %t, get_full_name(), $time); endtask endclass在仿真日志中可以清楚看到 build、connect、run 三个阶段的顺序。理解 phase 顺序之后再去学习 reset、configure、main 等子 phase就会顺畅很多。4.3 sequence 与 sequencer 通信sequence 是 UVM 中激励生成的机制它运行在 sequencer 之上通过 start_item 和 finish_item 把 item 发送给 driver。一个简单的 sequence 示例如下// 文件路径src/uvm_basic/my_sequence.sv class my_sequence extends uvm_sequence #(my_item); uvm_object_utils(my_sequence) function new(string name my_sequence); super.new(name); endfunction task body(); my_item item; repeat (3) begin item my_item::type_id::create(item); start_item(item); if (!item.randomize()) begin uvm_error(SEQ, Randomize failed) end finish_item(item); end endtask endclass让 Codex 解释这段代码时可以追加提问为什么这里需要 start_item 和 finish_item如果把 randomize 放在 start_item 之前会有什么问题start_item 和 finish_item 之间的代码是干什么的在实际工程中sequence 可以多层嵌套可以带约束可以用uvm_do宏简化代码。初学阶段建议先理解宏背后的展开逻辑再决定是否依赖宏。4.4 uvm_config_db 配置传递UVM 中跨层传递配置数据通常使用 uvm_config_db。它有 set 和 get 两个操作。例如在 test 层设置 virtual interface// 文件路径src/uvm_basic/my_test.sv class my_test extends uvm_test; uvm_component_utils(my_test) function new(string name, uvm_component parent); super.new(name, parent); endfunction function void build_phase(uvm_phase phase); super.build_phase(phase); uvm_config_db#(virtual my_if)::set(this, *.env.agent.*, vif, my_if); endfunction endclass然后在 driver 的 build_phase 中取出这个 virtual interfaceclass my_driver_with_vif extends uvm_driver #(my_item); virtual my_if vif; uvm_component_utils(my_driver_with_vif) function new(string name, uvm_component parent); super.new(name, parent); endfunction function void build_phase(uvm_phase phase); super.build_phase(phase); if (!uvm_config_db#(virtual my_if)::get(this, , vif, vif)) begin uvm_fatal(DRV, Cannot get vif) end endfunction endclass这里常见的错误是 set 和 get 的路径不匹配导致 get 失败。排查时可以打印 set 和 get 的完整路径使用uvm_config_db提供的查看机制或通过uvm_top.print_config()打印配置信息。4.5 寄存器模型与镜像值UVM 寄存器模型是验证工程师面试和实际项目中经常遇到的考点。寄存器模型用于模拟 DUT 中的寄存器通过前门或后门访问方式对寄存器进行读写。“寄存器模型镜像值”是学习中的一个难点。所谓镜像值是指寄存器模型保存的一份软件预期值它并不一定等于 DUT 内部寄存器的真实值。UVM 通过 predict、mirror、update 等操作维护镜像值。在寄存器模型中执行reg.write()后镜像值会被更新为写入值。执行reg.mirror()时模型会读取 DUT 寄存器并把读取值与镜像值作比较。如果 DUT 寄存器被外部逻辑修改模型中的镜像值不会自动感知除非设置了预测机制。Codex 可以帮助生成一个简单的寄存器模型访问示例例如// 文件路径src/reg_model/my_reg_model.sv class my_reg extends uvm_reg; rand uvm_reg_field data_field; function new(string name my_reg); super.new(name, 32, UVM_NO_COVERAGE); endfunction virtual function void build(); data_field uvm_reg_field::type_id::create(data_field); data_field.configure(this, 8, 0, RW, 0, 8h0, 1, 0, 0); endfunction uvm_object_utils(my_reg) endclass class my_reg_model extends uvm_reg_block; rand my_reg reg0; function new(string name my_reg_model); super.new(name, UVM_NO_COVERAGE); endfunction virtual function void build(); reg0 my_reg::type_id::create(reg0); reg0.configure(this, null, ); reg0.build(); default_map create_map(default_map, 0, 4, UVM_LITTLE_ENDIAN); default_map.add_reg(reg0, 32h0, RW); endfunction uvm_object_utils(my_reg_model) endclass学习寄存器模型时建议按以下顺序先理解寄存器和寄存器字段的 configure 参数。再理解 register map 的地址映射。接着学习前门访问和后门访问。最后研究 predict 和 mirror 机制。Codex 可以作为讲解伙伴让它在每一步都生成最小示例。5. 完整实战用 Codex 从零生成一个最小 UVM 环境这一节我们演示一个比较完整的学习闭环。假设我们要搭建一个最小 UVM 环境包含接口 my_if。transaction my_item。driver my_driver。monitor my_monitor。agent my_agent。env my_env。sequence my_sequence。test my_test。top 模块。5.1 定义接口和事务对象接口定义// 文件路径src/my_if.sv interface my_if(input logic clk, input logic rst_n); logic [7:0] data; logic [7:0] addr; logic valid; endinterface事务对象// 文件路径src/my_item.sv class my_item extends uvm_sequence_item; rand bit [7:0] data; rand bit [7:0] addr; rand bit valid; uvm_object_utils_begin(my_item) uvm_field_int(data, UVM_ALL_ON) uvm_field_int(addr, UVM_ALL_ON) uvm_field_int(valid, UVM_ALL_ON) uvm_object_utils_end function new(string name my_item); super.new(name); endfunction endclass5.2 使用 Codex 生成 driver 和 monitor可以尝试用下面的 Prompt请用 SystemVerilog 写一个 UVM driver它从 seq_item_port 获取 my_item并把 item 中的 data、addr、valid 驱动到 virtual interface。请在 run_phase 中完成驱动。同时写一个 monitor采样接口上的信号并放入 analysis port。正常情况下Codex 会给出类似下面的结果// 文件路径src/my_driver.sv class my_driver extends uvm_driver #(my_item); virtual my_if vif; uvm_component_utils(my_driver) function new(string name, uvm_component parent); super.new(name, parent); endfunction function void build_phase(uvm_phase phase); super.build_phase(phase); if (!uvm_config_db#(virtual my_if)::get(this, , vif, vif)) uvm_fatal(DRV, failed to get vif) endfunction task run_phase(uvm_phase phase); my_item item; forever begin seq_item_port.get_next_item(item); vif.addr item.addr; vif.data item.data; vif.valid item.valid; (posedge vif.clk); seq_item_port.item_done(); end endtask endclass // 文件路径src/my_monitor.sv class my_monitor extends uvm_monitor; virtual my_if vif; uvm_analysis_port #(my_item) ap; uvm_component_utils(my_monitor) function new(string name, uvm_component parent); super.new(name, parent); endfunction function void build_phase(uvm_phase phase); super.build_phase(phase); if (!uvm_config_db#(virtual my_if)::get(this, , vif, vif)) uvm_fatal(MON, failed to get vif) ap new(ap, this); endfunction task run_phase(uvm_phase phase); my_item item; forever begin (posedge vif.clk); if (vif.valid) begin item my_item::type_id::create(item); item.addr vif.addr; item.data vif.data; item.valid vif.valid; ap.write(item); end end endtask endclass注意这里给出的代码是示例实际仿真时还要根据接口时序做适配。Codex 生成的代码往往需要手动调整时序细节。5.3 组装 agent、env 和 testAgent 用于封装 driver 和 monitor// 文件路径src/my_agent.sv class my_agent extends uvm_agent; my_driver driver; my_monitor monitor; uvm_sequencer #(my_item) sequencer; uvm_component_utils(my_agent) function new(string name, uvm_component parent); super.new(name, parent); endfunction function void build_phase(uvm_phase phase); super.build_phase(phase); driver my_driver::type_id::create(driver, this); monitor my_monitor::type_id::create(monitor, this); sequencer uvm_sequencer#(my_item)::type_id::create(sequencer, this); endfunction function void connect_phase(uvm_phase phase); super.connect_phase(phase); driver.seq_item_port.connect(sequencer.seq_item_export); endfunction endclassEnv 用于封装 agent// 文件路径src/my_env.sv class my_env extends uvm_env; my_agent agent; uvm_component_utils(my_env) function new(string name, uvm_component parent); super.new(name, parent); endfunction function void build_phase(uvm_phase phase); super.build_phase(phase); agent my_agent::type_id::create(agent, this); endfunction endclassTest 用于设置 virtual interface 并启动 sequence// 文件路径src/my_test.sv class my_test extends uvm_test; my_env env; uvm_component_utils(my_test) function new(string name, uvm_component parent); super.new(name, parent); endfunction function void build_phase(uvm_phase phase); super.build_phase(phase); env my_env::type_id::create(env, this); endfunction task run_phase(uvm_phase phase); my_sequence seq; phase.raise_objection(this); seq my_sequence::type_id::create(seq); seq.start(env.agent.sequencer); #100; phase.drop_objection(this); endtask endclass5.4 编写 top 模块并运行Top 模块是验证环境的入口它负责创建时钟、复位并执行 run_test// 文件路径src/tb_top.sv module tb_top; logic clk; logic rst_n; initial begin clk 0; forever #5 clk ~clk; end initial begin rst_n 0; #20 rst_n 1; end my_if u_if(clk, rst_n); initial begin uvm_config_db#(virtual my_if)::set(null, uvm_test_top, vif, u_if); run_test(my_test); end initial begin $dumpfile(wave.vcd); $dumpvars(0, tb_top); end endmodule在支持 UVM 的仿真器中可以按以下方式编译运行vlog -sv my_if.sv my_item.sv my_driver.sv my_monitor.sv my_agent.sv my_env.sv my_sequence.sv my_test.sv tb_top.sv vsim -c -do run -all; quit work.tb_top如果你的仿真工具不支持 UVM 源码或需要指定 UVM 库目录请按照工具文档调整编译参数。5.5 预期输出与验证运行仿真后日志中应该能看到 driver 和 monitor 的打印信息以及 sequence 发送的随机数据。例如[Driver] got item addr... data... [Monitor] observed item addr... data...这个实战案例虽然简单但已经把 UVM 环境的组件树、phase 机制、config_db 传递、sequence 通信、TLM 连接都串起来了。接下来可以在此基础上继续加 scoreboard、reference model 和寄存器模型。6. 常见问题与排查思路6.1 Codex 安装与启动问题问题现象常见原因解决思路启动 Codex 提示 unable to locate the codex cli binary未安装 CLI 或未设置路径安装 CLI 并设置 codex_cli_path 环境变量提示 model not supported配置中的模型名称不支持修改模型名为目标服务支持的模型 ID提示 local proxy failed客户端代理设置异常检查代理配置关闭不必要的代理开关后重试Codex 对话回复内容过于空泛Prompt 描述不具体明确角色、上下文、任务、输出格式6.2 UVM 编译与仿真相关问题问题现象常见原因解决思路编译提示 uvm_class 未声明未正确包含 UVM 库文件编译时加入 UVM 库源文件路径或使用工具自带的 UVM 库构建环境时没有创建组件build_phase 中使用了 create 但没有传 parent确保type_id::create(name, this)中传入父组件config_db get 失败set 和 get 路径不匹配打印路径调用 print_config 排查sequence 没有启动忘记调用 seq.start() 或没有 raise_objection在 test run_phase 中 spawn 并等待 sequence 完成monitor 采集不到数据采样条件不对或接口时序未对齐使用断言或波形检查 valid 信号时序6.3 排查清单如果遇到问题可以按以下清单逐步排查先确认编译命令中是否包含了所有文件是否遗漏了 UVM 库。确认组件树是否完整test 是否创建了 envenv 是否创建了 agent。确认 connect_phase 中的 TLM 连接是否写反。确认 sequence 是否有 start_item、finish_item 包裹。确认 object 和 component 是否选对了基类。确认 config_db 的 set/get 路径是否一致。确认是否调用了 raise_objection 和 drop_objection防止仿真提前退出。确认接口时序是否满足 driver 和 monitor 的采样要求。7. 最佳实践与工程建议7.1 把 Codex 当“代码审查者”而不是“代码生成器”在实际使用中不建议直接复制 Codex 的输出到工程里。更好的做法是让 Codex 生成第一版代码骨架。自己阅读并修改关键逻辑。让 Codex 解释一下这段代码为什么这么写。再让 Codex 模拟 reviewer指出潜在问题。例如可以这样提问请 review 下面这段 UVM driver 代码指出时序风险、是否缺少 objection 处理、config_db 路径是否合理。这种模式会强迫自己思考同时也能学到编码规范。7.2 UVM 学习从手工搭建到依赖工具学习 UVM 的初期建议先手工搭建一次完整的最小环境即使很慢也没关系。原因很简单UVM 的组件树和 phase 机制只有亲手搭过才能形成直观印象。当你能手工搭出最小环境后再开始使用 Codex 辅助生成重复性较高的代码比如寄存器模型、多个 agent 的 env。这样既保留了底层理解又提升了效率。7.3 代码与配置管理在实际工程中UV M 代码同样需要做好版本管理。建议每个类单独一个文件文件名与类名保持一致。文件名用小写加下划线或小写驼峰确保与工具兼容。统一编译文件列表使用 filelist 文件管理。在代码中通过 get_full_name() 打印关键日志提升可排查性。使用 factory 覆盖时注意 create 而不是 new。7.4 面对 AI 生成内容的安全边界使用 Codex 时还应注意几点不要把公司私有代码直接粘贴到不支持私有部署的 AI 工具中。涉及公司项目时先确认是否能使用外部 AI 服务。AI 生成的代码可能存在版本差异和潜在 bug不能直接用于流片验证环境。所有代码都必须在仿真工具中经过回归验证之后才能进入正式环境。8. 总结与后续学习路线本文围绕“用 Codex 学 UVM”这条主线梳理了 Codex 的安装、配置、Prompt 设计也覆盖了 UVM 中最核心的组件、phase、sequence、config_db 和寄存器模型知识点。这个过程里值得记住的关键点有Codex 适合做代码骨架生成、概念解释和报错排查但不能替代手工理解 UVM 设计思想。学 UVM 的第一步不是背代码而是理解组件树和 phase 机制。遇到问题先从编译和运行日志入手再结合 config_db 路径和组件树逐一排查。搭建最小验证环境是建立整体认知的最高效方式。寄存器模型的镜像值、前门后门访问、预测机制是进阶阶段必须掌握的硬核内容。如果你的下一步目标是找到 UVM 相关工作建议按照下面的路线继续学习熟练搭建最小 UVM 环境能够不参考示例独立写出 driver、monitor、agent、env、test。学习 TLM 通信的常见端口类型在 scoreboard 中实现数据比对。学习寄存器模型的前门访问和镜像值更新机制。学习 sequence 的进阶用法例如嵌套 sequence、virtual sequence。学习覆盖率收集和功能覆盖率建模。尝试把一个简单的 DUT 验证环境跑完回归并学会分析覆盖率报告。如果你在实操中遇到 Codex 配置或 UVM 编译报错问题欢迎把报错信息按章节中的排查清单逐项对照一次。大部分问题都能在日志和路径配置中找到线索。