1. 为什么架构与验证值得放进同一条学习路线这两年芯片行业热度一直在涨但很多刚入行或者准备转行的朋友容易被岗位名称绕晕。有人觉得搞架构就是画框图写文档有人觉得做验证就是天天跑仿真跑回归两边好像井水不犯河水。实际上IC架构和IC验证是芯片设计流程里最需要互相理解的两个角色把它们放在同一条学习路线里规划反而能走得更稳。先说架构到底在干什么。架构不是简单画个系统框图而是要在产品定义、性能目标、功耗预算、面积约束和可实现的微架构方案之间做取舍。你做一颗应用处理器要清楚流水线该设计成几级Cache要配多大总线拓扑选环形还是Mesh中断控制器怎么挂到子系统上。这些决策直接决定芯片能不能满足目标跑分、能不能控制住功耗、流片回来后好不好调。再说验证在干什么。验证的目标是保证设计按照规格书的意图工作。功能验证要覆盖正常路径和异常路径要能证明“设计在边界条件下不会出问题”或“出了问题能及时被发现”。SoC验证比模块验证更复杂因为要管多时钟域交互、总线协议握手、低功耗状态切换、以及软硬件协同的运行场景。这些工作如果不理解系统架构验证方案就容易只盯着局部缺了全局视野覆盖率再高也漏问题。把两条路线合并来学的逻辑其实很简单架构设计者如果具备验证思维就知道自己定义的接口、寄存器、时序约束会给后端验证带来多大工作量设计的可验证性会好很多验证工程师如果具备架构视野就更容易判断哪些测试点是关键路径哪些场景必须构造验证环境建出来和真实芯片的行为模型贴合度更高。所以这篇文章主要面向三类人一是刚接触IC设计、还在纠结选架构还是选验证的学生或转行者二是在职的初级验证工程师想往SoC架构方向扩展视野三是产品经理或项目经理需要理解技术路线好做团队规划和资源评估。下面我把期刊资源、学习路线和避坑经验一并整理出来尽量做到照着走也能少走弯路。2. 架构方向的期刊、会议和入门读物怎么选2.1 体系结构顶会和代表性期刊如果是做计算机体系结构方向想跟踪业内最前沿的处理器设计、存储层次优化、片上网络、低功耗方案和AI加速器架构建议优先盯住几个顶级会议。体系结构领域有个不成文的说法重要成果先投会议期刊反而更像长文总结平台所以读会议论文比读期刊更贴近前沿。ISCAInternational Symposium on Computer Architecture、HPCAInternational Symposium on High-Performance Computer Architecture、MICROIEEE/ACM International Symposium on Microarchitecture和ASPLOSInternational Conference on Architectural Support for Programming Languages and Operating Systems这四个是最核心的。ISCA偏重体系结构和硬件软件协同设计HPCA兼顾高性能计算和芯片微架构MICRO在微架构实现细节上很强势ASPLOS则跨了体系结构、编程语言和操作系统三个方向对系统级设计特别有参考价值。如果习惯看期刊IEEE Transactions on ComputersTC和IEEE Transactions on Computer-Aided Design of Integrated Circuits and SystemsTCAD是传统强刊。TC覆盖计算机系统和体系结构的长文TCAD偏重EDA方法和电路设计自动化做架构前端的话TC更对口味。ACM Transactions on Architecture and Code OptimizationTACO也在体系结构和编译优化方面有不错的稿源适合想从编译器角度理解微架构的读者。国内期刊方面计算机学报、电子学报、半导体学报的英文版有时也会刊发处理器架构和AI芯片方向的论文适合跟踪国内团队的工作。但要提醒一句如果你想看最前沿的产业方向比如高性能CPU和GP-GPU的微架构演进公开论文毕竟是滞后且模糊的很多关键技术细节写在专利和内部文档里。读论文更多是为了建立技术判断力而不是为了去复现某一颗具体芯片。2.2 架构入门从哪本书开始最合适直接读顶会论文对新手不友好。论文里大量术语和假设没有体系结构基础的人很容易迷失在细节里。我建议按照这个顺序来读。第一步看Patterson和Hennessy的《计算机组成与设计硬件/软件接口》。这本书适合入门讲清楚了指令集、流水线、存储层次、I/O的基本概念配合RISC-V的例子尤其容易上手。如果学校教材不是这个版本找最新版本配合在线实验做一遍效果更好。第二步进阶看Hennessy和Patterson的另一本《计算机体系结构量化研究方法》。这本书是体系结构从业者的常备手册着重讲量化分析思路比如怎么通过CPI公式拆解性能瓶颈怎么评估Cache缺失带来的影响。书里的Amdahl定律、流水线性能模型、存储层次分析实际做架构方案评估时天天用得到。第三步针对处理器微架构可以看《超标量处理器设计》姚永斌著中文书里讲超标量流水线、乱序执行、寄存器重命名、分支预测讲得比较系统。做CPU、GPU、AI加速器微架构的读者这本书是很好的桥梁读完再看论文就顺很多。2.3 架构方向的开源资源和社区渠道除了期刊和书我强烈建议读者养成跟踪开源硬件社区的习惯。RISC-V国际基金会官网有大量指令集规范文档Chisel和Verilog的生态也有不少开源处理器核比如Rocket、BOOM、CVA6这些项目GitHub上都有源代码和文档。把这些代码综合起来看能直观体会架构设计是怎么在RTL层落地的。如果有精力建议订阅《IEEE Micro》杂志。它不算顶刊级别但每期主题聚焦比如CPU设计特刊、AI加速器特刊、数据中心芯片特刊编辑会邀请业内团队写实践总结比看纯学术论文更容易理解产业界的真实考量。比如某个做服务器CPU的公司为什么要选某一种Cache一致性协议这些背景信息在《IEEE Micro》上反而能读到。3. 验证方向的学习资源和期刊选择3.1 验证方向有哪些值得关注的会议功能验证领域最对口的会议是DVConDesign and Verification Conference这是验证工程师的主场。DVCon的论文和报告偏工程实践很少有纯粹的理论推导很多一线团队会把验证环境搭建方法、UVM使用经验、覆盖率收敛技巧拿出来分享。每年DVCon的教程和workshop内容也很适合学习者很多主题出自验证专家的实战总结。如果从设计和验证结合的角度找学术资源DATEDesign, Automation and Test in Europe和ITCInternational Test Conference值得关注。DATE覆盖面宽验证方法学、仿真加速、形式验证、硅前验证等相关论文都会出现。ITC偏测试和可测试性设计对熟悉DFT和量产测试有帮助验证工程师理解这些内容能更清楚设计验证和制造测试的边界落在哪里。再补充一个会议就是FMCADFormal Methods in Computer-Aided Design。如果对形式化验证感兴趣比如等价性检查、模型检验、定理证明在芯片设计里的应用这个会的内容质量很高。形式验证不像动态仿真那样靠激励去“撞”bug而是通过数学方法穷举状态空间验证性质很多安全关键芯片的验证工作依赖这个方向。3.2 验证方向期刊和系统资料推荐验证方向纯粹做方法学的期刊没有体系结构那么多IEEE TCAD依然是验证领域论文的重要发表阵地形式验证、覆盖率分析、仿真加速算法等内容常出现在这里。IEEE Transactions on Very Large Scale Integration (VLSI) Systems也就是TVLSI也会涵盖验证方法相关的电路和系统设计内容。IEEE Design Test杂志则介于学术和工业界之间经常有一些自主测试、验证流程的实践文章适合拓宽视野。不过做验证更依赖的是工程资料和方法论整理而不是单纯盯着论文。最经典的书仍然是《SystemVerilog验证测试平台编写指南》也就是业界俗称的SV绿皮书。这本书讲清楚了对验证工程师来说最核心的SystemVerilog语言特性包括OOP面向对象编程在测试平台里的应用、随机化激励、功能覆盖率收集、断言等。很多人犯的错误是先学语法再学验证思路顺序反了。正确做法是带着“怎么构建一个可复用、可配置、能快速收敛的测试平台”这个目标去学语言语法是为方法学服务的。《UVM实战》张强著电子工业出版社是第二本我认为绕不开的中文资料。书里对UVM的工厂机制、sequence机制、寄存器模型、phase机制讲得比较接地气跟着代码跑一遍基本UVM验证环境就不成问题了。想追英文原版的可以看《The UVM Primer》和《UVM Reference Manual》后者偏工具书不适合通读适合做项目时查阅。3.3 验证学习和系统方法论的底层逻辑经常有读者问验证到底要不要学形式化方法要不要会写参考模型。我的看法是验证工程师的能力不是靠“会跑工具”体现的而是靠验证计划的质量和问题定位速度体现的。验证计划的核心是把项目需求分解成可度量的验证目标。比如某条总线接口可能支持突发传输、乱序返回、超时重试这些特性每个特性都要有对应的测试场景场景里要设置合理的约束和异常注入。没有计划的验证就是无头苍蝇跑再多的case覆盖率也上不来。参考模型的编写能力也值得练。参考模型简单说是用高抽象的C、SystemC或者Python写一个功能等价模型用于和RTL仿真结果做比对。这要求验证工程师充分理解协议和算法比单纯写UVM组件更难但具备这种能力的人很容易转型做系统架构。很多资深验证工程师就是靠参考模型打下的基础理解起架构设计来毫无障碍。4. 架构方向学习路线从基础到微架构设计4.1 第一阶段数字电路和基础工具的地基不管做架构还是验证数字电路基础是不能跳过的。建议用《数字设计和计算机体系结构》里关于组合逻辑、时序逻辑的部分打底配合Verilog或SystemVerilog做一点小模块设计深刻理解时序约束是什么概念。很多细节比如建立时间和保持时间、亚稳态、跨时钟域处理如果在这个阶段没弄懂后面做架构设计会产生很大隐患。工具方面至少要熟练使用一种仿真工具和一个综合工具。开源环境选Verilator加GTKWave商业环境用VCS/QuestaSim加Design Compiler。不建议在这个阶段贪多重点是把“写RTL-仿真-看波形-修正”这个循环跑顺。如果连基本的波形都读不利索后面看架构层面的时序分析会非常吃力。4.2 第二阶段体系结构原理到微架构落地有了数字电路的地基就可以系统学习体系结构。建议先用量化方法那本书的1到5章把性能公式、流水线原理、存储层次和并行处理基础过一遍。理论部分学完想办法找一个开源处理器项目做RTL级的理解比如在学校课程里基于RISC-V的SCARV、PULP这类项目或者GitHub上任意一个万行级别的处理器逐一对照目录结构指出取指、译码、执行、访存、写回级的模块和对应信号。很多人卡在这一步原因是直接读RTL代码信息量太大。这里我有一个小技巧先只关注一条最简单指令的生命周期比如add指令从取指到写回信号名一级级往后追。把这条指令的路径搞清楚了再扩展到load、store、branch最后就自然建立起整体流水线视图。切忌刚开始就想show出全部模块。4.3 第三阶段微架构设计实践和论文阅读进入第三阶段尝试独立做一个小规模的处理器微架构设计再进一步做总线或NoC的架构评估。比如在一个8核节点上分析Mesh和Ring拓扑的跳数差异结合路由算法估算平均时延。这个阶段开源工具是Concat、SystemC建模、Gem5模拟器。Gem5适合做体系结构探索你可以改Cache参数、改动核数、改频率跑SPEC测试直观观察性能变化。事情做到这个程度回来读ISCA和MICRO的论文就不会觉得陌生了。刚开始读论文不必强求理解所有公式抓住“motivation、idea、method、evaluation”四个要素就好。先看标题和摘要再看图表结论最后才沉下心对照公式。我的经验是每周精读一篇三个月后看架构论文的感觉会完全不同。5. 验证方向学习路线从SystemVerilog到SoC验证5.1 第一阶段掌握验证语言和基本验证组件验证方向同样要有数字电路基础然后花大力气吃透SystemVerilog的验证特性。这里特指的是OOP、随机化、约束和功能覆盖率不是把Verilog语法背一遍。先写一个小型验证环境把driver、monitor、scoreboard和testcase之间的调用关系、数据流关系搞清楚。一个建议是手动实现一个最简的验证环境不用UVM直接用SystemVerilog。这看起来土但能逼着你理解事务级建模、握手协议和比对逻辑的实现过程。等亲手写完之后再学UVM你才明白UVM的类库是为了解决什么问题才存在的。直接上UVM框架学就好像跳过数电去学计算机组成原理很容易背概念用不出来。5.2 第二阶段UVM方法学和完整验证环境搭建UVM是当前功能验证的主流框架。必须重点掌握的有factory机制、phase机制、config机制、sequence机制、寄存器模型和tlm通信。很多人卡在UVM的宏定义上比如uvm_component_utils、uvm_object_utils、uvm_field_utils这些总想背参数。别背先理解背后的注册机制把类的创建由编译期变成运行期的逻辑搞清楚宏就好懂了。这个阶段的实操目标是独立搭建一个完整的UVM验证环境。建议选一个简单的协议模块比如断言握手接口或者SPI、I2C从机模块覆盖正常读写、错误响应、超时场景并收集功能覆盖率。我这个阶段的经验是工程宁可小一点环境层次要齐agent、env、test和case的关系必须结构清晰否则后面做SoC级验证时会因为环境设计混乱吃大亏。5.3 第三阶段SoC验证能力和专项验证方向熟悉UVM之后要开始接触SoC验证。SoC验证要处理的不只是某个模块的交易级验证还涉及多核互联、中断系统、启动流程、外设配置、低功耗状态切换等系统级行为。这时你需要学会搭建SoC验证平台一般是把处理器核的模型放进去通过编译运行C程序驱动系统进行激励观察总线事务和外部接口行为。专项验证方向也在这个阶段展开。常见的细分方向包括缓存一致性验证MTL验证也就是memory transaction layer低功耗验证比如UPF的功耗意图验证形式验证比如等价性检查和断言形式化以及硅前驱动的软件验证。不要全都学结合项目需求挑一个方向纵深发展。业内对SoC验证工程师的需求量大但对系统思维要求也高这也是为什么我做开头就建议架构和验证一起学这个阶段优势会体现得很明显。6. 常见问题与避坑心得6.1 学习路线中的典型卡点和排查方法第一条最常遇到的问题是SystemVerilog仿真器和UVM环境装好以后编译报一堆莫名其妙的信息。这往往不是环境出问题而是大家直接用uvm_macros.svh的路径引用错误。推荐使用包的形式在仿真命令里加incdir和uvm参数编译UVM库而不是把uvm源码胡乱复制进工作目录。正规仿真工具默认支持-uvm选项只要把库路径指对就顺利了。第二条很多人写了一堆UVM sequence却不知道怎么控制测试结束导致仿真一直跑不完。原因多半是phase机制理解不透sequence没有把item完整消费完或者objection没有raise/drop。建议在写第一个用例的时候就在sequence里增加item数量的计数并在drain time用phase.drop_objection同时仿真脚本里加最大时间保护比如-timelimit避免无限循环拖掉整个回归时间。第三条架构方向容易踩的坑是一上来就读论文结果越看越迷糊。我的解决思路是对照着已有芯片的开源实现读论文。比如先快速读一篇讲非阻塞Cache设计的论文再去看某个开源处理器里如何实现非阻塞Cache的表项管理理论映射到代码后理解成本会低很多。另外论文里很多实验效果是建立在特定target和benchmark下的不能当成放之四海而皆准的结论。6.2 架构和验证学习要避开的思维误区第一个误区是把验证当成“低门槛”岗位。验证的门槛确实不体现在语言上但体现在“能不能把设计验证闭环”上。只会搭UVM环境不会针对设计风险制定测试策略的人实际上还处于初级阶段。真正资深的功能验证工程师对RTL逻辑烂熟于心甚至能从代码覆盖角度反推架构的合理性。验证能力做到深处和架构设计能力是互通的。第二个误区是忽视层次化验证的思路。模块级验证、子系统级验证、SoC级验证不是简单的大环境套小环境每一次层次跃迁都意味着新的调度策略、复用策略和抽象策略。如果不理解这一点只会在顶层环境里堆模块干涉严重的时候环境极其难维护。好的验验环境设计一定是分层的底层组件保持稳定上层测试场景可灵活配置。这种分层思维其实和架构设计中的模块划分、接口抽象是同一个方法论。第三个误区是放弃书写验证计划。我见过不少人验证环境写完就开始无脑建testcase根本不管哪些功能点已经覆盖哪些还是空白。正确的做法是先做验证计划把测试点和覆盖率目标列成表格每条对应到具体的testcase和场景。写完计划再搭环境后面只要持续check覆盖率就行。养成这个习惯之后做架构评估和风险分析也是有帮助的。6.3 最后再分享一点我个人的体会踩过这么多坑之后我的一个强烈感受是IC架构和验证的学习本质上都是在训练一种面向风险的设计直觉。做架构的人如果只看性能不看实现代价流片后验证会痛不欲生做验证的人如果只看覆盖率不问设计漏洞在哪项目交付也会充满不确定性。所以安排学习路线时最好两个方向的内容交叉着看。今天读一篇架构论文明天就去看对应的验证方案如何构造场景后天再去想如果是自己设计会把可测试性设计放哪里走完这个循环知识就不再是割裂的了。期刊和书单只是路线图上的坐标真正把这条路走通的还是动手做项目并在过程里不断追问“为什么这么设计”和“怎么样才能让设计被充分验证”。建议给自己定一个半年计划前半段把SystemVerilog和UVM环境跑通每次仿真波形和覆盖率督责自己有清晰的分析后半段挑一个开源CPU核独立做流水线理解和总线接口验证两方面合在一起基本就能克服新手阶段的最大障碍。 
长河君 · 2026/9/8 15:36:15 · 阅读 1.2k IC架构与验证协同进阶：从基础理论到SoC实战的完整学习路线
1. 为什么架构与验证值得放进同一条学习路线这两年芯片行业热度一直在涨但很多刚入行或者准备转行的朋友容易被岗位名称绕晕。有人觉得搞架构就是画框图写文档有人觉得做验证就是天天跑仿真跑回归两边好像井水不犯河水。实际上IC架构和IC验证是芯片设计流程里最需要互相理解的两个角色把它们放在同一条学习路线里规划反而能走得更稳。先说架构到底在干什么。架构不是简单画个系统框图而是要在产品定义、性能目标、功耗预算、面积约束和可实现的微架构方案之间做取舍。你做一颗应用处理器要清楚流水线该设计成几级Cache要配多大总线拓扑选环形还是Mesh中断控制器怎么挂到子系统上。这些决策直接决定芯片能不能满足目标跑分、能不能控制住功耗、流片回来后好不好调。再说验证在干什么。验证的目标是保证设计按照规格书的意图工作。功能验证要覆盖正常路径和异常路径要能证明“设计在边界条件下不会出问题”或“出了问题能及时被发现”。SoC验证比模块验证更复杂因为要管多时钟域交互、总线协议握手、低功耗状态切换、以及软硬件协同的运行场景。这些工作如果不理解系统架构验证方案就容易只盯着局部缺了全局视野覆盖率再高也漏问题。把两条路线合并来学的逻辑其实很简单架构设计者如果具备验证思维就知道自己定义的接口、寄存器、时序约束会给后端验证带来多大工作量设计的可验证性会好很多验证工程师如果具备架构视野就更容易判断哪些测试点是关键路径哪些场景必须构造验证环境建出来和真实芯片的行为模型贴合度更高。所以这篇文章主要面向三类人一是刚接触IC设计、还在纠结选架构还是选验证的学生或转行者二是在职的初级验证工程师想往SoC架构方向扩展视野三是产品经理或项目经理需要理解技术路线好做团队规划和资源评估。下面我把期刊资源、学习路线和避坑经验一并整理出来尽量做到照着走也能少走弯路。2. 架构方向的期刊、会议和入门读物怎么选2.1 体系结构顶会和代表性期刊如果是做计算机体系结构方向想跟踪业内最前沿的处理器设计、存储层次优化、片上网络、低功耗方案和AI加速器架构建议优先盯住几个顶级会议。体系结构领域有个不成文的说法重要成果先投会议期刊反而更像长文总结平台所以读会议论文比读期刊更贴近前沿。ISCAInternational Symposium on Computer Architecture、HPCAInternational Symposium on High-Performance Computer Architecture、MICROIEEE/ACM International Symposium on Microarchitecture和ASPLOSInternational Conference on Architectural Support for Programming Languages and Operating Systems这四个是最核心的。ISCA偏重体系结构和硬件软件协同设计HPCA兼顾高性能计算和芯片微架构MICRO在微架构实现细节上很强势ASPLOS则跨了体系结构、编程语言和操作系统三个方向对系统级设计特别有参考价值。如果习惯看期刊IEEE Transactions on ComputersTC和IEEE Transactions on Computer-Aided Design of Integrated Circuits and SystemsTCAD是传统强刊。TC覆盖计算机系统和体系结构的长文TCAD偏重EDA方法和电路设计自动化做架构前端的话TC更对口味。ACM Transactions on Architecture and Code OptimizationTACO也在体系结构和编译优化方面有不错的稿源适合想从编译器角度理解微架构的读者。国内期刊方面计算机学报、电子学报、半导体学报的英文版有时也会刊发处理器架构和AI芯片方向的论文适合跟踪国内团队的工作。但要提醒一句如果你想看最前沿的产业方向比如高性能CPU和GP-GPU的微架构演进公开论文毕竟是滞后且模糊的很多关键技术细节写在专利和内部文档里。读论文更多是为了建立技术判断力而不是为了去复现某一颗具体芯片。2.2 架构入门从哪本书开始最合适直接读顶会论文对新手不友好。论文里大量术语和假设没有体系结构基础的人很容易迷失在细节里。我建议按照这个顺序来读。第一步看Patterson和Hennessy的《计算机组成与设计硬件/软件接口》。这本书适合入门讲清楚了指令集、流水线、存储层次、I/O的基本概念配合RISC-V的例子尤其容易上手。如果学校教材不是这个版本找最新版本配合在线实验做一遍效果更好。第二步进阶看Hennessy和Patterson的另一本《计算机体系结构量化研究方法》。这本书是体系结构从业者的常备手册着重讲量化分析思路比如怎么通过CPI公式拆解性能瓶颈怎么评估Cache缺失带来的影响。书里的Amdahl定律、流水线性能模型、存储层次分析实际做架构方案评估时天天用得到。第三步针对处理器微架构可以看《超标量处理器设计》姚永斌著中文书里讲超标量流水线、乱序执行、寄存器重命名、分支预测讲得比较系统。做CPU、GPU、AI加速器微架构的读者这本书是很好的桥梁读完再看论文就顺很多。2.3 架构方向的开源资源和社区渠道除了期刊和书我强烈建议读者养成跟踪开源硬件社区的习惯。RISC-V国际基金会官网有大量指令集规范文档Chisel和Verilog的生态也有不少开源处理器核比如Rocket、BOOM、CVA6这些项目GitHub上都有源代码和文档。把这些代码综合起来看能直观体会架构设计是怎么在RTL层落地的。如果有精力建议订阅《IEEE Micro》杂志。它不算顶刊级别但每期主题聚焦比如CPU设计特刊、AI加速器特刊、数据中心芯片特刊编辑会邀请业内团队写实践总结比看纯学术论文更容易理解产业界的真实考量。比如某个做服务器CPU的公司为什么要选某一种Cache一致性协议这些背景信息在《IEEE Micro》上反而能读到。3. 验证方向的学习资源和期刊选择3.1 验证方向有哪些值得关注的会议功能验证领域最对口的会议是DVConDesign and Verification Conference这是验证工程师的主场。DVCon的论文和报告偏工程实践很少有纯粹的理论推导很多一线团队会把验证环境搭建方法、UVM使用经验、覆盖率收敛技巧拿出来分享。每年DVCon的教程和workshop内容也很适合学习者很多主题出自验证专家的实战总结。如果从设计和验证结合的角度找学术资源DATEDesign, Automation and Test in Europe和ITCInternational Test Conference值得关注。DATE覆盖面宽验证方法学、仿真加速、形式验证、硅前验证等相关论文都会出现。ITC偏测试和可测试性设计对熟悉DFT和量产测试有帮助验证工程师理解这些内容能更清楚设计验证和制造测试的边界落在哪里。再补充一个会议就是FMCADFormal Methods in Computer-Aided Design。如果对形式化验证感兴趣比如等价性检查、模型检验、定理证明在芯片设计里的应用这个会的内容质量很高。形式验证不像动态仿真那样靠激励去“撞”bug而是通过数学方法穷举状态空间验证性质很多安全关键芯片的验证工作依赖这个方向。3.2 验证方向期刊和系统资料推荐验证方向纯粹做方法学的期刊没有体系结构那么多IEEE TCAD依然是验证领域论文的重要发表阵地形式验证、覆盖率分析、仿真加速算法等内容常出现在这里。IEEE Transactions on Very Large Scale Integration (VLSI) Systems也就是TVLSI也会涵盖验证方法相关的电路和系统设计内容。IEEE Design Test杂志则介于学术和工业界之间经常有一些自主测试、验证流程的实践文章适合拓宽视野。不过做验证更依赖的是工程资料和方法论整理而不是单纯盯着论文。最经典的书仍然是《SystemVerilog验证测试平台编写指南》也就是业界俗称的SV绿皮书。这本书讲清楚了对验证工程师来说最核心的SystemVerilog语言特性包括OOP面向对象编程在测试平台里的应用、随机化激励、功能覆盖率收集、断言等。很多人犯的错误是先学语法再学验证思路顺序反了。正确做法是带着“怎么构建一个可复用、可配置、能快速收敛的测试平台”这个目标去学语言语法是为方法学服务的。《UVM实战》张强著电子工业出版社是第二本我认为绕不开的中文资料。书里对UVM的工厂机制、sequence机制、寄存器模型、phase机制讲得比较接地气跟着代码跑一遍基本UVM验证环境就不成问题了。想追英文原版的可以看《The UVM Primer》和《UVM Reference Manual》后者偏工具书不适合通读适合做项目时查阅。3.3 验证学习和系统方法论的底层逻辑经常有读者问验证到底要不要学形式化方法要不要会写参考模型。我的看法是验证工程师的能力不是靠“会跑工具”体现的而是靠验证计划的质量和问题定位速度体现的。验证计划的核心是把项目需求分解成可度量的验证目标。比如某条总线接口可能支持突发传输、乱序返回、超时重试这些特性每个特性都要有对应的测试场景场景里要设置合理的约束和异常注入。没有计划的验证就是无头苍蝇跑再多的case覆盖率也上不来。参考模型的编写能力也值得练。参考模型简单说是用高抽象的C、SystemC或者Python写一个功能等价模型用于和RTL仿真结果做比对。这要求验证工程师充分理解协议和算法比单纯写UVM组件更难但具备这种能力的人很容易转型做系统架构。很多资深验证工程师就是靠参考模型打下的基础理解起架构设计来毫无障碍。4. 架构方向学习路线从基础到微架构设计4.1 第一阶段数字电路和基础工具的地基不管做架构还是验证数字电路基础是不能跳过的。建议用《数字设计和计算机体系结构》里关于组合逻辑、时序逻辑的部分打底配合Verilog或SystemVerilog做一点小模块设计深刻理解时序约束是什么概念。很多细节比如建立时间和保持时间、亚稳态、跨时钟域处理如果在这个阶段没弄懂后面做架构设计会产生很大隐患。工具方面至少要熟练使用一种仿真工具和一个综合工具。开源环境选Verilator加GTKWave商业环境用VCS/QuestaSim加Design Compiler。不建议在这个阶段贪多重点是把“写RTL-仿真-看波形-修正”这个循环跑顺。如果连基本的波形都读不利索后面看架构层面的时序分析会非常吃力。4.2 第二阶段体系结构原理到微架构落地有了数字电路的地基就可以系统学习体系结构。建议先用量化方法那本书的1到5章把性能公式、流水线原理、存储层次和并行处理基础过一遍。理论部分学完想办法找一个开源处理器项目做RTL级的理解比如在学校课程里基于RISC-V的SCARV、PULP这类项目或者GitHub上任意一个万行级别的处理器逐一对照目录结构指出取指、译码、执行、访存、写回级的模块和对应信号。很多人卡在这一步原因是直接读RTL代码信息量太大。这里我有一个小技巧先只关注一条最简单指令的生命周期比如add指令从取指到写回信号名一级级往后追。把这条指令的路径搞清楚了再扩展到load、store、branch最后就自然建立起整体流水线视图。切忌刚开始就想show出全部模块。4.3 第三阶段微架构设计实践和论文阅读进入第三阶段尝试独立做一个小规模的处理器微架构设计再进一步做总线或NoC的架构评估。比如在一个8核节点上分析Mesh和Ring拓扑的跳数差异结合路由算法估算平均时延。这个阶段开源工具是Concat、SystemC建模、Gem5模拟器。Gem5适合做体系结构探索你可以改Cache参数、改动核数、改频率跑SPEC测试直观观察性能变化。事情做到这个程度回来读ISCA和MICRO的论文就不会觉得陌生了。刚开始读论文不必强求理解所有公式抓住“motivation、idea、method、evaluation”四个要素就好。先看标题和摘要再看图表结论最后才沉下心对照公式。我的经验是每周精读一篇三个月后看架构论文的感觉会完全不同。5. 验证方向学习路线从SystemVerilog到SoC验证5.1 第一阶段掌握验证语言和基本验证组件验证方向同样要有数字电路基础然后花大力气吃透SystemVerilog的验证特性。这里特指的是OOP、随机化、约束和功能覆盖率不是把Verilog语法背一遍。先写一个小型验证环境把driver、monitor、scoreboard和testcase之间的调用关系、数据流关系搞清楚。一个建议是手动实现一个最简的验证环境不用UVM直接用SystemVerilog。这看起来土但能逼着你理解事务级建模、握手协议和比对逻辑的实现过程。等亲手写完之后再学UVM你才明白UVM的类库是为了解决什么问题才存在的。直接上UVM框架学就好像跳过数电去学计算机组成原理很容易背概念用不出来。5.2 第二阶段UVM方法学和完整验证环境搭建UVM是当前功能验证的主流框架。必须重点掌握的有factory机制、phase机制、config机制、sequence机制、寄存器模型和tlm通信。很多人卡在UVM的宏定义上比如uvm_component_utils、uvm_object_utils、uvm_field_utils这些总想背参数。别背先理解背后的注册机制把类的创建由编译期变成运行期的逻辑搞清楚宏就好懂了。这个阶段的实操目标是独立搭建一个完整的UVM验证环境。建议选一个简单的协议模块比如断言握手接口或者SPI、I2C从机模块覆盖正常读写、错误响应、超时场景并收集功能覆盖率。我这个阶段的经验是工程宁可小一点环境层次要齐agent、env、test和case的关系必须结构清晰否则后面做SoC级验证时会因为环境设计混乱吃大亏。5.3 第三阶段SoC验证能力和专项验证方向熟悉UVM之后要开始接触SoC验证。SoC验证要处理的不只是某个模块的交易级验证还涉及多核互联、中断系统、启动流程、外设配置、低功耗状态切换等系统级行为。这时你需要学会搭建SoC验证平台一般是把处理器核的模型放进去通过编译运行C程序驱动系统进行激励观察总线事务和外部接口行为。专项验证方向也在这个阶段展开。常见的细分方向包括缓存一致性验证MTL验证也就是memory transaction layer低功耗验证比如UPF的功耗意图验证形式验证比如等价性检查和断言形式化以及硅前驱动的软件验证。不要全都学结合项目需求挑一个方向纵深发展。业内对SoC验证工程师的需求量大但对系统思维要求也高这也是为什么我做开头就建议架构和验证一起学这个阶段优势会体现得很明显。6. 常见问题与避坑心得6.1 学习路线中的典型卡点和排查方法第一条最常遇到的问题是SystemVerilog仿真器和UVM环境装好以后编译报一堆莫名其妙的信息。这往往不是环境出问题而是大家直接用uvm_macros.svh的路径引用错误。推荐使用包的形式在仿真命令里加incdir和uvm参数编译UVM库而不是把uvm源码胡乱复制进工作目录。正规仿真工具默认支持-uvm选项只要把库路径指对就顺利了。第二条很多人写了一堆UVM sequence却不知道怎么控制测试结束导致仿真一直跑不完。原因多半是phase机制理解不透sequence没有把item完整消费完或者objection没有raise/drop。建议在写第一个用例的时候就在sequence里增加item数量的计数并在drain time用phase.drop_objection同时仿真脚本里加最大时间保护比如-timelimit避免无限循环拖掉整个回归时间。第三条架构方向容易踩的坑是一上来就读论文结果越看越迷糊。我的解决思路是对照着已有芯片的开源实现读论文。比如先快速读一篇讲非阻塞Cache设计的论文再去看某个开源处理器里如何实现非阻塞Cache的表项管理理论映射到代码后理解成本会低很多。另外论文里很多实验效果是建立在特定target和benchmark下的不能当成放之四海而皆准的结论。6.2 架构和验证学习要避开的思维误区第一个误区是把验证当成“低门槛”岗位。验证的门槛确实不体现在语言上但体现在“能不能把设计验证闭环”上。只会搭UVM环境不会针对设计风险制定测试策略的人实际上还处于初级阶段。真正资深的功能验证工程师对RTL逻辑烂熟于心甚至能从代码覆盖角度反推架构的合理性。验证能力做到深处和架构设计能力是互通的。第二个误区是忽视层次化验证的思路。模块级验证、子系统级验证、SoC级验证不是简单的大环境套小环境每一次层次跃迁都意味着新的调度策略、复用策略和抽象策略。如果不理解这一点只会在顶层环境里堆模块干涉严重的时候环境极其难维护。好的验验环境设计一定是分层的底层组件保持稳定上层测试场景可灵活配置。这种分层思维其实和架构设计中的模块划分、接口抽象是同一个方法论。第三个误区是放弃书写验证计划。我见过不少人验证环境写完就开始无脑建testcase根本不管哪些功能点已经覆盖哪些还是空白。正确的做法是先做验证计划把测试点和覆盖率目标列成表格每条对应到具体的testcase和场景。写完计划再搭环境后面只要持续check覆盖率就行。养成这个习惯之后做架构评估和风险分析也是有帮助的。6.3 最后再分享一点我个人的体会踩过这么多坑之后我的一个强烈感受是IC架构和验证的学习本质上都是在训练一种面向风险的设计直觉。做架构的人如果只看性能不看实现代价流片后验证会痛不欲生做验证的人如果只看覆盖率不问设计漏洞在哪项目交付也会充满不确定性。所以安排学习路线时最好两个方向的内容交叉着看。今天读一篇架构论文明天就去看对应的验证方案如何构造场景后天再去想如果是自己设计会把可测试性设计放哪里走完这个循环知识就不再是割裂的了。期刊和书单只是路线图上的坐标真正把这条路走通的还是动手做项目并在过程里不断追问“为什么这么设计”和“怎么样才能让设计被充分验证”。建议给自己定一个半年计划前半段把SystemVerilog和UVM环境跑通每次仿真波形和覆盖率督责自己有清晰的分析后半段挑一个开源CPU核独立做流水线理解和总线接口验证两方面合在一起基本就能克服新手阶段的最大障碍。