ICer_Designer的博客

原创 ACE协议介绍(四)：ace协议在哪些场景下会进行snoop操作？

摘要：ACE协议的Snoop操作用于维护多核系统缓存一致性，仅在共享内存（Shareable）内由相干主设备发起一致性事务时触发。主要场景包括：读共享数据（ReadShared）、获取独占权限（ReadUnique）、写操作（WriteUnique）和缓存维护（CleanInvalid）。触发条件包括：共享内存属性、相干主设备、一致性事务类型及互连判断需求。不触发Snoop的情况包括：非共享内存、非一致性事务、非相干主设备及SnoopFilter优化判定。Snoop操作通过广播请求确保各主设备缓存状态一致。

原创 关于sv中this的使用介绍，以及与super的区别

本文阐述了面向对象编程中this关键字的核心作用，即明确引用当前类实例的成员（属性和方法），解决命名冲突和区分作用域。文章通过验证场景案例拆解了this的四大使用场景：1）解决成员变量与局部变量命名冲突；2）显式调用当前实例方法提升可读性；3）在构造函数中传递当前实例；4）配合super区分父子类成员。同时指出了this的使用限制：不能在静态方法和类外部使用。最后对比了this与super的区别，强调this的核心价值在于明确作用域，在验证中常用于事务类构造、参考模型方法调用和组件注册等场景。

原创 ACE协议介绍(三)：ace协议中的make和clean操作

在 ACE（AXI Coherency Extensions）协议中，和是两类核心的缓存一致性操作，用于管理缓存行的状态和权限，确保多核系统中数据的一致性。

原创 uvm_analysis_imp_decl的使用及举例说明

摘要： uvm_analysis_imp_decl宏是UVM中实现多端口分析通信的关键工具，允许一个组件（如Scoreboard）同时接收多个Monitor的事务。核心流程：1）通过宏定义自定义后缀（如_icache、_axi）；2）在组件中声明对应的uvm_analysis_imp_后缀端口；3）实现write_后缀()方法处理事务；4）在Env中绑定生产者的analysis_port到消费者的analysis_imp。注意事项：宏需在组件前声明，方法名严格匹配后缀，事务类型一致。

原创 cpu的fetch/prefetch

它们都是核心工作。

原创 关于systemverilog中的随机化的使用

只能在 class 中使用- 可以在任何地方使用。

原创 关于typedef和enum枚举的配合使用介绍

代码简洁：避免重复写冗长的enum定义，提升代码可读性。强类型检查：使用别名声明的变量只能接受枚举中的合法值，编译器会自动检查类型错误，减少 bug。可维护性高：枚举定义集中在一处，修改时只需改一次，所有引用都会同步更新。跨模块复用：通过包（package）导出typedef后的枚举，可以在整个项目中复用，确保一致性。先在项目的公共 UVM 包中定义 AXI 响应类型枚举，通过typedef创建别名，供整个验证环境复用：// 文件：axi_defines_pkg.sv（公共枚举/参数定义包）

原创 关于CPU的介绍(四)----CMO(Cache Maintenance Operations）

摘要：CMO（缓存维护操作）是管理缓存状态的关键机制，包含两类核心操作：Cache cleaning（将脏数据写回主存，使外设可见）和Cache invalidation（使缓存行失效，强制重新加载）。前者用于数据同步，后者用于数据更新。两者常配合使用，如DMA操作时先清理确保数据可见，再失效使CPU获取最新数据。这些操作解决了缓存一致性问题，是多核系统和外设交互的重要保障。

原创 ACE协议介绍(二)：ace协议为什么增加AC/CR/CD这三个通道？

ACE 新增 AC/CR/CD 通道的本质，是将缓存一致性的监听机制从 AXI 的点对点模型中剥离，用独立通道承载 “反向地址 + 响应 + 数据”，解决 AXI 无法支撑的全局一致性问题。这三个通道不仅是协议层面的扩展，更是硬件设计中 “时序隔离、带宽优化、状态同步” 的关键保障，是 ACE 能够实现多主设备缓存一致性的底层基石。

原创 ACE协议介绍(一)：ace协议为什么增加RACK/WACK这两个通道？

ACE协议在AXI基础上扩展了RACK/WACK通道，解决了多主设备缓存一致性的核心问题。传统AXI的RESP机制只能实现单向响应，而ACE通过独立确认通道实现了事务生命周期的闭环管理、全局操作排序、资源释放和状态同步。RACK/WACK作为事务终点锚点，确保主设备完成数据处理后通知互联更新全局状态，避免资源泄漏和一致性错误。这种设计解耦了数据传输与一致性控制的时序，为ACE实现多主设备共享缓存提供了关键机制，是其区别于AXI点对点传输的本质特征之一。

原创 RISC-V(四)：RV32F(RISC-V 32 位单精度浮点扩展指令集)

RV32F 是 RISC-V RV32 架构的单精度浮点核心扩展独立浮点寄存器：f0~f31 专门存储浮点数，与整数寄存器分离，简化硬件设计；灵活的控制机制：通过 fcsr 寄存器配置舍入模式、记录浮点异常，适配不同应用场景；高效的融合乘加：FMA 指令减少运算延迟和精度损失，是浮点计算的性能关键；与整数指令的无缝交互：支持浮点与整数的双向转换和数据移动，兼容原有整数指令集。

原创 RISC-V(三)：RV32M(RISC-V 32 位乘法 / 除法扩展指令集)

RV32M 是 RISC-V RV32 架构的核心算术扩展，通过 10 条 R 型指令实现了 32 位有符号 / 无符号的乘法、除法、取余操作，解决了 RV32I 仅支持基础运算的局限。其设计遵循 RISC-V 的模块化、精简性乘法指令拆分高低位结果，适配 32 位寄存器的限制；除法 / 取余指令明确向零取整和余数符号规则，保证跨平台兼容性；可选实现的特性，让处理器可在性能和面积 / 功耗之间做权衡。

原创 RISC-V(一)：RV32I(RISC-V 32 位基础整数指令集)

RV32I 是 RISC-V 32 位架构的 “最小核心”，通过固定指令格式、正交寄存器设计、精简指令集，实现了 “低硬件复杂度 + 高兼容性” 的平衡。它不仅是所有 32 位 RISC-V 处理器的必备基础，也是理解 RISC-V 模块化设计思想的核心 —— 在此基础上，可通过叠加 M/C/A 等扩展适配不同场景，同时保持指令集的简洁性和可实现性。

原创 RISC-V(二)：RV32E(RISC-V 32 位嵌入式精简扩展)

RV32E 是 RISC-V 架构对 “极致精简嵌入式场景” 的定制化优化，核心通过裁剪通用寄存器数量实现硬件面积和功耗的降低，同时保持与 RV32I 的指令集兼容，是物联网、超低功耗传感器、微型 MCU 的理想选择。其设计体现了 RISC-V “模块化、可裁剪” 的核心优势 —— 既保留架构统一性，又适配细分场景的极致需求。

原创 关于CPU的介绍(三)----MMU(内存管理单元）

CPU是否包含MMU取决于应用场景需求。带MMU的CPU（如x86、ARMCortex-A）支持虚拟内存、多任务隔离和权限控制，适用于复杂系统如服务器和智能手机；无MMU架构（如Cortex-M、8051）则简化设计、降低功耗，适合实时嵌入式系统和物联网设备。MMU提供地址转换和内存保护，而无MMU架构直接访问物理地址，确保实时性和低延迟。RISC-V等模块化架构可根据需求灵活选择是否集成MMU。

原创 关于CPU的介绍(二)----DTLB(数据转址旁路缓存)

是 CPU 中用于的高速缓存，是内存管理单元（MMU）的关键组件。以下从。

原创 关于CPU的介绍(一)----IFU取指单元

IFU 是 CPU 的 “指令供应中心”，核心任务是高效、连续地从内存中获取指令，并通过预取、分支预测、缓存等技术，为后续流水线阶段提供稳定的指令流。其设计复杂度随 CPU 架构和性能需求提升，是衡量 CPU 性能的关键指标之一。

原创 哪些属性的请求会经过L1D Cache？

只有 **Cacheable写回 / 写透、写分配 / 写不分配等组合的写请求；读分配的读请求；带共享 / 唯一属性的一致性请求。非 Cacheable 的请求（如设备寄存器访问）会直接绕过 L1D Cache 的缓存流程。

原创 systemverilog 如何在子类中修改父类中声明的变量

/ 父类配置类：base_cfg// 声明可被子类修改的变量（protected：子类可访问，外部不可改）// 默认突发长度// 默认开启覆盖率// 默认基地址// 可选：父类提供修改变量的方法（推荐，封装逻辑）if (len > 0 && len <= 64) begin // 合法性检查`uvm_error("BASE_CFG_ERR", $sformatf("burst_len=%0d 超出范围", len))endendclass。

原创 uvm_config_db的使用说明

摘要：在UVM验证环境中，test与寄存器模型(rm)之间通过uvm_config_db传递配置对象(cfg)句柄。核心流程包括：1)定义包含寄存器参数的cfg类和rm类；2)在test的build_phase中实例化cfg并调用uvm_config_db::set写入；3)在rm的build函数中使用uvm_config_db::get读取。关键要点包括：路径匹配原则(set路径需指向rm实例)、类型严格一致、确保先set后get的执行顺序。扩展场景支持rm在env中的跨层级传递，并通过日志打印和断言验证

原创 功能覆盖率--数组型bin和单bin的区别

SystemVerilog中coverpoint的两种bin定义方式存在本质差异：带方括号bins all_vals[]={[0:63]}会创建64个独立bin（0-63各一个），要求所有值都被触发才能100%覆盖；不带方括号bins all_vals={[0:63]}则合并为1个bin，只要触发区间内任意值即视为完全覆盖。前者适用于需要验证0-63每个数值都被覆盖的场景，后者仅验证数值是否落在0-63范围内。关键区别在于方括号控制bin的拆分方式，直接影响覆盖率统计的精确度。

原创 关于uvm_tlm_analysis_fifo中used函数的介绍

摘要：used()是uvm_tlm_analysis_fifo中用于查询当前FIFO事务数量的成员函数，继承自父类uvm_tlm_fifo_base。该函数为非阻塞查询操作，返回已存储的事务总数，常用于监控FIFO负载状态、调试拥塞情况及条件性读取事务。在有限深度FIFO中，返回值范围为0至最大深度，且线程安全。典型应用场景包括结合is_empty()检查待处理事务、批量读取判断等，是验证环境中调试和状态管理的重要工具。

原创 介绍下宏的字符串化和连接特性

摘要：字符串化(#)和连接(`)是C/Verilog/SystemVerilog宏定义的核心特性。字符串化将宏参数转化为带引号的字符串，便于打印变量名；连接则实现参数与文本的拼接，生成动态标识符。关键点包括：字符串化自动处理引号但不展开嵌套宏；连接需确保无空格且生成合法标识符。典型应用包括调试打印、参数化命名和代码生成，能显著提升代码复用性。使用时需注意语法细节，如连接符位置和宏展开顺序。（149字）

原创 批量替换文本内容和批量重命名文件的操作

第一条命令用于批量修改文件内容（替换文本）。第二条命令用于批量重命名文件（修改文件名）。两者结合了grepfind（查找目标）、sedrename（执行操作）和xargs（传递参数），是 Linux 下高效的批量操作工具链。

原创 关于makefile中通配符*和%的介绍

是文件通配符，用于匹配当前目录中已存在的文件，适合获取文件列表。是模式匹配符，用于定义通用规则（如所有.o依赖.c），不依赖文件是否存在，是 Makefile 实现 “批量处理” 的核心机制。灵活运用两者可以大幅简化 Makefile 的编写，尤其是模式规则，能显著减少重复代码，提高可维护性。

原创 clocking的输入与输出是相对验证环境tb还是dut的？

在 SystemVerilog 中，clocking块的input和output方向是而言的，用于定义测试平台与 DUT（RTL）之间的信号交互方向及时序。

原创 关于systemverilog中find在队列及关联数组中的使用

在 SystemVerilog（SV）中，find是，用于从集合中筛选出满足指定条件的元素，并返回一个包含这些元素的。它是数据筛选的核心工具，语法简洁且支持灵活的条件判断，广泛用于验证中对事务、信号等数据的快速过滤。

原创 关于uvm_top.print_topology()的介绍

摘要：UVM中的uvm_top.print_topology()方法用于打印测试平台的组件层次结构，包括组件名称、类型及父子关系，便于调试和环境验证。该方法通常在end_of_elaboration_phase或run_phase中调用，输出树状结构显示uvm_test_top及其子组件（如env、agent等），是UVM调试的核心工具，能有效提升验证效率，特别适用于复杂项目的环境正确性检查。

原创 芯片验证环境中，使用 Makefile中的mode 和 SystemVerilog中的$value$plusargs 来控制仿真条件，两种常见的参数传递方式介绍

摘要：本文对比了Makefile模式（编译时控制）与SystemVerilog的$value$plusargs（运行时控制）两种参数传递方式。Makefile通过宏定义在编译时固定条件，适合性能敏感场景但缺乏灵活性；$value$plusargs支持动态调整参数，便于调试但存在运行时开销。关键差异体现在控制阶段（静态/动态）、修改成本、性能及适用场景：Makefile模式适合固定配置（如芯片模式选择），而$value$plusargs更适用于需频繁调整的测试验证。选择时需权衡性能需求与调试灵活性，二者可互补

原创 sram进入deepsleep和shutdown是如何实现低功耗的？

SRAM（静态随机存取存储器）中的shutdown和deepsleep是两种重要的低功耗技术，用于降低静态功耗。下面我将详细介绍这两种技术的原理和实现方式。

原创 seq挂载到sequencer的方式以及set_sequencer的介绍

start()

原创 为什么interface声明句柄要用virtual

/ 通过虚接口驱动信号。虚接口不占用额外内存，仅存储对物理接口的引用，实际信号仍由物理接口维护。// 实例化物理接口。是静态绑定的，必须在编译时确定连接的物理接口实例，导致代码僵化。操作信号，无需知道接口在Testbench中的具体路径。允许在运行时动态绑定到不同的接口实例，实现灵活性。，同一组件可以适配多个接口实例，无需修改内部代码。：类中只能声明虚接口，实例化需在模块中完成。：它只是对物理接口的引用，不包含实际信号。// 动态绑定虚接口到物理接口。

原创 关于 arm 核 MPU中cacheable bufferable、shareable的理解

（如 Snoop Control Unit, SCU）或软件管理（如 Clean/Invalidate Cache）确保多核/外设看到的数据一致。，写操作可以缓存在总线写缓冲区（Write Buffer）中，无需等待从设备（Slave）立即完成。（以及 ARMv7-M/v8-M 架构）中，内存属性（Memory Attributes）如。：外设寄存器（如 GPIO）、DMA 缓冲区（避免 Cache 一致性问题）。：普通内存（如 SRAM），允许写合并（Write Merging）优化。

原创 在芯片验证过程中如何进行有效的缺陷定位和分析

4、仿真挂死一般也都是验证环境的问题，检查初始化正否正确配置，变量传递config_db，接口连接正常(TLM通信)，forever，while循环语句是否耗时，是否存在退出条件。3、数据比较不一致，违反协议，一般都是rtl的问题，解决此类问题，就是把rtl内部整个数据通路都熟悉了，分断选取几个关键节点信号查看是否符合预期，然后再定位到具体的问题。2、问题分类：数据比较不一致，违反协议，仿真挂死，验证环境问题；1、首先是自己对整个功能模块足够熟悉；

原创 芯片验证如何保证验证的完备性

明确覆盖率目标：功能覆盖率100%、断言覆盖率达100%、代码覆盖率达100%提取测试点的过程中要完备，尤其要考虑到边界、异常、多功能点的cross测试;过程：1、使用约束随机验证，生成多样化激励，覆盖未知场景；：针对特定功能设计确定性测试用例；

原创 driver和sequencer之间的连接

这类端口的功能主要是用来实现driver和sequencer的request获取和response返回。如：drv.seq_item_port.connect(sqr.seq_item_export);seq_item_port和seq_item_export。

原创 关于uvm_subscriber的介绍

/一个write函数，供initiator端使用uvm_analysis_port端口时。使用方式如：class xxx_axi_transform extends uvm_subscriber#(svt_axi_transaction);是 UVM 库中的一个预定义类，属于 uvm_analysis_port。的订阅（Subscriber）模式的一部分，用于接收和分析通过。// 例如：打印事务信息、转换数据格式、检查协议规则。// 处理接收到的 AXI 事务。

原创 关于C语言的学习

原创 ram_cov

【代码】ram_cov。