- 博客(803)
- 收藏
- 关注
RSS订阅原创 寄存器模型生成：从手工到自动化
写代码这件事，总是充满了矛盾。你想要完美控制每一个细节，但又希望能够批量生产。寄存器模型的生成，恰恰体现了这种矛盾。
2025-06-04 16:45:53
33
原创 别再害怕，你的恐惧都是自己编的故事
你会发现，那些让你害怕的人，其实和你一样，都是在这个行业里摸爬滚打的普通人。他们有自己的压力，自己的困扰，自己的局限性。在芯片行业，技术实力才是硬道理，其他的都是浮云。我们在这个行业里，每天都在和复杂的技术打交道，解决各种棘手的问题。大家都怕——怕老板，怕同事，怕客户，怕竞争对手，甚至怕那些刚毕业的新人。毕竟，能在芯片行业生存下来的人，都不是省油的灯。你的能力有多少就是多少，你的价值在哪里就在哪里。下次再遇到让你害怕的情况，试着深呼吸，告诉自己：我没有什么好怕的，我只是在和另一个同样有血有肉的人交流而已。
2025-06-03 07:28:36
165
原创 UVM寄存器模型适配器：连接抽象与现实的桥梁
如何让高层次的抽象模型与底层的具体实现无缝对接？UVM寄存器模型的适配器（Register Layer Adapter）就是解决这个问题的关键组件。它就像一座桥梁，连接着抽象的寄存器操作和具体的总线协议。
2025-06-02 17:17:24
113
原创 UVM验证中的“怪异“寄存器：当标准不够用时
我们总是希望一切都能按照既定的规则运行。UVM寄存器模型为我们提供了强大的基础类，能够描述大多数常见的寄存器行为——清零读取（RC）、写一置位（W1S）、写零置位（W0S）等等。但现实往往比理想复杂，总有那么一些寄存器，它们的行为如此特殊，以至于标准的描述方式显得力不从心。这就是我们今天要谈论的"Quirky" Registers——怪异寄存器。
2025-06-02 17:17:24
122
原创 UVM Register Model集成：从概念到实践
Register Model在UVM testbench中扮演着双重角色：一方面，它是DUT硬件状态的镜像，让我们随时能够查看当前的寄存器值；另一方面，它又是访问硬件的工具，无论是通过front door还是back door的方式。Register Model既要维护状态，又要提供访问机制，这种设计让它成为验证环境中的核心组件。
2025-06-02 17:17:24
106
原创 SoC设计中的复杂地址映射：当一个寄存器有多张“身份证“
在芯片设计的世界里，地址映射就像城市的街道系统。简单的芯片可能只需要一条主干道，但复杂的SoC（系统级芯片）往往需要错综复杂的道路网络。今天我们来聊聊UVM寄存器模型中最有趣也最挑战的部分——复杂地址映射。
2025-06-02 10:39:49
77
原创 为什么需要寄存器模型抽象
在硬件验证的世界里，寄存器就像是设计的神经系统——它们承载着控制信号，存储着状态信息，连接着软硬件的世界。但如何在验证环境中优雅地管理这些寄存器，却是一个让很多工程师头疼的问题。UVM寄存器模型就是为了解决这个问题而生的。
2025-06-02 10:39:49
90
原创 SoC设计中的复杂地址映射：当一个寄存器有多张“身份证“
在芯片设计的世界里，地址映射就像城市的街道系统。简单的芯片可能只需要一条主干道，但复杂的SoC（系统级芯片）往往需要错综复杂的道路网络。今天我们来聊聊UVM寄存器模型中最有趣也最挑战的部分——复杂地址映射。
2025-06-02 10:39:49
64
原创 正则表达式的前世今生
Perl的实现往前走了一大步，在原有语法基础上增加了很多修改，形成了所谓的"Perl flavor"。今天，正则表达式真的是无处不在。从最新的JavaScript框架到70年代的Unix工具，从办公软件到现代编程语言，你很难找到一个不支持正则表达式的地方。很多强大的工具都有这个特点，表面上看起来很普及，但真正能熟练运用的人并不多。工具的命名往往蕴含着深刻的设计思想，grep这个看似随意的名字，其实承载着几代程序员的智慧结晶。这或许说明了一个道理：很多看似不相关的技术，在底层往往有着相似的数学基础。
2025-06-01 17:17:01
1002
原创 让Parameter Package成为你的配置管家
在做验证的时候，我们经常遇到这样的情况：DUT里用了某个参数值，但在testbench里又写了一个完全不同的值。然后debug的时候才发现，原来是参数数数值或者类型不匹配导致的问题。这种低级错误真的很让人头疼。想象一下，你的DUT有个总线宽度参数是32位，但你在testbench里不小心写成了64位。或者更糟糕的是，你改了DUT的参数，但忘记同步更新testbench。这种事情在复杂项目里太常见了。为什么需要Parameter Package？
2025-06-01 11:21:15
79
原创 SystemVerilog编码指南：从混乱到秩序
这就像整理房间一样，虽然乱糟糟的房间也能住人，但井井有条的环境总是让人心情愉悦，工作效率更高。好的代码风格不会让你的设计跑得更快，但它能让其他人（包括几个月后的你自己）更容易理解和维护。每次进入新的嵌套块时，使用一致的空格数缩进。千万别用Tab键，因为不同编辑器的Tab设置不一样。这样做能让代码更清晰，调试时也更容易定位问题。，你精心调整的格式在别人那里可能就乱套了。一行只写一个声明或语句。
2025-06-01 11:21:15
98
原创 UVM调试那些事儿：内置功能其实够用
写UVM testbench的时候，经常会遇到一些莫名其妙的问题。配置没传下去，Factory override没生效，phase卡住了，objection没匹配上。这些问题就像黑盒子一样，让人抓狂。UVM的Resource Database是通过字符串匹配来工作的。这就像生活中的很多事情一样，看起来简单，实际上魔鬼都在细节里。一个字符打错了，整个配置就传不下去。其实，UVM本身就提供了不少调试功能。虽然simulator也有自己的debug工具，但了解UVM内置的这些功能，往往能更快定位问题。
2025-05-31 14:15:39
162
原创 UVM命令行处理：调试路上的得力助手
UVM的命令行处理器（Command-Line Processor）让我们能够灵活控制testbench的行为，更重要的是，它体现了一种"参数化思维"——通过外部配置来改变内部行为。想象一下，如果每次想要改变verbosity级别或者启用debug功能，都需要修改代码、重新编译，那会是多么痛苦的事情。这就像每次调整汽车的空调温度都要拆开仪表盘一样荒谬。这里的"临时性"是关键词——我们用它来启用额外的debug信息或者调整某些行为。内置的UVM Plusargs：开箱即用的强大功能。为什么需要命令行处理器？
2025-05-31 14:15:39
21
原创 别在有毒的环境里证明自己
更可怕的是，很多人在这种环境里待久了，开始怀疑自己。芯片行业哪里都有压力，关键是要分清楚什么是正常的工作压力，什么是人为制造的精神折磨。项目延期了，责任都推给下面的人，功劳却都是领导的。最要命的是，这种环境下，大家都在拼命证明自己不是那个最差的。如果你发现自己每天上班都像上刑场，周末都在焦虑下周的工作，和同事聊天都要小心翼翼，那可能真的该考虑换个环境了。做芯片需要的是专注和创造力，但这种环境只会消耗你的精神能量，让你变得焦虑、敏感、自我怀疑。在一个有毒的环境里，你越是努力证明自己，越是在给这种毒性买单。
2025-05-31 07:31:38
172
原创 培训不出来的专长，才是你的护城河
真正让你不可替代的，是那些需要时间积累、需要个人天赋、需要行业沉淀的东西。所以，与其担心被培训出来的新人替代，不如想想自己的护城河在哪里。但仔细想想，那些需要创造性思维、需要复杂判断的工作，依然是人类的优势。真正的知识往往是"不可言传的"。毕竟，真正的专长从来不是学出来的，而是干出来的。比如对某个方法概念的深度理解，这不是看几本书就能搞懂的，需要在多次流片中积累经验，需要踩过各种坑。他们能照着流程走，能用工具，能写代码，但遇到真正的问题时，往往不知道怎么处理。真正的专长，其实是那些无法标准化的东西。
2025-05-30 07:31:10
179
原创 UVM消息系统：验证中的沟通
一个好的验证环境不仅要能发现bug，更要能清晰地告诉你发生了什么。UVM的消息系统就像是验证平台的神经网络，把各种信息传递给工程师。连sequence_item和sequence这些对象也能使用消息功能。这个系统内嵌在所有UVM组件中，因为它们都继承自。让每一条消息都有意义，让每一个组件都能发声。
2025-05-29 16:43:49
170
原创 UVM命令行调试控制：让验证过程更灵活
在做UVM验证的时候，我们经常会遇到这样的困扰：代码写好了，但调试信息要么太少看不清问题，要么太多淹没了关键信息。如果每次都要修改代码重新编译，那效率就太低了。幸好UVM提供了一套命令行控制机制，让我们可以在运行时灵活调整verbosity和消息行为。想象一下，你写了一个复杂的验证环境，里面有很多组件，每个组件都会输出各种级别的信息。在开发阶段，你可能希望看到所有细节；但在回归测试时，你只想看到关键的错误和警告。如果没有灵活的控制手段，你要么忍受信息过载，要么错过重要线索。为什么需要命令行控制。
2025-05-29 16:43:49
199
原创 UVM中的End-of-Test机制：让验证有序收场
一个好的开始固然重要，但优雅的结束同样关键。就像一场精彩的音乐会需要完美的谢幕一样，UVM testbench也需要一个清晰明确的结束机制。今天我们来聊聊UVM中的End-of-Test和Objection机制。UVM testbench如果使用标准phasing，会经历三个阶段：零时间的构建连接阶段、耗时的执行阶段，以及零时间的清理阶段。任何复杂的过程都需要明确的开始、进行和结束边界。
2025-05-29 16:43:49
92
原创 UVM Report Catcher：在错误中寻找转机的艺术
UVM Report Catcher是一个内置的回调机制，专门用来处理那些"不太合适"的消息。想象一下，你的代码里有个第三方IP总是抛出fatal error，但实际上这个错误在你的测试中并不致命。传统的做法可能是修改源码，但Report Catcher提供了一个更优雅的解决方案。代码中的消息告诉我们发生了什么。但有时候，这些消息并不总是我们想要的样子。当消息产生时，先经过报告捕获器的处理，然后才传递给消息服务器。这个过程中，你可以修改消息的严重性、详细程度、ID、动作，甚至是内容本身。
2025-05-29 16:43:49
111
原创 “做那个补缺口的人“
缺什么，什么就值钱。职场也是一样，你提供的如果是市场上到处都有的东西，那你就只能拿到市场价；在芯片公司里，会写Verilog的人一抓一大把，会用EDA工具的也不少，但能在关键时刻站出来，把那些别人不想碰、不会碰的事情搞定的人，永远稀缺。但如果你愿意去做，并且做成了，那你就成了团队效率提升的功臣。如果你既懂硬件又懂软件，能在两个团队之间做桥梁，那你的价值就不是简单的1+1了。你得看看你的团队、你的项目、你的公司，到底缺什么。不是你会写多少行代码，也不是你熟悉多少个工具，而是你能解决别人解决不了的问题。
2025-05-29 12:11:42
245
原创 “做那个补缺口的人“
缺什么，什么就值钱。职场也是一样，你提供的如果是市场上到处都有的东西，那你就只能拿到市场价；在芯片公司里，会写Verilog的人一抓一大把，会用EDA工具的也不少，但能在关键时刻站出来，把那些别人不想碰、不会碰的事情搞定的人，永远稀缺。但如果你愿意去做，并且做成了，那你就成了团队效率提升的功臣。如果你既懂硬件又懂软件，能在两个团队之间做桥梁，那你的价值就不是简单的1+1了。你得看看你的团队、你的项目、你的公司，到底缺什么。不是你会写多少行代码，也不是你熟悉多少个工具，而是你能解决别人解决不了的问题。
2025-05-29 12:11:42
233
原创 “做那个补缺口的人“
缺什么，什么就值钱。职场也是一样，你提供的如果是市场上到处都有的东西，那你就只能拿到市场价；在芯片公司里，会写Verilog的人一抓一大把，会用EDA工具的也不少，但能在关键时刻站出来，把那些别人不想碰、不会碰的事情搞定的人，永远稀缺。但如果你愿意去做，并且做成了，那你就成了团队效率提升的功臣。如果你既懂硬件又懂软件，能在两个团队之间做桥梁，那你的价值就不是简单的1+1了。你得看看你的团队、你的项目、你的公司，到底缺什么。不是你会写多少行代码，也不是你熟悉多少个工具，而是你能解决别人解决不了的问题。
2025-05-29 12:11:42
108
原创 三大EDA要断供？国产替代的窗口期真的来了
国产EDA这几年其实一直在默默发力，华大九天在模拟电路设计上已经有了不错的口碑，概伦电子在建模仿真方面也站住了脚，还有一大批新兴公司在各个细分领域寻找突破点。就像温水煮青蛙，当年选择这些工具的时候，我们看重的是它们的成熟和高效。但问题是，当你习惯了开别人的车，有一天车主说不让你开了，你才发现自己哪也去不了。EDA工具的复杂度超出很多人的想象，它不只是一个软件，而是几十年技术积累的结晶。需要钱，需要人，需要时间，更需要整个产业链的协同配合。好在现在已经有了一些基础，有了一些积累，也有了一些成功的案例。
2025-05-28 20:08:15
280
原创 越是负责任的人，活得越痛苦
负责任的人，往往陷入一种怪圈：事情做得越好，分到的活就越多，而那些混日子的人反而活得轻松自在。芯片行业不会因为一个人的离开而停转，但一个人的健康和幸福感一旦失去，却很难再找回来。当芯片出了问题，所有人的目光都会投向那个最靠谱的人，好像他天生就该有解决一切问题的能力。一个团队里，总有那么几个人扛着最难啃的模块，加班debug，而另一拨人早就收工回家了。，让你的付出被看见，这不是虚荣，而是职场生存的必要技能。负责任的人，最怕的不是工作量大，而是看不到工作的意义。，明确什么是你能控制的，什么是你无法控制的。
2025-05-28 07:59:53
353
原创 UVM中的Metric Analyzers：监控系统非功能性指标
在验证环境中，我们不仅要关注DUT功能是否正确，还需要监控各种非功能性指标。这就像评价一个人，不光要看他能不能完成任务，还要看他的效率、体力消耗等各方面表现。UVM的Metric Analyzers就是专门干这个活的组件。想象一下，如果你在管理一个工厂，除了要确保产品质量合格，你肯定还想知道生产线的效率如何、能耗情况怎样。Metric Analyzers就扮演着这样的角色——它们是验证环境中的"性能监督员"。Metric Analyzers在架构上其实很标准化，它们通常是标准的analysis组件。
2025-05-27 18:20:50
110
原创 UVM验证环境中的后期分析：Post-Run Phases详解
许多analysis组件在仿真运行期间会持续进行分析工作，但有时候我们需要延迟分析，直到收集到所有数据。或者某个组件需要在仿真结束时做最终检查。对于这些场景，UVM提供了extract、check和report这三个post-run phases。在比赛进行中，你可以看到每个选手的实时状态，但要统计最终排名、分析整体表现趋势，就必须等到所有选手都冲过终点线。就像医生看病一样，检查完毕后还需要时间来分析化验结果，得出最终诊断。UVM框架深刻理解这一点，专门设计了Post-Run Phases来处理这类需求。
2025-05-27 18:20:50
253
原创 设计验证中的Predictor和Scoreboard：构建可靠验证体系
Predictor本质上是DUT功能的"黄金参考模型"。它接收与DUT相同的输入激励，然后产生我们认为正确的期望响应数据。这个概念很直观：既然我们要验证DUT的行为是否正确，那就需要一个"标准答案"来对比。当我们向DUT（Design Under Test）输入随机激励时，如何自动判断输出结果是否正确？当我们向DUT（Design Under Test）输入随机激励时，如何自动判断输出结果是否正确？Predictor：验证体系的"黄金标准"
2025-05-27 18:20:50
142
原创 ARM改口了，小米XRING O1真的是自研芯片
上周小米发布XRING O1芯片的时候，业内议论纷纷。有人说这不过是换个马甲的ARM方案，有人质疑小米的技术实力。但是这两天，ARM官方主动出来澄清了——小米的XRING O1确实没有使用ARM的CSS客户端平台解决方案。这个转折挺有意思的。ARM作为IP授权商，通常不会主动为客户的技术实力做背书。这次却专门发声明，说小米确实是自己设计的系统级架构。背后的含义，懂的人都懂。
2025-05-27 12:12:23
489
原创 UVM分析系统：设计验证中的观察者艺术
分析部分的任务就是观察行为并做出判断。它需要判断设计是否按照规范正确运行，包括功能行为、性能表现以及功耗管理等各个方面。这种判断不是凭空而来的，而是基于对预期行为的精确建模。最难的往往不是生成激励，而是如何准确判断设计是否正确工作。这就像医生诊断病人一样，需要观察各种症状，分析数据，最终做出准确判断。UVM的分析系统正是为此而生。设计验证本质上包含两个核心环节：第一是生成输入激励让设计进入已知状态，第二是分析设计的响应是否符合预期。这个过程看似简单，实际上蕴含着深刻的思考——分析的本质：观察与判断。
2025-05-27 07:46:42
145
原创 从Sequence中访问配置资源：UVM验证的实用指南
在UVM验证环境中，sequence经常需要访问testbench的各种资源，比如register model或者configuration object。想想看，这就像我们出门前先检查钱包、钥匙、手机一样，sequence也需要先确保自己有必要的"装备"，然后才能开始干活。把获取资源作为sequence的body()方法的第一个动作。
2025-05-27 07:46:42
144
原创 参数化处理：让UVM验证环境更灵活
参数化就像是给验证环境插上了翅膀。想象一下，同一个验证环境能够适配8位、16位、32位甚至更宽的数据总线，这种灵活性正是现代验证所追求的。但是，如何优雅地处理这些参数，却是一个需要深度思考的问题。Parameters在硬件设计中扮演着关键角色，它们通常用来配置设计IP和接口。从VIP的角度来看，parameters主要影响总线字段的宽度或者使用中的通道数量。同一个设计的不同参数配置，到底算是同一个设计还是不同的设计？
2025-05-26 16:55:40
361
原创 UVM中的抽象-具体类连接方法：一种值得思考的设计模式
除了常见的virtual interface方式，还有一种颇具意味的方法——抽象-具体类连接模式。这种方法展现了面向对象编程中一个重要的思想：通过抽象来隔离变化。在这个模式中，抽象类定义了BFM中所有可用方法的模板，就像是画出了一个轮廓；而具体类则在BFM中声明并扩展抽象类，填充具体的实现内容。这样，具体类的句柄通过uvm_config_db传递给agent类中的抽象句柄。需要注意的是，这种方法只能在仿真环境中使用，不支持硬件加速平台。抽象-具体类连接模式的精髓在于将接口的定义和实现分离开来。
2025-05-26 16:55:40
175
原创 只有理解复杂，才能实现简单
表面看起来简单的东西，背后往往藏着你看不见的复杂。真正的简单也不是删删减减，而是把复杂的东西理解透了之后的自然呈现。就像一颗芯片，用户看到的是几个引脚，但里面可能有几十亿个晶体管在协调工作。你不理解那几十亿个晶体管的逻辑，就别想设计出好用的芯片。很多人喜欢抄现成的方案，拿来就用，遇到问题就头疼。为什么？因为他们只看到了表面的简单，没有理解底层的复杂。当系统出现异常的时候，他们就像无头苍蝇，改一处坏三处，最后只能推倒重来。
2025-05-26 12:28:30
334
原创 深入理解UVM中的Virtual Interface BFMs
为了让验证组件真正做到可重用，它们需要被组织成uvm_agents，并配备相应的信号interface。当我们构建一个验证组件时，总是面临着一个根本性的选择：是让interface充当一个简单的信号容器，还是赋予它更多的智慧？如何优雅地将可重用的验证组件在不同的项目间共享？：负责验证的被动部分，通过virtual interface句柄采样interface活动。：负责验证的主动部分，将sequence_items中的信息转换为interface活动。从信号容器到验证组件的演进。
2025-05-25 21:10:12
195
原创 UVM中Sequencer与Driver的连接
在UVM验证环境中，sequences和drivers之间的协作就像一场精心编排的舞蹈。它们通过一个双向的TLM通信机制来完成这种协作，而这个机制的核心就在sequencer中实现。这里有个有趣的细节：port和export类都用sequence_items的类型来参数化，用于request和response事务。这种设计体现了一个重要的系统思考：通过标准化的接口来实现组件间的解耦。，这个port需要连接到sequencer中对应的。
2025-05-25 21:10:12
120
原创 UVM Testbench与DUT的连接
BFM组件扮演着翻译官的角色，它们具有静态的信号端口，可以直接与硬件信号交互。这种设计很巧妙——既保持了UVM对象的抽象性，又建立了与硬件世界的实际连接。UVM testbench中的对象们有个天生的限制——它们无法直接碰触到DUT的信号线。这不是设计的缺陷，而是软件抽象与硬件实现之间必然的鸿沟。如何让UVM testbench与RTL DUT之间建立起有效的连接，需要理解UVM对象域和硬件信号域之间的本质差异。
2025-05-25 21:10:12
177
原创 文档自动化：在 ASIC 验证中的智慧实践
作为验证工程师，我们经常在代码和文档之间挣扎。老实说，这两者往往像两条平行线，很难保持同步。今天就来聊聊这个痛点，以及一个解决方案 - 让代码自己"说话"。
2025-05-23 23:02:59
310
原创 如何把复杂问题变简单
我们常常面临这样的场景：拿到一份几百页的功能规格书，然后被告知"去验证它"。没有明确的方向，没有具体的计划，只有一堆模糊的要求和紧张的时间表。
2025-05-23 23:02:59
129
原创 验证策略的艺术
也有的特性需要同时在block和chip级验证，虽然工作量增加了，但避免了后期可能出现的大问题。在实际工作中，我们经常需要决定某个功能应该在block级还是chip级进行验证。这不是随意的选择，而是由功能本身决定的。一个好的验证策略就像指南针，不仅能帮我们找到出路，还能在最短的时间内发现所有藏得最深的bug。而如果它跨越模块边界，比如芯片级别的总线协议或跨模块信号，就必须在芯片级验证。如果一个test object深埋在模块内部，那么在block级验证就合适。
2025-05-23 23:02:59
76
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人