得验笔记-CSDN博客

原创 DV 工程架构中，多态（Polymorphism）的应用

SystemVerilog中的多态通过父类句柄调用子类方法，核心价值在于解耦架构。它实现了三个关键优势：1）统一接口屏蔽差异，使上层容器无需关心具体对象类型；2）分离框架与实现，让UVM等框架能调用未知的用户代码；3）支持运行时动态配置，通过工厂模式灵活切换实现类。这种机制如同标准插座供电不同电器，既保持接口统一又允许具体行为多样化，避免修改核心代码即可扩展功能，是构建灵活验证环境的基础。

2026-05-01 13:09:36 359

原创验证的道与术：在硅片的确定性中，寻找不确定性的边界

《验证工程师的修行之道：在混沌中建立秩序》芯片验证的本质是建立信任的过程，而非单纯的技术执行。面对指数级增长的复杂度，验证工程师的核心使命是通过有限的资源逼近确定性，扮演系统质疑者的角色。当前UVM等验证方法虽然笨重，但其标准化机制解决了人性不可靠的问题——约束随机验证弥补思维盲区，覆盖率量化取代主观判断，模块化解耦管理复杂状态。行业正在进化：形式验证用数学穷尽路径，软件驱动验证贴近真实场景，Python混合编程提升灵活性。验证工程师的真正价值在于系统性思维和批判精神，而非工具本身。技术会迭代，但对确定

2026-04-25 18:39:03 371 1

原创从软件架构视角解码 UVM：它到底是什么？能做什么？不能做什么？

UVM 不是软件框架，但软件架构思维能帮我们看清它的抽象意图、识别它的实现妥协、规避它的语义陷阱。当我们用 IoC、Pub-Sub、State Machine 的语言拆解 UVM 时，不是为了强行套用软件范式，而是为了建立可验证、可推导、可复现的验证环境设计纪律。

2026-04-19 18:32:45 356

原创【验证技能树】UVM 源码解读13 -- config_db 为什么只在某些 phase 里“安全”？—— Run-time 配置的时间语义

摘要： UVM 的 config_db 机制本质是构建期参数注入系统，而非运行时变量表。其安全性严格依赖于 UVM phase 时间轴：build_phase 是配置黄金窗口（组件未定型），connect_phase 边界收紧（仅影响局部行为），run_phase 后则存在高风险（热插参数导致状态不一致）。源码表明 config_db 不保证运行时同步性，且与 factory override 存在时序耦合。核心准则是：结构配置（如组件特性）应限于 build 阶段，行为控制（如测试场景）应通过 seque

2026-01-21 23:26:15 506

原创计算机系统、编程和调试中有大量广为人知的“魔数”（Magic Numbers），你都知道哪些?

计算机系统中存在许多有趣的“魔数”（Magic Numbers），主要用于调试、文件标识和协议识别。常见调试标记如0xDEADBEEF（内存释放标记）、0xCCCCCCCC（未初始化栈内存）；文件标识如0x504B0304（ZIP文件）、0x89504E47（PNG图像）；还有程序员幽默如0x1337C0DE（Leet Code）。这些魔数设计醒目、易记，在异常检测和格式识别中发挥重要作用，兼具实用性和趣味性。

2026-01-20 22:22:49 405

原创【验证技能树】从验证视角，真正理解 AMBA CHI 04 ——Snoop 与 Directory 的真实边界

摘要： CHI协议中，Snoop与Directory的交互是验证关键点。常见误区是将Directory等同于Cache状态表，但Directory的核心职责是提供一致性裁决所需的最小信息（如地址持有者、一致性语义）。Snoop的本质是系统级指令而非询问，其正确性由SnoopRsp决定。高频错误包括Directory过期、Snoop抑制条件错误及SnoopRsp语义不完整。验证应聚焦系统状态一致性（如避免多Unique、Directory与Cache状态冲突）。Directory的设计目标是通过结构化裁决确保

2026-01-18 00:58:22 637

原创【验证技能树】UVM 源码解读12 -- Sequencer，Sequence 的真实角色

摘要： UVM将激励（stimulus）设计为“可调度对象”，核心目的是在SoC级验证中建立主动侧的秩序。Sequencer作为调度中心，负责多Sequence的仲裁、优先级管理及生命周期控制，而非简单的数据通道。这种设计将“行为定义”（Sequence）与“执行调度”（Sequencer）分离，解决了多Master并发、跨Agent协同等复杂场景下的资源竞争问题。Virtual Sequence进一步实现跨Agent的行为编排，而Phase绑定使激励融入验证生命周期管理。该架构并非冗余，而是为应对未来系统

2026-01-13 21:09:57 541

原创【验证技能树】从验证视角，真正理解 AMBA CHI 03 -- 从一次 Load Miss，看懂 CHI 的一致性交易

摘要：本文深入剖析CHI协议中一次Load Miss的完整流程，聚焦工程实践中的关键验证点。从Request Node发起读请求开始，详细解析Home Node的一致性裁决机制，重点讨论Snoop的必要性及其系统级意义。文章强调CHI协议将数据流动与状态承诺分离的设计理念，指出验证工程师应关注状态转换的不变量而非时序巧合。通过拆解"Req→裁决→Snoop→Dat→Rsp"的完整链路，揭示CHI用结构复杂度换取系统确定性的本质，为RISC-V/CPU/SoC验证提供实践指导。

2026-01-10 23:18:51 897

原创【验证技能树】UVM 源码解读11 -- TLM2 —— Blocking vs Non-blocking 背后的建模取舍

摘要： TLM2中的Blocking与Non-blocking接口本质区别在于建模目标：Blocking（如b_transport）适用于功能正确性验证，简化独占场景建模；Non-blocking（如nb_transport）通过状态机分阶段描述时序与资源竞争，解决系统级并发问题。实际工程中，多数验证因聚焦功能而非系统行为而优先选择Blocking，但NoC、Cache等复杂场景需Non-blocking避免模型失真。TLM2的设计复杂度是为系统级真实性服务的必要代价，其价值在于为未来架构验证预留能力。选择

2026-01-10 00:00:13 678

原创【验证技能树】UVM 源码解读10 --TLM 是通信机制，还是架构边界？

摘要： UVM TLM 的核心价值并非简单的数据通信，而是通过严格的架构约束实现组件解耦。源码分析揭示，TLM 通过 port/export/imp 机制强制实现依赖倒置，使数据流向独立于层级结构。例如，analysis_port 的单向广播特性从设计上禁止监控逻辑反向干预DUT，体现了“观察者模式”的架构意图。UVM TLM 的复杂性实质是防止不良架构（如跨层调用、状态耦合）的防御性设计，其本质是以通信接口为表象的验证架构规范。当验证环境复杂度达到一定规模时，这种约束的价值才会充分显现。

2026-01-06 23:11:13 1089

原创【验证技能树】UVM 源码解读09 -- Configuration DB 是好设计吗？一个被滥用的全局状态系统

文章探讨了UVM中Config DB的设计初衷与工程实践中的误用问题。Config DB作为层次化配置传递的解决方案，其核心价值在于避免参数爆炸并支持组件复用，而非作为全局状态管理工具。源码分析表明，Config DB通过精确的作用域匹配和覆盖规则实现可控配置传递。但实际工程中常因三种误用导致问题：传递运行时状态、随意设置所有权、过度依赖通配符。正确使用需遵循四大原则：仅传递初始化配置、明确配置所有者、限定作用域范围、将其视为正式接口而非快捷通道。成熟的验证环境应保持Config DB用法的克制与规范，使其

2026-01-03 22:51:52 600

原创【验证技能树】从验证视角，真正理解 AMBA CHI 02 -- 为什么要拆成五条通道？

CHI协议将事务拆分为Req、Rsp、Dat、Snoop、SnoopRsp五条通道，看似复杂实则解决了多核SoC的关键问题。这种设计将请求、裁决、数据、侦听和响应职责分离，使系统在并发访问、多级缓存和严格一致性要求下仍能保持可控。五通道明确了各环节的边界，让死锁分析、乱序处理和验证变得更加结构化，为复杂SoC提供了可证明正确的框架。这种拆分不是增加复杂度，而是将固有复杂性显式化，最终提升系统的可验证性和扩展性。

2026-01-03 14:00:04 536

原创【验证技能树】从验证视角，真正理解 AMBA CHI 01 -- 为什么 SoC 需要 CHI？

摘要：多核SoC设计中，传统总线架构（如ACE）采用广播式snoop机制，在核数增多时面临snoop流量爆炸、延迟不可控和验证复杂度激增等问题。AMBA CHI协议通过引入Home Node和Directory机制，将一致性管理从分布式协商转变为集中式裁决，明确数据归属并精准控制snoop范围，显著降低系统复杂度。其多通道设计（Req/Rsp/Dat等）支持高并发乱序操作，同时保障逻辑正确性。验证重点从信号对齐转向系统不变量维护（如数据唯一性）。当SoC规模超出直觉调试能力时，CHI通过结构化协议实现可控

2026-01-02 12:43:06 927

原创 CPU 验证中，C 代码与（SV）验证环境之间需要双向同步

摘要：CPU验证中C代码与SystemVerilog/UVM环境的双向同步是关键需求，通常通过共享内存+轮询机制实现。主流方法采用预留同步地址和magic value协议：C代码写入特定值通知SV状态，SV通过backdoor/frontdoor访问监控该地址。实现包含定义同步协议、SV轮询监听、双向交互（如中断触发）等步骤，推荐优先使用backdoor访问以提高效率。高级方案如DPI-C适用于快速原型但可移植性差。最佳实践需考虑场景特性，注意避免忙等待、确保内存一致性，并遵循清晰协议设计。该技术是CPU/

2026-01-02 12:39:08 1076

原创【验证技能树】UVM 源码解读05 -- 深入 Phase 调度链路

摘要： UVM Phase 是一个分布式调度系统，以 Phase 为节点、component tree 为作用域，通过任务/函数执行单元实现层级化调度。Phase 分为 function phase（顺序不可阻塞，如 build）和 task phase（并行可阻塞，如 run），通过 execute() 统一调度。其核心机制包括状态推进、回调派发、DFS 遍历及 objection 同步，实现多组件并行与协同。Phase 与 Hierarchy 结合形成时空调度，支撑复杂 SoC 验证的扩展性。理解 Ph

2025-12-31 23:20:18 912

原创【验证技能树】UVM 源码解读08 -- Factory 机制真的有必要吗？—— 一个被误解的依赖反转设计

摘要：本文深入剖析UVM Factory的设计本质，指出其核心价值并非简单的对象创建，而是实现验证框架层面的依赖反转（IoC）。通过源码分析揭示Factory通过接管对象创建时机，解耦高层结构与底层实现，使验证环境成为可配置系统。文章对比直接new与Factory创建方式的差异，强调Factory在大型项目中管理依赖关系、支持灵活override的关键作用，同时指出其在小型稳定项目中收益不明显的合理性。最后提出工程实践建议：根据项目实际复杂度选择性使用Factory，在base class和可变点采用，稳定

2025-12-31 23:14:13 772

原创【验证技能树】UVM 源码解读06 -- Objection 的完整源码解剖

Objection 本身是一个 object，而不是 component。它是“机制”，不是“参与者”它不跑 phase，只服务 phaseObjection 不是计数器，而是一个：以 component hierarchy 为传播路径、以 phase 生命周期为边界、以“协商结束”为目标的分布式同步协议。

2025-12-21 23:07:04 707

原创【验证技能树】UVM 源码解读07 -- UVM 为什么要设计 Phase Domain？这是为 SoC 而生的调度系统

所有结论，默认都——Power / Reset 场景只是这个框架的一个自然应用。

2025-12-20 22:41:17 912

原创【验证技能树】UVM 源码解读04 -- `uvm_component` 源码解读

如果说uvm_object定义了 UVM 的“数据模型”，那么定义的，就是。UVM 中所有真正“活着”的东西：最终都继承自。理解，不是理解某个类，而是理解。

2025-12-20 00:25:56 815

原创【验证技能树】UVM 最核心的设计哲学是什么？

摘要： UVM的核心设计哲学是将验证代码转化为可长期维护的验证系统，其架构基于四个关键原则：控制反转（通过工厂模式实现组件替换）、抽象层次分离（严格划分职责边界）、验证代码资产化（支持跨项目复用）以及调试优先（牺牲性能换取可追踪性）。UVM的复杂性源于其面向大规模SoC验证的工程目标，本质是一个融合面向对象、事件驱动和分层抽象的“验证操作系统内核”，旨在解决验证复杂度爆炸问题，而非追求短期开发效率。

2025-12-16 22:41:49 495

原创【验证技能树】UVM 源码解读03 -- uvm_object 源码解读

所有 object 派生自uvm_objectuvm_void是一个 UVM 内部占位基类（相当于“无意义基类”）保持类型可替换性（factory）让验证环境能在不同项目、不同层级中复用让 VIP 可以用 override 替换，不影响上层代码建立统一的数据操作接口copy/clone/compare/print 在 SoC 级调试中极其关键将这些逻辑抽象出来，避免用户重复发明轮子对象轻量化，不参与组件调度使 transaction 类更加稳定、可复用。

2025-12-16 22:38:44 929

原创为什么 RISC-V 的特权架构，是理解 RISC-V 的入口？

摘要： RISC-V特权架构是处理器设计的核心，定义了安全隔离与系统抽象的关键机制。其简洁设计围绕三层特权模式（M/S/U）、CSR寄存器、异常/中断、虚拟内存和SBI接口五大支柱展开，直接影响CPU验证、OS开发及SoC设计。工程师需通过“三遍读法”掌握其结构、关键路径与代码映射，从而构建体系化认知，解决黑盒问题并提升架构思维能力。理解特权架构是深入RISC-V系统设计、验证和优化的必经之路。

2025-12-01 21:02:11 862

原创【验证技能树】UVM 源码解读02 -- UVM 框架鸟瞰

摘要： UVM通过面向对象设计、事务层抽象(TLM)、工厂模式和覆盖率驱动构建验证框架。其类层次分为uvm_object（数据对象）和uvm_component（组件树与生命周期），分别支持事务建模和验证环境构建。源码按功能模块化，核心机制（工厂、Phase、TLM等）集中在base/目录，标准组件位于comps/。UVM实现了四大设计模式： OOP：通过uvm_object/uvm_component的继承与虚函数提供扩展点；工厂模式：由uvm_factory和宏（如uvm_object_utils）实

2025-09-30 09:32:34 961

原创【体系结构】ARM版 - RAS 概述

文章摘要 RAS（可靠性、可用性、可维护性）是计算机系统关键特性。Arm架构通过RAS扩展提供错误处理框架，包括异常报告机制、错误同步指令（ESB）和标准化错误记录。错误分为可纠正（CE）、不可恢复（UEU）等类型，通过检测、纠正和隔离机制减少系统失效。RAS支持从基本错误复位到复杂恢复方案，帮助构建高可靠系统。

2025-09-22 22:21:44 1230

原创【验证技能树】UVM 源码解读01 -- UVM本质上就是软件工程方法论在芯片验证领域的应用

文章摘要： UVM（通用验证方法学）是基于SystemVerilog的芯片验证框架，采用组件化、面向对象和事务级抽象设计。其核心在于职责分离与数据流，通过Driver、Monitor、Sequencer等模块协作实现高效验证。UVM强调复用性、可扩展性和可维护性，类似软件工程的模块化与低耦合原则。理解其体系结构比记忆API更重要，有助于灵活组合组件并提升验证效率。UVM不仅是工具，更融合了软件工程思维，推动验证工作向自动化、系统化发展。掌握UVM底层逻辑能优化验证环境设计，适用于从IP到SoC的多层级验证场

2025-09-21 16:26:15 969

原创【验证技能树】验证工程师一定需要的：最小可执行 Testbench（Minimal Executable Testbench）

摘要：最小可执行测试平台（MEB）是解决复杂SoC验证痛点的轻量化方案。它仅包含时钟、DUT、驱动和监控四个核心模块，通过极简代码实现快速验证。相比传统UVM验证环境，MEB在环境搭建、接口调试、问题复现和学习场景中具有显著优势。文章提供了加法器验证的MEB实例，包含单文件仿真、波形查看和Makefile模板，并强调"先跑通闭环"的验证哲学。这种最小化思维不仅适用于芯片验证，对职业发展中的核心能力验证也具有启发意义。

2025-09-19 22:38:38 418

原创 IC工程师 Linux 命令速查表 [持续更新中...]

本文总结了VLSI工程师常用的Linux终端命令，分为四大类：1）基本操作（ls、cd、cp等目录文件管理）；2）文件与文本处理（find、grep、less等搜索查看工具）；3）资源监控（du、top、ps等系统状态查看）；4）协作交付（tar、scp、git等打包传输与版本控制）。这些命令覆盖了日常RTL开发、仿真调试、日志分析和团队协作的典型场景，如查看仿真log、定位信号定义、监控系统资源等，是VLSI工程师高效工作的必备技能。特别提醒rm -rf等危险命令需谨慎使用。

2025-09-10 22:30:37 245

原创【嵌入式编程】static、volatile和extern 关键字的重要性

当你在与微控制器（MCU）一起工作时，浏览代码库时，很难忽略这些关键字。

2024-06-19 21:27:45 549

原创【CPU 多核技术】一文带你看懂CPU多核技术- 发展历程及技术细节

多核心CPU和SoC是为了满足整机系统对处理能力和处理速度不断提升的需求，在单核心CPU沿着摩尔定律向前发展，受到了芯片功率极限阻碍时，人们不得不选择的一种突破路线。多核心CPU推动着操作系统的更新和升级，操作系统又决定了多核心CPU效能的发挥。多核心CPU技术的难点是多核心之间的信息传递、数据同步和任务调度等。系统性能优劣不能只考虑CPU核心数量，还要考虑操作系统、调度算法、应用和驱动程序等。多核心CPU技术和FinFET等3D芯片技术可以看作是延续摩尔定律生命的两大关键技术。

2024-06-10 21:07:56 7792

原创【MIPS】Cache一致性协议之： MESI 协议

多核处理器上有一套完整的协议，来保证Cache一致性。比较经典的Cache一致性协议当属MESI协议。dirty和valid标志，它们很好的描述了 Cache 和 Memory (内存)之间的数据关系(数据是否有效，数据是否被修改)，而在多核处理器中，多个核会共享一些数据，MESI协议就包含了描述共享的状态。转自：https://blog.csdn.net/muxiqingyang/article/details/6615199。

2024-03-10 01:22:15 2711 2

原创 [AIDV] 芯片验证：AI 机器学习在 DV 中的应用及进展

现代硬件设计的功能要求不断增加，这意味着传统的功能验证过程在满足设计上市时间目标方面变得效率低下。大量的事实证明，机器学习 (ML) 模型对于流程主要部分的自动化非常有价值，而这些部分通常占用了工程师的精力；使他们不再需要添加新的覆盖率指标来使设计更加稳健。

2024-03-01 23:24:02 3720 2

原创【个人思考】IC验证工程师的起源与进化

20年前所需的功能验证技能几乎无法与今天的验证技能相提并论，随着设计和验证变得更加抽象，硬件与固件、软件的实现边界不断移动，以及新技术的采用，这种变化应该被期望。优秀的验证工程师是多年经验的积累。20到30年前，一个优秀的验证工程师了解设计，知道如何构建简单的功能测试计划清单，并在模拟器中大致上进行设计级别的连线，构建能够检测功能故障的模型还能获得额外的加分。衡量一名优秀的验证工程师的最佳指标不是他们给出的答案，而是他们所提出的问题以及提问的速度。今天，一个优秀的验证工程师几乎是一个全知的工程师。

2024-01-16 00:43:16 526 1

原创【CPU cache】与程序员相关的CPU缓存知识漫谈

与程序员相关的CPU缓存知识 1.基础知识 2. 缓存的命中 3.缓存的一致性 4.程序性能

2024-01-09 21:32:11 1588

原创【个人思考】数字芯片领域，未来值得投身方向？

这两种芯片已经是芯片界的元老，推荐这两个方向不仅仅是因为它们在消费电子、服务器、云计算等领域有着稳定的出货量，更是因为CPU/GPU作为超大规模的芯片，对个人的技能栈能做非常全面的学习补足。存算一体芯片未来的挑战也颇多，包括计算单元的设计，数据传输路径的优化，对应的软件编译器的部署等。这个方向需要具备数字信号处理、通信协议、射频等方面的知识，具有较高的技术门槛。当然没有十几二十年的学习和经验积累，是搞不定它们的，除此之外，想设计出有市场竞争力的高性能CPU/GPU，光有时间的积累还不够，智商也是要的。

2024-01-03 00:32:52 529 1

转载【MIPS】MIPS指令集：内嵌汇编asm语法介绍

内嵌汇编指令"move %0,%1\n\t"中的move还不是真正的MIPS汇编指令，MIPS中的move指令的2个操作数是寄存器，而此处move的操作数是c语言中的变量。“memory”就是通知GCC编译器，此段内嵌汇编修改了memory中的内容，asm之前的c代码块和之后的c代码块看到的memory可能是不一样的，对memory的访问不能依赖之前的缓存，需要重新加载。操作符就使用MIPS汇编指令中的助记符，操作数可以是%0,%1,%2形式的占位符，来表示c语言中变量ret、a和b。整个程序功能很简单。

2023-08-14 21:04:37 881

原创【SystemVerilog中的浅复制（shallow copy）和深复制 (deep copy)】

俗话说得好：遇事不决问标准，今天回顾问题时，发现对浅复制（shallow copy）和深复制 (deep copy) 的理解不够深入，整理一下标准中对深复制和浅复制的介绍和自己的理解；

2023-05-28 23:56:10 467 1

原创【数字IC验证进阶】SystemVerilog的随机稳定性

作为基于约束的随机验证方法的一部分，在ASIC/FPGA开发过程中，每晚会运行一套测试，并且每晚的回归测试都会使用不同的种子运行。这样，每当测试使用不同的随机种子运行时，测试平台中的 $urandom, $urandom_range & (class) randomize()调用会生成不同的随机数，从而导致DUT的不同激励和配置。这些回归测试中的任何测试失败都必须是可复现的，特别是如果失败结果证明是RTL错误。

2023-05-25 23:54:26 1526 3

qq_45869788的博客