3. UVM层次结构与Verdi nSchema
在UVM验证环境中，几乎所有调试问题最终都会落到两个基本问题上：这个对象在层次树的什么位置？它是component还是object？Verdi的nSchema视图正是回答这两个问题最直接的入口。它把仿真时动态构建的UVM层次以树形方式呈现出来，并允许逐层展开、查看factory注册信息和config_db配置路径。理解nSchema的组织方式，能显著缩短从"现象"到"根因"的定位时间。
UVM树形层次：component构成骨架
UVM的层次结构由uvm_component派生类在build_phase中通过new(name, parent)逐级创建，形成一棵以uvm_test_top为根的树。典型结构如下：
uvm_test_top (my_test)
├─ env (my_env)
│ ├─ agent_ahb (ahb_agent)
│ │ ├─ driver (ahb_driver)
│ │ ├─ monitor (ahb_monitor)
│ │ └─ sequencer (ahb_sequencer)
│ └─ scoreboard (my_scoreboard)
└─ vseqr (virtual_sequencer)这棵树的每个节点都是一个component实例，其完整层次路径由各级get_name()用点号连接而成，例如uvm_test_top.env.agent_ahb.driver。这个路径字符串是后续config_db、factory覆盖、报告过滤等机制的公共索引，也是nSchema中定位节点的关键。
component与object的本质区分
调试时最常见的误判是把object当成component去查层次。二者的区别必须清晰：
- 生命周期：component随仿真从build到final持续存在，object（如transaction、sequence、config对象）按需创建、用完即弃。
- 层次归属：component有parent，构成树；object没有parent，不属于层次树，只通过句柄被引用。
- nSchema可见性：nSchema默认展示component树；object不会作为树节点出现，只能通过其创建者（如sequencer、driver）的上下文或波形/事务窗口观察。
因此，当你在nSchema里"找不到"某个transaction时，通常不是工具问题，而是它本就不该出现在层次树中。此时应转向sequence/transaction调试视图，或检查该object是否被正确uvm_config_db#(...)::set到某个component。
nSchema中展开UVM层次
在Verdi中打开nSchema（通常通过verdi -ssf novas.fsdb后加载UVM层次，或使用verdi -uvm相关选项），左侧呈现层次树，右侧显示选中节点的属性。展开操作的关键点：
- 根节点通常显示为
uvm_test_top或顶层module，展开后逐级显示component实例名与类型名。 - 节点前的三角标可逐层展开；右键菜单可"Expand All"或按类型过滤。
- 选中某节点后，属性面板显示其full name、type、parent，以及是否被factory覆盖。
- 若某层未展开或显示为空，常见原因是该component在build_phase中因条件判断未创建，或parent传参错误导致挂到了非预期节点下。
factory注册信息查看
UVM factory机制允许用派生类替换基类，但替换是否生效取决于注册与覆盖是否匹配。在nSchema中选中一个component节点，可查看其factory注册信息，包括：注册名（`uvm_component_utils`宏注册的字符串）、原始类型、是否被set_type_override_by_type或set_inst_override_by_type覆盖、覆盖后的实际类型。
典型排查场景：期望driver被替换为ahb_driver_err，但nSchema中该节点类型仍显示ahb_driver。此时应检查：覆盖调用是否在build_phase之前执行、覆盖路径字符串是否与nSchema中的full name完全一致、注册宏是否写在了正确的类中。nSchema给出的"实际类型"是判断覆盖是否生效的最终依据。
config_db配置路径追踪
config_db的set/get通过路径字符串匹配，路径写错是配置失效的头号原因。nSchema可辅助追踪：选中目标component，查看其full name，再对照代码中的set/get路径。
// set 端
uvm_config_db#(int)::set(this, "agent_ahb.driver", "pre_num", 8);
// get 端
uvm_config_db#(int)::get(this, "", "pre_num", pre_num);若get端在uvm_test_top.env.agent_ahb.driver中执行，则set路径this为uvm_test_top.env时，拼接后为uvm_test_top.env.agent_ahb.driver，匹配成功。若set写成"agent.driver"或get端this层级不对，则匹配失败，get返回0且变量保持默认值。nSchema中确认full name后，可快速判断路径是否一致。
把三者串起来看
nSchema的价值在于把层次、factory、config_db三条线索放在同一视图里交叉验证。一个高效的排查顺序是：先在nSchema中定位目标component的full name，确认它确实被创建且挂在预期parent下；再查看其factory实际类型，判断覆盖是否生效；最后用full name去核对config_db的set/get路径。三步中任何一步不匹配，都能在nSchema中找到明确证据，而不必反复加打印或猜测。
掌握nSchema后，UVM调试从"读代码猜结构"转变为"看运行时真实结构"，这是根因定位效率提升的关键一步。