为何UVM中uvm_driver非抽象类而uvm_sequence是抽象类？

首先看给出的UVM类定义代码：

virtual class uvm_env extends uvm_component;
virtual class uvm_scoreboard extends uvm_component;
virtual class uvm_monitor extends uvm_component;

class uvm_sequencer #(type REQ=uvm_sequence_item, RSP=REQ) 
                    extends uvm_sequencer_param_base #(REQ, RSP);

class uvm_driver #(type REQ=uvm_sequence_item,
                   type RSP=REQ) extends uvm_component;

virtual class uvm_sequence #(type REQ = uvm_sequence_item,
                             type RSP = REQ) extends uvm_sequence_base;

针对问题中提到的参数化类抽象性差异，核心原因在于类的设计定位与职责不同：

一、uvm_sequence 为何是抽象类 #

• 激励逻辑的强定制需求：sequence的核心工作是生成适配具体DUT的激励序列，不同项目、不同DUT的激励逻辑完全不同，UVM框架无法提供通用的默认实现。将其设为抽象类，强制用户必须继承并实现自己的激励逻辑。
• 框架定义的强制接口：uvm_sequence内部包含body()这类纯虚方法，这些方法是框架调用用户激励逻辑的入口，没有默认实现，必须由用户重写才能完成功能，因此类本身必须标记为virtual（抽象类）。

二、uvm_sequencer 和 uvm_driver 为何不是抽象类 #

uvm_sequencer #

• 通用调度逻辑已实现：sequencer的核心职责是管理sequence的执行、仲裁激励请求、转发REQ/RSP事务，这些逻辑是UVM框架的通用机制，与具体DUT无关。框架已经完成了完整的调度、仲裁代码实现，用户只需实例化并配置参数，无需重写核心逻辑，因此不需要设为抽象类。
• 参数化仅适配数据类型：其参数化只是为了兼容不同的REQ/RSP事务类型，内部核心逻辑不依赖具体事务内容，通用实现完全可行。

uvm_driver #

• 基础交互逻辑通用：driver的核心工作包括与sequencer通信获取事务、返回响应，UVM框架已经实现了get_next_item()、item_done()等通用交互方法，这些逻辑不依赖具体DUT的引脚行为。
• 定制部分为可选扩展：虽然用户需要实现引脚级的信号驱动逻辑，但框架将这部分设计为可重写的普通方法（而非纯虚方法）。用户可以直接继承uvm_driver，仅重写特定方法完成定制，无需强制实现所有内容，因此类本身不需要是抽象类。

内容的提问来源于stack exchange，提问作者AnuragChauhan