4、异常场景定义：什么是异常场景、与正常场景的区别、常见异常场景（复位、中断、总线错误、超时、数据损坏等）

在UVM验证方法学中，异常场景（Exception Scenario）是指那些偏离正常协议规范、时序要求或功能预期的输入序列、系统状态或环境条件。与正常场景（Happy Path）相比，异常场景的核心价值在于验证DUT（Design Under Test）在非理想条件下的鲁棒性、恢复能力和错误处理机制。一个设计如果仅在正常路径下工作良好，而在复位抖动、总线毛刺、数据超时或中断风暴中崩溃，那么它在真实SoC系统中几乎不具备可靠性。本章将系统定义异常场景的边界，剖析其与正常场景的本质差异，并深入拆解五类最常见的异常场景：复位异常、中断异常、总线错误、超时异常和数据损坏，为后续章节的注入方法打下概念基础。

4.1 异常场景的核心定义与本质特征

异常场景在UVM验证语境下，是指通过sequence或driver主动向DUT施加的、违反协议规范或系统正常操作条件的激励序列，以及通过interface或virtual sequence注入的故障条件。其本质是对DUT错误处理能力的压力测试。一个完整的异常场景包含三个要素：异常注入条件（如拉低复位信号100ns）、DUT响应行为（如状态机跳转到复位态）、最终恢复状态（如重新初始化完成）。异常场景的设计必须基于协议规范和系统架构文档，而非随意构造。

4.2 正常场景与异常场景的多维度对比

对比维度	正常场景	异常场景
协议合规性	完全符合协议时序、电平、数据格式	故意违反或处于协议边界条件
激励目的	验证功能正确性	验证容错、恢复、报告能力
时序特征	建立/保持时间满足，时钟稳定	异步事件、毛刺、时钟抖动、超时
数据完整性	数据内容与CRC/校验一致	数据位翻转、CRC错误、数据包丢失
覆盖率目标	功能覆盖率（FC）	异常覆盖率（EC）、故障注入覆盖率
调试难度	低，波形可预测	高，需要结合日志、断言、波形交叉分析
验证时间	短，通常为1-2个burst	长，需要等待超时或恢复过程

从验证策略角度看，正常场景是“证明设计能做正确的事”，而异常场景是“证明设计在错误条件下不会崩溃或能优雅降级”。两者在UVM testbench中的实现路径不同：正常场景通常通过简单的sequence产生，而异常场景需要专门的异常sequence、故障注入模型（如uvm_objection控制时序）以及更复杂的scoreboard比对策略（允许特定错误码或状态跳转）。

4.3 常见异常场景深度拆解

4.3.1 复位异常

复位异常是SoC验证中最基础也最关键的异常类型。它不仅仅包括简单的“拉低复位信号”，而是涵盖多种边界情况：异步复位（复位信号在时钟上升沿附近变化，导致亚稳态）、复位毛刺（复位信号短暂抖动，小于最小脉宽要求）、复位释放时序违规（复位释放时刻不满足与时钟沿的建立/保持时间）、部分复位（仅复位子模块，而其他模块保持运行）。

判断复位异常是否被正确响应，需要检查：DUT是否进入确定的复位状态、复位释放后是否完成正确的初始化序列、内部状态机是否从IDLE开始、FIFO是否被清空、寄存器是否恢复默认值。在UVM中，复位异常的注入通常通过修改interface中的reset_n信号驱动时序实现，或者使用uvm_sequence中的body()任务来控制复位信号的拉低和释放时刻。

4.3.2 中断异常

中断异常在中断控制器（INTC）和CPU子系统验证中尤为重要。常见的中断异常包括：中断风暴（在极短时间内产生大量中断请求，超过DUT的处理能力）、中断丢失（高优先级中断抢占低优先级中断，导致低优先级中断被延迟或丢失）、中断嵌套（在中断服务程序执行期间再次触发同级别或更高级别中断）、伪中断（中断信号毛刺导致误触发，但中断状态寄存器无对应标志）。

中断异常的验证难点在于：中断响应是异步的，且与软件执行流相关。在UVM中，通常通过虚拟接口（virtual interface）模拟中断引脚的行为，使用fork...join_any或wait语句来同步中断事件。验证中断异常时，需要特别关注中断延迟（从请求到响应的周期数）是否在可接受范围内，以及中断处理完成后是否清除了正确的状态位。

// 中断风暴注入示例（简化）
class intr_storm_seq extends uvm_sequence #(intr_item);
  virtual task body();
    repeat(100) begin // 连续产生100个中断请求
      req = intr_item::type_id::create("req");
      req.intr_type = INTR_GPIO;
      start_item(req);
      finish_item(req);
      #10; // 仅间隔10ns，模拟风暴
    end
  endtask
endclass

4.3.3 总线错误

总线错误是AHB/AXI/APB等总线协议验证中的核心异常场景。典型的总线错误包括：地址越界（访问不存在的地址空间，如保留地址或未映射的外设）、协议违例（如突发传输长度超过限制、未对齐访问、在错误阶段发出控制信号）、仲裁异常（多个主机同时请求总线，但仲裁逻辑未按优先级响应）、从机错误响应（从机返回ERROR响应，但主机未正确处理）。

总线错误的验证需要结合协议规范中的错误响应机制。例如，在AXI协议中，从机可以通过RRESP或BRESP信号返回SLVERR或DECERR。验证时，需要构造一个从机模型（slave model），使其在特定地址或特定条件下返回错误响应，然后检查主机（DUT）是否正确处理了该错误（如终止传输、记录错误状态、触发中断）。

4.3.4 超时异常

超时异常是指DUT在预期时间内未收到响应或未完成操作。常见的超时场景包括：外设无响应（如SPI从机未拉低CS或未返回数据）、DMA传输超时（传输未在指定周期内完成）、等待状态卡死（总线协议中的等待状态信号一直有效，导致传输无法完成）、看门狗超时（软件未在窗口期内喂狗，导致系统复位）。

超时异常的验证需要精确控制时间参数。在UVM中，可以使用#delay或wait(condition, timeout)语句来模拟超时条件。验证超时异常时，需要检查DUT是否产生了正确的超时中断或错误标志，以及超时后的恢复行为（如重试、放弃传输、进入安全模式）。

4.3.5 数据损坏

数据损坏异常关注数据在传输或存储过程中发生的位错误。常见的数据损坏包括：数据位翻转（由于串扰、电源噪声或信号完整性导致）、CRC/校验错误（数据内容与校验字段不匹配）、数据包丢失（在FIFO溢出或总线仲裁失败时）、数据顺序错乱（在乱序传输的协议中，如AXI的out-of-order传输）。

数据损坏的注入通常通过修改数据通道的约束来实现。例如，在UVM sequence中，可以在数据发送前故意翻转某些位，或者修改CRC字段。验证数据损坏时，需要检查DUT是否能够检测到错误（通过CRC校验、奇偶校验等），并采取正确的行动（如请求重传、丢弃数据包、记录错误日志）。

4.4 异常场景的验证策略与案例拆解

以一个典型的I2C控制器验证为例，说明异常场景的完整验证流程。假设DUT是一个I2C主机控制器，需要验证其从机无响应时的超时处理能力。

阶段	操作内容	关键参数/条件
初始条件	配置I2C控制器为主机模式，目标从机地址0x50	时钟频率100kHz，超时阈值1ms
异常注入	在sequence中，发送START + 地址字节后，强制SCL保持高电平（模拟从机拉低SCL等待）	SCL高电平持续时间超过1ms
DUT响应	I2C控制器应检测到SCL长时间为高，触发超时中断，并释放总线	检查中断状态寄存器bit[3] = 1
恢复验证	软件清除中断标志后，重新发起传输	第二次传输应正常完成
结果比对	scoreboard检查：超时中断是否在1ms±10%内产生，总线是否释放，后续传输是否成功	时间窗口：0.9ms ~ 1.1ms

在这个案例中，异常场景的验证不仅仅是注入一个超时条件，还需要验证超时后的恢复路径。如果DUT在超时后没有正确释放总线，后续的传输将永远无法进行。因此，异常场景的验证必须形成“注入→响应→恢复→再验证”的闭环。

4.5 常见误区与总结复盘