1. 项目概述：理解UVM Sequence启动的核心价值

在UVM验证环境中，sequence是生成激励（stimulus）的灵魂。你可以把它想象成一个“剧本”，而sequencer就是“导演”，负责调度和执行这个剧本。但“剧本”再好，也得有正确的“开机”方式。很多刚接触UVM的朋友，包括我自己在早期项目里，都曾为sequence怎么启动、在哪启动、启动后怎么控制这些问题挠头。明明在uvm_do宏里写得明明白白的transaction，怎么就是发不出去？或者，为什么我的sequence启动了一次就结束了，无法循环？这些问题的根源，往往不在于sequence本身写得不对，而在于没有吃透sequence的启动机制。

UVM sequence主要有三种启动方式：start方法、default_sequence设置，以及通过uvm_config_db进行配置启动。这三种方式并非简单的并列关系，它们各有其适用的场景、执行的时机和背后的控制逻辑。选择哪种方式，直接关系到你的验证环境架构是否清晰、激励控制是否灵活、以及测试用例的复用性高低。今天，我们就来彻底拆解这三种启动方式，我会结合自己踩过的坑和项目中的实际应用，把每种方式的原理、写法、注意事项和典型使用场景给你讲透。无论你是正在搭建第一个UVM测试平台，还是想优化现有环境的激励生成策略，这篇文章都能给你提供可直接“抄作业”的实操指南。

2. Sequence启动方式深度解析与设计思路

2.1 核心概念：Sequence、Sequencer与Virtual Sequence

在深入启动方式之前，我们必须先统一几个核心概念，这是理解所有后续操作的基础。很多混淆都源于概念不清。

Sequence：激励事务（transaction）的生成器。它不是一个静态的对象，而是一个动态的过程，其核心任务是产生并发送transaction给sequencer。一个sequence里可以包含复杂的控制流、随机化约束和uvm_do系列宏。

Sequencer：仲裁器和转发器。它挂载在driver之上，主要做两件事：第一，仲裁来自多个sequence的transaction发送请求（虽然基础场景通常只有一个）；第二，将sequence产生的transaction转发给对应的driver。你可以把它理解为一个“管道”，sequence是水源，driver是用水终端，sequencer就是连接两者的水管，并控制水流的顺序。

Virtual Sequence：这是一个高级概念，但理解它对掌握启动方式至关重要。Virtual sequence本身并不直接产生具体的transaction，而是作为一个“总控序列”，用来协调多个运行在不同sequencer上的物理sequence（physical sequence）的执行顺序和同步关系。它通常没有固定的sequencer，需要通过p_sequencer句柄来访问环境中的其他sequencer。

为什么要区分这些？因为不同的启动方式，本质上是将sequence这个“剧本”交给不同的“导演”（sequencer）在不同的“时间点”去执行。start方法是手动、即时地指定导演开拍；default_sequence是告诉UVM在构建环境的某个阶段自动为某个sequencer安排一个默认剧本；而uvm_config_db配置则提供了一种灵活的、可重写的“剧本分发”机制。理解了你手中的“剧本”类型（普通的还是virtual的）和你想让哪个“导演”在何时执行它，就能自然地对号入座，选择最合适的启动方式。

2.2 三种启动方式的设计哲学与选型考量

这三种启动方式的设计，体现了UVM环境构建中“控制权”和“灵活性”的权衡。

sequence.start(sequencer)方式将控制权完全交给了用户。用户在run_phase（或其他phase）中，可以精确地控制sequence在何时、针对哪个sequencer启动。这种方式最为直接和强大，特别适合需要复杂控制逻辑的场景，例如：需要根据前一个sequence的执行结果来决定是否启动下一个sequence；或者在virtual sequence中动态启动多个子sequence。它的缺点是，需要用户手动编写启动代码，如果sequence和sequencer的层次关系复杂，管理起来会稍显繁琐。

default_sequence设置是一种“声明式”的启动方式。用户在test的build_phase中，通过uvm_config_db为某个sequencer的类型参数default_sequence设置一个默认的sequence类型。之后，UVM环境会在相应的phase（通常是main_phase）自动创建并启动这个sequence。这种方式将启动的细节隐藏了起来，让test的代码非常简洁，特别适合那些每个测试用例都需要在固定sequencer上运行固定主sequence的场景。它的灵活性相对较低，因为启动是自动的，难以在运行时进行干预。

通过uvm_config_db配置启动可以看作是default_sequence的增强版和更通用的形式。它不仅仅用于设置默认sequence，还可以在环境的任何层次、任何时间，将某个sequence实例（而不仅仅是类型）配置给某个sequencer。这为sequence的动态替换、跨层次传递以及高级复用提供了可能。例如，顶层的test可以将一个精心构造的virtual sequence实例，通过config_db传递给底层的一个virtual sequencer，从而实现全局的激励控制。

在实际项目中，我通常会这样混合使用：对于整个验证平台公用的、稳定的主激励流，采用default_sequence方式，保证环境基础运行。对于测试用例特有的、复杂的、需要动态调整的激励场景，则在test中使用start方法或者在更高层次使用uvm_config_db来传递和启动特定的sequence。接下来，我们就进入每一种方式的实操环节。

3. 方式一：使用start()方法手动启动

这是最基础、最直观的启动方式，相当于你直接调用一个方法来让sequence跑起来。

3.1start()方法的原型与参数解析

start()方法是uvm_sequence基类提供的，其原型大致如下（关注核心参数）：

virtual task start ( uvm_sequencer_base sequencer, // 指定运行本sequence的sequencer uvm_sequence_base parent_sequence = null, // 父sequence，用于构成层次 int this_priority = -1, // 优先级，数字越高优先级越高 bit call_pre_post = 1 // 是否自动调用pre_body和post_body );

• sequencer（必需）：这是最重要的参数。你必须告诉sequence，它产生的transaction要发给哪个sequencer。如果这个sequencer没有正确连接（connect）到driver，那么transaction就会卡住，这是最常见的“sequence发了数据但driver没收到”的原因之一。
• parent_sequence：如果这个sequence是作为另一个sequence（父sequence）的子sequence启动的，则需要传入父sequence的指针。这主要用于构建sequence的层次结构，方便在父sequence中控制子sequence。
• this_priority：当多个sequence同时向同一个sequencer发送transaction时，sequencer会根据这个优先级进行仲裁。默认值-1表示使用sequence实例的优先级，通常我们保持默认即可，除非有明确的仲裁需求。
• call_pre_post：如果设置为1（默认），UVM会在执行sequence的body()任务前自动调用pre_body()，在执行后自动调用post_body()。如果你希望手动控制这些回调，可以设为0。

3.2 标准调用流程与代码示例

最常见的调用场景是在test的main_phase中启动sequence。假设我们有一个简单的my_sequence和一个对应的my_sequencer。

首先，定义sequence和test：

class my_sequence extends uvm_sequence #(my_transaction); `uvm_object_utils(my_sequence) function new(string name="my_sequence"); super.new(name); endfunction virtual task body(); `uvm_info("SEQ", "Sequence body started", UVM_LOW) repeat(5) begin `uvm_do(req) // 自动创建、随机化并发送transaction `uvm_info("SEQ", $sformatf("Sent transaction %0d", req.data), UVM_HIGH) end `uvm_info("SEQ", "Sequence body finished", UVM_LOW) endtask endclass class my_test extends uvm_test; `uvm_component_utils(my_test) my_env env; my_sequencer sqr; // 假设在env中已经实例化并连接好 virtual function void build_phase(uvm_phase phase); super.build_phase(phase); env = my_env::type_id::create("env", this); endfunction virtual function void connect_phase(uvm_phase phase); super.connect_phase(phase); sqr = env.agent.sqr; // 获取sequencer的句柄 endfunction

关键部分，在main_phase中启动：

virtual task main_phase(uvm_phase phase); my_sequence seq; phase.raise_objection(this); // 提起异议，防止phase提前结束 seq = my_sequence::type_id::create("seq"); `uvm_info("TEST", "Starting sequence via start()...", UVM_LOW) seq.start(sqr); // 核心启动语句 `uvm_info("TEST", "Sequence finished.", UVM_LOW) phase.drop_objection(this); // 放下异议 endtask endclass

3.3 实操心得与避坑指南

1. raise_objection是必须的：这是新手最容易忽略导致仿真瞬间结束的坑。UVM的phase机制依靠objection来维持。在start()方法前（或同时）必须调用phase.raise_objection(this)，否则main_phase会认为没有任务需要执行，立即结束，你的sequence可能根本没来得及运行。start()是一个阻塞任务，它会一直等到sequence的body()执行完毕才返回。所以，我们通常在start()后立即drop_objection。

2. 确保sequencer句柄有效：seq.start(sqr)中的sqr必须是一个已经成功创建并连接到driver的sequencer实例。我习惯在connect_phase中将test层对sequencer的引用保存下来，如上例所示。如果sqr是null，仿真不会报错，但sequence会启动在一个“空”的sequencer上，transaction无法送达。

3. start()与fork的结合使用：如果你想并发启动多个sequence，或者让sequence在后台运行，可以使用fork。

   virtual task main_phase(uvm_phase phase); phase.raise_objection(this); fork begin seq_a.start(sqr_a); end begin seq_b.start(sqr_b); end // 或者启动同一个sequencer上的多个sequence，sequencer会仲裁 begin seq_c.start(sqr); end begin seq_d.start(sqr); end join phase.drop_objection(this); endtask

   这里要注意，fork...join会等待所有分支结束，而fork...join_none会立即继续执行后续语句。在UVM中，通常使用fork...join来确保所有激励序列完成后再结束phase。

4. Virtual Sequence的启动：Virtual sequence的启动是start()方法大显身手的地方。因为virtual sequence没有绑定的sequencer，你必须显式地传递一个virtual sequencer（或者一个普通的sequencer，但不推荐）给它。

   class my_virtual_seq extends uvm_sequence; `uvm_object_utils(my_virtual_seq) my_sequencer p_sqr; // 通过`uvm_declare_p_sequencer宏声明更规范 ... task body(); // 使用 p_sqr.abc_sqr 来启动具体的物理sequence sub_seq_on_abc.start(p_sqr.abc_sqr); endtask endclass // 在test中启动 virtual task main_phase(uvm_phase phase); my_virtual_seq vseq; phase.raise_objection(this); vseq = my_virtual_seq::type_id::create("vseq"); vseq.start(env.virt_sqr); // 启动在virtual sequencer上 phase.drop_objection(this); endtask

   这里的关键是，start()的参数是env.virt_sqr，这个virtual sequencer内部包含了指向各个物理sequencer（如abc_sqr）的句柄，从而让virtual sequence能够控制它们。

4. 方式二：设置default_sequence自动启动

这种方式将sequence的启动工作交给了UVM框架，实现了配置与执行的解耦。

4.1 原理与配置时机

default_sequence是uvm_sequencer类的一个类型参数。当你在某个component（通常是test）的build_phase中，通过uvm_config_db为该sequencer的default_sequence设置了一个sequence类型时，UVM会在该sequencer进入某个运行phase（默认为main_phase）时，自动创建该类型的sequence实例并调用其start()方法。

配置时机至关重要：必须在build_phase中设置。因为build_phase是组件层次结构构建的阶段，此时配置信息才能被正确地解析和应用到目标组件上。在connect_phase或run_phase中设置是无效的。

4.2 标准配置语法与层级覆盖

配置语法如下：

uvm_config_db#(uvm_object_wrapper)::set( this, // 上下文（context），通常是当前component的this指针 “sqr_path”, // 目标sequencer的路径（相对于context） “default_sequence”, // 字段名，固定为“default_sequence” sequence_type::get_type() // 要设置的sequence的类型（使用type_id::get_type()） );

• 上下文（this）：决定了配置信息的作用域。this指向当前component实例。
• 目标路径（“sqr_path”）：是目标sequencer在UVM层次结构中的路径，相对于上下文。这是最容易出错的地方。
  • 如果配置语句写在test中，且sequencer在env.agent.sqr，那么路径通常是“env.agent.sqr”。
  • 如果配置语句写在env中，且sequencer在agent.sqr，那么路径就是“agent.sqr”。
  • 可以使用“*”作为通配符，表示对所有匹配的sequencer生效，但需谨慎使用，以免造成意外的覆盖。

示例：在test中配置

class my_test_default extends uvm_test; `uvm_component_utils(my_test_default) my_env env; virtual function void build_phase(uvm_phase phase); super.build_phase(phase); env = my_env::type_id::create(“env”, this); // 配置my_sequence为env.agent.sqr的default_sequence uvm_config_db#(uvm_object_wrapper)::set( this, // 上下文是test本身 “env.agent.sqr”, // 目标路径：从test往下找env，再找agent，再找sqr “default_sequence”, my_sequence::get_type() ); endfunction // 注意：test的main_phase不需要手动启动sequence，也无需raise_objection（sequence会自动raise） virtual task main_phase(uvm_phase phase); // 这里可以是空的，或者执行其他监控任务 // sequence会自动启动并管理自己的objection `uvm_info(“TEST”, “Test main_phase started, sequence should auto-start.”, UVM_LOW) endtask endclass

4.3 注意事项与典型应用场景

注意：使用default_sequence时，sequence自身会在其pre_body中自动raise_objection，在post_body中自动drop_objection（前提是call_pre_post=1）。因此，在test的main_phase中，我们通常不需要再手动管理objection。这是与手动start()的一个重要区别。

1. 路径必须绝对正确：这是配置失败的最主要原因。务必使用uvm_root::get().print_topology()在仿真开始前打印UVM拓扑结构，核对sequencer的完整路径。在build_phase中，由于组件正在创建，打印拓扑可能不完整，可以在end_of_elaboration_phase中打印。

2. 配置的优先级与覆盖：uvm_config_db遵循“后设置者优先”和“更精确路径优先”的原则。这意味着，如果在更高层级（如top module）或同一层级的后面代码中，对同一个路径设置了不同的default_sequence，那么后面的配置会覆盖前面的。这为测试用例的复用提供了灵活性：一个基础test类设置了默认sequence，派生test类可以重写它。

3. 适用于稳定的主激励流：default_sequence非常适合那些作为测试平台“默认”行为的激励。例如，一个基础的、随机的数据流sequence。这样，所有继承自该基础环境的测试用例，默认都会产生这种激励，简化了测试用例的编写。

4. 无法传递sequence实例：default_sequence配置的是类型（uvm_object_wrapper），而不是实例。这意味着你不能通过这种方式传递一个已经随机化好、带有特定约束的sequence对象。如果需要传递实例，或者需要更复杂的启动控制，就需要用到第三种方式或回退到手动start()。

5. 方式三：通过uvm_config_db配置启动（进阶）

这种方式最为灵活，它结合了前两者的优点：既可以像default_sequence一样进行配置，又可以像start()一样传递对象实例并精确控制。

5.1 传递Sequence实例与动态控制

核心思想是：我们不在build_phase设置类型，而是在build_phase之后（通常在test的main_phase或run_phase），将一个已经创建并配置好的sequence实例，通过uvm_config_db“传递”给sequencer。在sequencer一侧，我们需要在合适的phase（如main_phase）去“获取”这个实例，然后手动启动它。

发送方（Test）：

class my_test_config extends uvm_test; `uvm_component_utils(my_test_config) my_env env; my_sequencer sqr; my_sequence seq; virtual function void build_phase(uvm_phase phase); super.build_phase(phase); env = my_env::type_id::create(“env”, this); endfunction virtual function void connect_phase(uvm_phase phase); super.connect_phase(phase); sqr = env.agent.sqr; endfunction virtual task main_phase(uvm_phase phase); phase.raise_objection(this); // 1. 创建并配置sequence实例 seq = my_sequence::type_id::create(“seq”); // 可以对seq进行特定的随机化或参数设置 seq.some_constraint_mode(0); // 例如，关闭某个约束 seq.some_parameter = 100; // 2. 将sequence实例通过config_db设置出去 // 字段名可以自定义，不一定是“default_sequence”，例如“run_sequence” uvm_config_db#(my_sequence)::set(this, “”, “run_sequence”, seq); // 这里路径用“”表示应用到当前上下文（this）的所有能找到该字段的地方 // 更常见的做法是指定到具体的sequencer路径，如“env.agent.sqr” `uvm_info(“TEST”, “Sequence instance set via config_db”, UVM_LOW) // 注意：此时sequence还没有启动！ phase.drop_objection(this); // 这里放下的是main_phase的objection，sequence的还未提起 endtask endclass

接收方（Sequencer或其所在的Agent/Env）： 我们需要一个地方来获取并启动这个sequence。通常，我们在sequencer所在agent的main_phase中做这件事。

class my_agent extends uvm_agent; `uvm_component_utils(my_agent) my_sequencer sqr; my_driver drv; my_sequence seq_from_config; virtual task main_phase(uvm_phase phase); // 1. 从config_db中获取sequence实例 if (uvm_config_db#(my_sequence)::get(this, “”, “run_sequence”, seq_from_config)) begin `uvm_info(“AGENT”, “Got sequence instance from config_db”, UVM_LOW) phase.raise_objection(this); // 2. 手动启动获取到的sequence实例 seq_from_config.start(sqr); phase.drop_objection(this); end else begin `uvm_info(“AGENT”, “No run_sequence config found, maybe use default”, UVM_LOW) end endtask endclass

5.2 复杂场景应用：Virtual Sequence的全局调度

这是uvm_config_db配置启动方式最具威力的应用场景，常用于构建高度可复用和可控制的验证环境。典型模式是：Test创建并配置Virtual Sequence -> 通过config_db传递给Env -> Env中的Virtual Sequencer获取并启动它。

第一步：定义Virtual Sequence和Virtual Sequencer

// Virtual Sequencer：主要作用是集成各个物理sequencer的句柄 class my_virtual_sequencer extends uvm_sequencer; `uvm_component_utils(my_virtual_sequencer) my_sequencer eth_sqr; // 以太网接口sequencer my_sequencer pcie_sqr; // PCIe接口sequencer function new(string name, uvm_component parent); super.new(name, parent); endfunction endclass // Virtual Sequence：协调多个物理sequence class top_virtual_sequence extends uvm_sequence; `uvm_object_utils(top_virtual_sequence) `uvm_declare_p_sequencer(my_virtual_sequencer) // 声明p_sequencer类型 eth_sequence eth_seq; pcie_sequence pcie_seq; function new(string name=“top_virtual_sequence”); super.new(name); endfunction virtual task body(); `uvm_info(“VSEQ”, “Starting top virtual sequence”, UVM_LOW) // 并发启动两个接口的sequence fork begin eth_seq = eth_sequence::type_id::create(“eth_seq”); eth_seq.start(p_sequencer.eth_sqr); end begin pcie_seq = pcie_sequence::type_id::create(“pcie_seq”); pcie_seq.start(p_sequencer.pcie_sqr); end join `uvm_info(“VSEQ”, “Top virtual sequence finished”, UVM_LOW) endtask endclass

第二步：在Env中集成Virtual Sequencer并连接

class my_env extends uvm_env; `uvm_component_utils(my_env) my_virtual_sequencer virt_sqr; eth_agent eth_agt; pcie_agent pcie_agt; virtual function void build_phase(uvm_phase phase); super.build_phase(phase); virt_sqr = my_virtual_sequencer::type_id::create(“virt_sqr”, this); eth_agt = eth_agent::type_id::create(“eth_agt”, this); pcie_agt = pcie_agent::type_id::create(“pcie_agt”, this); endfunction virtual function void connect_phase(uvm_phase phase); super.connect_phase(phase); // 将物理sequencer的句柄赋值给virtual sequencer virt_sqr.eth_sqr = eth_agt.sqr; virt_sqr.pcie_sqr = pcie_agt.sqr; endfunction endclass

第三步：Test通过config_db传递并触发（推荐在run_phase）

class complex_test extends uvm_test; `uvm_component_utils(complex_test) my_env env; top_virtual_sequence top_vseq; virtual task run_phase(uvm_phase phase); phase.raise_objection(this); // 1. 创建并配置virtual sequence top_vseq = top_virtual_sequence::type_id::create(“top_vseq”); // 可以对top_vseq进行参数配置 top_vseq.some_global_param = 1; // 2. 将virtual sequence实例设置到virtual sequencer的路径上 // 字段名可以约定为“vseq”或“top_sequence” if (!uvm_config_db#(top_virtual_sequence)::set(this, “env.virt_sqr”, “vseq”, top_vseq)) begin `uvm_fatal(“CFGERR”, “Failed to set virtual sequence via config_db”) end `uvm_info(“TEST”, “Virtual sequence instance set, waiting for env to pick it up...”, UVM_LOW) // 3. 可以在这里等待一段时间，或者等待一个事件，确保env已经获取并启动了sequence // 一个简单的同步方法是让virtual sequence在结束时设置一个事件 #1000; // 示例：等待一段时间 phase.drop_objection(this); endtask endclass

第四步：Env（或一个专用的启动组件）获取并启动Virtual Sequence通常，我们会在Env的run_phase中增加一个任务来专门处理这个启动逻辑。

class my_env extends uvm_env; // ... 其他成员和build/connect phase同上 top_virtual_sequence vseq_from_cfg; virtual task run_phase(uvm_phase phase); super.run_phase(phase); // 调用父类 // 启动一个并行的进程来处理virtual sequence fork begin phase.raise_objection(this, “Starting virtual sequence”); // 尝试从config_db获取virtual sequence实例 if (uvm_config_db#(top_virtual_sequence)::get(this, “”, “vseq”, vseq_from_cfg)) begin `uvm_info(“ENV”, “Got virtual sequence, starting...”, UVM_LOW) vseq_from_cfg.start(virt_sqr); // 关键：启动在virtual sequencer上 end else begin `uvm_info(“ENV”, “No virtual sequence config, skipping.”, UVM_LOW) end phase.drop_objection(this, “Virtual sequence finished”); end join_none // 使用join_none，不阻塞env的run_phase endtask endclass

这种模式的优点是解耦彻底：Test只负责生成激励策略（virtual sequence），完全不关心底层sequencer如何连接。Env负责提供平台和启动机制。两者通过uvm_config_db这个标准接口通信，极大提升了代码的复用性和可维护性。在大型项目中，这是管理复杂激励场景的推荐架构。

6. 三种方式对比与混合使用策略

为了更直观地对比，我将三种方式的核心特性总结如下表：

在实际项目中，几乎没有哪个验证平台会只使用一种方式。混合使用才是最佳实践。我个人的策略通常是：

1. 基础数据流：为每个主要的物理接口sequencer设置一个default_sequence，比如一个简单的随机数据生成sequence。这保证了即使没有特定测试用例，环境也能产生基本激励进行冒烟测试。
2. 测试用例特定激励：在具体的test类中，使用uvm_config_db来覆盖default_sequence或者传递特定的sequence实例。对于简单的用例，直接覆盖default_sequence类型；对于复杂的、需要预配置的用例，则创建实例并通过config_db传递。
3. 系统级协调：对于涉及多个接口协同的场景，必然使用Virtual Sequence。采用“Test创建实例 -> config_db传递 -> Env中获取并启动”的模式。这是保持架构清晰的关键。
4. 局部动态控制：在某个sequence的body()任务内部，如果需要动态启动另一个子sequence，毫无疑问使用start()方法。

7. 常见问题排查与调试技巧实录

即使理解了原理，在实际操作中还是会遇到各种问题。下面是我在项目中总结的几个典型问题及其排查思路。

7.1 Sequence未启动或Transaction未发送

这是最普遍的问题。排查思路如下：

1. 检查Objection：这是第一嫌疑点。如果phase因为没有人raise_objection而提前结束，sequence根本没机会运行。确保在启动sequence的phase中提起了objection。

   • 对于start()方法，你需要手动raise_objection。
   • 对于default_sequence，确保sequence的pre_body/post_body被调用（call_pre_post=1），它们会自动管理。
   • 对于config_db方式，检查获取并启动sequence的地方是否提起了objection。

2. 检查Sequencer连接：seq.start(sqr)中的sqr必须是一个已经成功连接到driver的sequencer。在connect_phase结束后，使用uvm_root::get().print_topology()打印拓扑，确认agent、sequencer、driver的层次关系正确。同时，在agent中检查sequencer和driver的TLM端口是否正确连接（driver.seq_item_port.connect(sequencer.seq_item_export)）。

3. 检查Sequence路径（针对default_sequence）：确认uvm_config_db::set中的路径字符串完全正确。最可靠的方法是在end_of_elaboration_phase中打印完整拓扑进行比对。路径是大小写敏感的。

4. 使用UVM调试信息：在sequence的new()、pre_body、body、post_body以及test的main_phase中加入uvm_info打印，观察执行流。如果body都没进入，问题出在启动环节；如果进入了body但没看到transaction发送，检查uvm_do宏或start_item/finish_item的使用。

7.2 关于pre_body和post_body的调用

这是一个容易混淆的点。pre_body和post_body是否被调用，取决于start()方法的call_pre_post参数和sequence的启动上下文。

• 当通过sequence.start(sequencer, parent_seq, priority, call_pre_post)启动，且call_pre_post=1（默认）时，pre_body和post_body会被调用。
• 当作为default_sequence自动启动时，call_pre_post通常为1，因此也会被调用。
• 但是，如果这个sequence是作为另一个sequence的子sequence，通过uvm_do宏或start_item/finish_item调用的，那么它的pre_body和post_body不会被调用！只有顶层的、直接启动的sequence才会调用这两个任务。

如果你在pre_body中放置了重要的初始化代码，但在子sequence中失效了，这就是原因。解决方案是将初始化代码移到body()任务的开头。

7.3 多Sequence启动的仲裁与同步

当多个sequence同时向同一个sequencer发送transaction时，sequencer的仲裁机制开始工作。除了start()时的优先级参数，更常见的同步方式是使用uvm_event或uvm_barrier。

• uvm_event：用于点对点或一对多的通知。例如，Sequence A完成某个关键操作后，触发一个事件，Sequence B等待这个事件后再开始发送特定transaction。

  // 在某个共享的配置对象或env中定义 uvm_event sync_ev = new(“sync_ev”); // Sequence A中 task body(); // ... 做一些操作 sync_ev.trigger(); // ... 继续 endtask // Sequence B中 task body(); sync_ev.wait_trigger(); // 收到事件后开始操作 // ... endtask

• uvm_barrier：用于多线程同步，等待所有参与者到达屏障点。例如，需要三个sequence同时准备好后才能发起一次联合操作。

  uvm_barrier joint_barrier = new(“joint_barrier”, 3); // 需要3个参与者 // 在每个sequence中 task body(); // ... 准备阶段 joint_barrier.wait(); // 屏障解除，开始联合操作 // ... endtask

7.4 使用`uvm_info宏跟踪执行流

在复杂的sequence启动场景中，尤其是混合使用多种方式时，在关键节点添加详细的uvm_info日志是最高效的调试手段。我通常会为不同的组件和sequence设置不同的UVM_HIGH或UVM_DEBUG级别信息，在需要调试时，通过命令行+UVM_VERBOSITY=UVM_HIGH来打开它们，像看流程图一样追踪整个激励生成和调度的过程。这比漫无目的地看波形要直接得多。

最后，再分享一个我踩过的坑：在一次使用config_db传递virtual sequence实例的项目中，test里设置了实例，但env里始终获取不到。排查了半天，发现是test中set的路径是“env.virt_sqr”，而env中get的上下文是this（即env本身），路径是“”，这会导致UVM在env这个作用域下寻找字段“vseq”，但实例是设置在env.virt_sqr路径上的。解决方法有两种：一是在env中get时使用完整路径“virt_sqr”作为第二个参数；二是test在set时，将上下文设置为uvm_root::get()，路径设置为“*.virt_sqr”，但这不够精确。最终我采用了在env的run_phase里，用uvm_config_db::get(null, “”, “vseq”, vseq)进行全局获取。这个经历让我深刻理解了uvm_config_db中上下文和路径参数的相对性，在跨层次传递时，一定要仔细核对。