- 博客(1465)
- 收藏
- 关注
RSS订阅原创 为什么最忙的Leader,反而最不值钱?
而同样这三天,如果他去跟产品部门谈合作,争取到一个新的芯片项目立项,那可能是几千万的盘子。或者花时间梳理团队的技术壁垒,帮公司拿下一个重要客户的定制需求,这才是杠杆效应。一个项目Leader亲自上手优化关键路径的时序,熬了三个通宵终于收敛了。每天盯着仿真波形、改RTL代码看起来很拼,实际上是在用低价值的忙碌,逃避真正需要他解决的问题。当一个Leader把全部精力耗在具体技术细节上,他就失去了为团队争取更大价值的能力。他还在用工程师的思维干活,拿着Leader的工资,做着性价比最低的事。
2026-01-29 22:09:31
284
原创 为什么设计觉得完美的芯片,到验证手里能爆出一堆bug?
设计人员的思维路径已经固化在”我想实现什么功能”上,测试也会沿着这条路径走。设计一个UART模块,就测一测正常收发数据,波特率切换,也许再加几个异常情况处理。还有一类最麻烦,也最重要，就是需求文档写得模棱两可,设计按一种理解实现了,验证按另一种理解验证了,结果对不上。设计和验证从不同角度理解同一份需求,碰撞出来的分歧恰恰暴露了规范中的模糊地带。设计工程师最崩溃的时刻,大概就是信心满满地提交代码,然后被验证团队甩回来一份长长的bug列表。那些被验证虐过的设计,往往才是真正robust的设计。
2026-01-29 09:09:03
377
原创 以APB为例，多外设验证的陷阱
APB是典型的共享总线架构。PADDR、PWRITE、PWDATA这些信号是所有外设共享的，每个外设通过独立的PSEL片选信号来判断主机是否在访问自己。理论上，当PSEL无效时，外设应该完全不响应总线操作。PRDATA输出没有切换到高阻态，干扰总线上其他外设的数据回读；PREADY信号异常拉低，导致整条总线被hang住；内部寄存器被误写入，状态被破坏；地址译码逻辑有漏洞，把不该响应的地址也响应了。做过SoC验证的工程师都知道，APB总线上通常挂着十几个甚至几十个外设。
2026-01-28 21:47:24
264
原创 为什么芯片团队最讨厌“MBA式领导“？
不懂技术的leader，要么被工程师牵着鼻子走，要么瞎拍板导致项目翻车。你得能看懂他们的代码，得能理解他们遇到的技术瓶颈，得能在关键时刻给出靠谱的技术建议。能跟工程师在技术层面对话，能判断技术方案的可行性，能真正理解项目的难点和风险——有了这个基础，管理能力才能发挥作用。设计评审会上，工程师在讨论流水线深度和频率目标的trade-off，leader插不上话，时间长了，想让芯片工程师心服口服，光靠管理学那套理论是撑不住的，还得有真本事。不懂技术的领导，在关键决策点上就是个瞎子。既懂技术又懂管理的那个。
2026-01-28 07:58:50
14
原创 为什么芯片团队最讨厌“MBA式领导“？
不懂技术的leader，要么被工程师牵着鼻子走，要么瞎拍板导致项目翻车。你得能看懂他们的代码，得能理解他们遇到的技术瓶颈，得能在关键时刻给出靠谱的技术建议。能跟工程师在技术层面对话，能判断技术方案的可行性，能真正理解项目的难点和风险——有了这个基础，管理能力才能发挥作用。设计评审会上，工程师在讨论流水线深度和频率目标的trade-off，leader插不上话，时间长了，想让芯片工程师心服口服，光靠管理学那套理论是撑不住的，还得有真本事。不懂技术的领导，在关键决策点上就是个瞎子。既懂技术又懂管理的那个。
2026-01-28 07:58:50
17
原创 为什么芯片团队最讨厌“MBA式领导“？
不懂技术的leader，要么被工程师牵着鼻子走，要么瞎拍板导致项目翻车。你得能看懂他们的代码，得能理解他们遇到的技术瓶颈，得能在关键时刻给出靠谱的技术建议。能跟工程师在技术层面对话，能判断技术方案的可行性，能真正理解项目的难点和风险——有了这个基础，管理能力才能发挥作用。设计评审会上，工程师在讨论流水线深度和频率目标的trade-off，leader插不上话，时间长了，想让芯片工程师心服口服，光靠管理学那套理论是撑不住的，还得有真本事。不懂技术的领导，在关键决策点上就是个瞎子。既懂技术又懂管理的那个。
2026-01-28 07:58:50
202
原创 为什么芯片团队最讨厌“MBA式领导“？
不懂技术的leader，要么被工程师牵着鼻子走，要么瞎拍板导致项目翻车。你得能看懂他们的代码，得能理解他们遇到的技术瓶颈，得能在关键时刻给出靠谱的技术建议。能跟工程师在技术层面对话，能判断技术方案的可行性，能真正理解项目的难点和风险——有了这个基础，管理能力才能发挥作用。设计评审会上，工程师在讨论流水线深度和频率目标的trade-off，leader插不上话，时间长了，想让芯片工程师心服口服，光靠管理学那套理论是撑不住的，还得有真本事。不懂技术的领导，在关键决策点上就是个瞎子。既懂技术又懂管理的那个。
2026-01-28 07:58:50
368
原创 会写代码不算本事，会配合才是
见过太多技术很牛的工程师，写代码写得飞起，但就是不会和人配合，结果要么被孤立，要么把团队氛围搞得一团糟。也见过一些技术不是最拔尖的人，但因为懂得怎么和不同的人协作，反而能push项目往前走，最后成了团队的核心。前端写RTL，验证跑testcase，后端做layout，DFT插扫描链，每个岗位都有自己的专业壁垒。真正会配合的人，不是那种谁说什么都点头的老好人，而是知道什么时候该坚持、什么时候该让步的人。最后tape out的那一刻，回头看，会发现最大的收获不是掌握了多少技术，而是学会了怎么和人一起成事。
2026-01-27 07:46:18
382
原创 验证的隐藏成本:外设模型比参考模型更要命
一颗SoC芯片对外有UART、I2C、GPIO、PWM接口,对内还得跟ADC、DAC、时钟树、复位电路这些模拟模块交互。验证一个SoC的UART模块,DUT发出的是串行数据流,波特率115200。如果验证平台里没有UART接收器模型,谁来接这些数据?难道手工去数每个bit的时序,然后在波形里人肉解码?很多团队觉得参考模型太重,干脆不做。但问题是,真实的芯片不会孤立存在。
2026-01-26 07:52:19
297
原创 组合逻辑毛刺：当代码正确但芯片却出错
在芯片设计中，。组合逻辑毛刺，本质上就是电路在状态切换时产生的短暂脉冲干扰。想象一下，当多个信号同时变化时，由于传输路径不同，它们到达目标的时间就会有差异，这种时间差会在输出端产生意料之外的瞬间跳变。举个实际的例子。当地址从3'b100变到3'b101时，理论上只有最低位变化。可能会出现这样的中间态，每个中间态都会让输出产生一次跳变。
2026-01-25 19:56:09
293
原创 国产芯片行业要的不是遍地开花,而是几棵参天大树
钱不好拿了,订单开始往头部集中,那些靠PPT融资、靠概念活着的公司,日子越来越难过。并购的消息隔三差五就冒出来,要么是大鱼吃小鱼,要么就是抱团取暖。从2018年开始,各路资本、地方政府、创业者一窝蜂扎进来,仿佛只要挂上”国产替代”四个字,就能躺着数钱。那些天天烧钱打价格战的,那些产品同质化严重的,该出局就出局。现在的洗牌,只是在清理杂草,给真正有潜力的树腾出空间和养分。等这波过去,留下来的企业,才真正有资格跟国际巨头掰手腕。那些抱怨行业不景气的,可能从一开始就没想明白,自己到底有什么核心竞争力。
2026-01-25 08:18:28
36
原创 寄存器验证的”致命陷阱”：Excel表格
很多团队都遭遇过类似的问题:脚本本身没bug,生成逻辑也正确,但输入数据源——那份Excel表格——出了岔子。在芯片研发流程中,寄存器验证是个看起来很”安全”的环节。毕竟都是自动化脚本生成代码,按理说应该万无一失。某个芯片项目进入验证阶段,工程师信心满满地运行自动生成的寄存器验证代码，结果仿真死活跑不通。
2026-01-24 15:01:42
243
原创 为什么你要先测那20%的功能?
芯片研发周期动辄1到3年,这意味着你在2026年立项的芯片,可能要到2028年才能流片。这期间市场会变,技术会变,客户的想法更会变。市场调研给你的只是模糊的方向:“我们需要一颗支持xxx协议的芯片,功耗要低。” 具体怎么低?哪些场景下要多低?边界条件是什么?这些问题往往没有明确答案。于是芯片公司只能自己定义功能。既然不确定用户会怎么用,那就多做几种方案:支持模式A,也支持模式B;可以配置成方式1,也能配置成方式2。这些”也许用得上”的功能,就占据了大量的芯片面积。还有就是保护电路。
2026-01-24 06:56:25
295
原创 为什么有的芯片会”上电即死”?
因为RTL仿真环境太理想化,复位信号一来,所有寄存器乖乖同时归零。但真实硅片上,复位信号从PAD传到芯片内部深处,会有延迟,会有偏斜,不同区域的电路复位时间根本不一样。芯片上电那一瞬间,内部所有寄存器的状态都是不确定的。有的是0,有的是1,完全随机。如果复位电路设计有问题,某些状态机可能会进入非法状态,然后整个芯片就卡死在那里。前仿都过了,芯片流片回来就是点不亮。这种情况在行业里见得太多。这两个功能看起来简单,实际上是芯片最容易翻车的陷阱。
2026-01-23 07:26:05
260
原创 为什么验证的参考模型比RTL的错误更少？
参考模型也是人写的代码,设计模块也是人写的代码,凭什么你写的就是对的,我写的就该怀疑?参考模型并没有什么魔法能保证绝对正确。它和设计模块一样,都可能有bug,都可能理解偏了需求。那为什么验证体系还要把参考模型当成”黄金标准”?答案是:没法保证绝对正确,但可以做到相对正确。关键在于参考模型的写法和设计完全不一样。
2026-01-21 08:50:41
285
原创 为什么说验证工程师要懂点测试?
很多做验证的工程师每天写testbench、跑仿真,却从没去测试实验室看过真实的测试设备长什么样。这就像在模拟器里练了一万小时车,却从没摸过真车方向盘。,只不过一个在流片前,一个在流片后。。你在代码里写,测试工程师在ATE上设置的就是”在某个时刻给SCLK引脚施加高电平,给MOSI引脚输出数据位”。再看monitor。到了真实测试环境,这个功能就是示波器或逻辑分析仪干的活——在时钟上升沿触发,捕获valid信号有效时的data_out值。。
2026-01-20 19:47:55
329
原创 最被低估的技能：会夸人
验证工程师连着加班一周终于把corner case覆盖全了，这时候一句"辛苦了，这波coverage提升很关键"比十句"这是你的本职工作"有用得多。后端工程师费了老劲把某个module的timing收敛了，一句"这个module确实难搞，能搞定不容易"比直接扔下一个module有效得多。那些被认可、被看见的人，会更愿意投入，更愿意承担责任，甚至更愿意帮助别人。久而久之，大家不敢尝试新东西，不愿意主动担责，能少说就少说，能躲就躲。毕竟，道理谁都懂，但能让人愿意继续拼下去的，从来不只是道理。
2026-01-20 08:18:17
304
原创 寄存器验证背后的设计陷阱
某芯片的中断状态位更新有500个时钟周期的延迟，还需要等待各种状态。仿真跑testcase时这个延迟完全符合时序要求,RTL代码也没有任何逻辑错误。但软件工程师在调试中断处理函数时,发现读到的状态总是”旧的”,需要加一堆等待和轮询,整个中断响应时间被拖得很长。做寄存器验证的时候,很多团队把精力放在抓读写不一致、复位值错误这些硬核bug上。这当然重要,芯片流片出去如果连基本的读写都不对,那就是灾难性的。但真正让人头疼的,往往不是这些会直接导致功能失效的错误。
2026-01-19 21:11:27
24
原创 研发测试和量产测试有什么不同？
测试程序需要经过严格的验证和优化,确保既不会漏掉有缺陷的芯片,也不会误杀良品。而量产测试追求的是高良率和低测试成本,失败意味着生产出了废品。研发阶段可能会跑几十万甚至上百万个测试向量,到量产时要精简到几千个,既要保证测试覆盖率,又要控制测试时间。量产测试用的是ATE(自动测试设备),强调的是速度和效率,一台设备可能同时测试几十上百颗芯片。这个阶段工程师要做的是实验性质的工作,通过各种测试手段来确认电路设计、功耗指标是否符合规格书的要求。——研发测试和量产测试,它们的目标、方法、甚至思维方式都截然不同。
2026-01-19 07:59:44
306
原创 芯片行业的”羊群效应”：大家都在卷同一个方向？
所以你会看到一种现象——大公司有资源试错,可以布局多条产品线,用一两个爆款养活其他尝试。小公司只能all in一个方向,赌对了飞升,赌错了出局。那些最早冲进去的公司已经占据生态位,后来者只能喝汤,甚至连汤都没得喝。投资人认可的方向更容易拿到钱,产业链成熟的赛道供应商配合度更高,大家都在做的事情招人也容易。那些看起来不性感、市场不够大、短期看不到回报的方向,反而可能孕育着下一个十年的增长点。这是人类几万年进化出来的本能——跟着大部队走,至少不会饿死。没有标准答案,只有不同的选择和相应的代价。
2026-01-18 09:13:51
30
原创 芯片仿真为什么不能上来就跑随机测试?
太多新人犯同一个错误——testbench还没完全搭好,就迫不及待地开始跑随机测试。这种事为什么会发生?因为很多人。
2026-01-17 10:26:32
295
1
原创 IP验证最终回归到时序级建模
设计的RTL代码严格按照时钟周期工作,第10个时钟上升沿写入数据,第15个时钟上升沿读出数据。而参考模型如果用Python写,内部用队列结构模拟,可能第1秒push数据,第2秒pop数据。这就意味着参考模型不能完全脱离硬件时序,它需要理解时钟周期、握手信号、ready/valid协议这些底层概念。有时DUT第20周期输出,有时第25周期输出,而参考模型的输出时间也在飘。有人会说,不关心时序不就可以了，这样很多复杂乱序处理、延迟变化、突发流量等各种情况就验证不够完备。,这就是时序同步的关键。
2026-01-16 07:34:52
403
原创 你的团队有验证架构师么？
大家都在用UVM的类库、写着继承自uvm_sequence的代码,TB里也有Agent、Env这些标准组件,看起来很规范。但仔细一看,那些最核心的架构设计工作——接口怎么抽象、事务和信号怎么转换、多Agent怎么协同,往往没人真正负责,或者说被分散到了每个验证工程师手里。他们觉得资深验证工程师自然就能干这个活,或者项目leader应该顺带把架构设计了。结果就是,这项工作要么被忽略,要么被分摊到每个人头上,变成了”谁遇到问题谁就临时搭一套”的状态。方法学不等于架构能力。
2026-01-15 20:54:42
283
原创 有人建议断言要占RTL的30%
有公司推荐”断言数量要达到RTL代码30%“，但真要落地，问题一堆。。它能在仿真阶段抓住那些隐蔽的bug，比testbench发现问题要早得多。一个写得好的assertion,能在错误发生的第一时间定位问题,而不是等到波形里翻来覆去找半天。但30%这个数字是怎么来的？说实话,。不同模块的复杂度天差地别,一刀切的比例根本不合理。。RTL代码改了,对应的断言也得跟着改。项目紧张的时候,工程师优先保证功能正确,断言经常就被抛在脑后。结果就是一堆过期的断言触发误报,最后干脆被注释掉。还有就是。
2026-01-15 08:22:13
387
原创 后仿真中的几个注意事项
很多人会问，前仿真不是已经验证过功能了吗？为什么还要再来一遍？前仿真验证的是RTL代码的逻辑正确性，但到了后端完成布局布线后，电路中会产生大量的——线路延迟、负载电容、互连电阻，这些都会影响信号的时序特性。一个在前仿真中完美运行的设计，到了后仿真可能就会出现或，甚至还有毛刺，导致芯片无法正常工作。
2026-01-14 21:11:34
357
原创 UVM太重了，小项目不需要？
SystemVerilog给了我们极大的灵活性，但灵活的代价就是混乱。张三用class写了一套，李四用task搞了另一套，王五直接module堆起来。表面上看都能跑通仿真，但一到code review或者debug，就开始扯皮了。
2026-01-14 07:53:02
28
原创 断言：让芯片设计工程师又爱又恨
一旦发出请求信号req，必须在1到2个时钟周期内收到应答ack。如果实际仿真时没收到应答，或者应答来得太晚，断言就会报错。为什么说它给设计带来麻烦？道理很简单。设计在自己的代码里埋断言，就等于给自己挖了坑。
2026-01-13 18:34:36
308
原创 芯片验证工程师的写代码能力不是第一位
很多人以为验证工程师就是搭环境、跑仿真。但这只是表面工作。。举个实际的例子：某个FIFO模块在正常读写测试下运行完美，覆盖率也达到了100%。但有个验证工程师在review代码时问了一句：“如果同步器信号在FIFO满状态下晚出去一拍会怎样?结果一测，指针直接错乱。这个Bug在功能仿真里根本不会暴露，因为大家默认信号是确定和干净的。。
2026-01-13 08:06:00
409
原创 边界值测试：一个”==”引发的芯片bug
成立，允许继续写入。但写入后data_count递增到256，8位寄存器溢出归零，FIFO满标志永远无法拉高。看一个真实场景：某款芯片的FIFO控制器在流片后被发现，当深度配置为256时会丢数据。溢出、极值、临界状态，这些在验证和实验室测试时被漏掉的场景，到了量产后就是灾难。当FIFO写入第255个数据后，data_count变成255，判断。
2026-01-12 21:14:58
403
原创 仿真器出bug了？分频时钟竞争的诡异仿真现象
带有分频时钟的仿真有时候看起来完全pass的，但采样的数据却是错的。这种bug比X态更阴险，因为它会让你误以为设计没问题，结果上板或流片后功能全乱套。场景是这样的：clkb是clka的4分频，用clkb去采样clka域的多bit数据。按理说clkb上升沿到来时，data应该已经在clka域稳定了，采样到的应该是”旧值”。但仿真结果是：每次都采样到”新值”。整个数据流都错位了，功能完全不对。核心原因是仿真器的事件调度机制。在一个时刻，有两个事件同时发生：仿真器必须选择一个顺序来执行这两个事件。由于Verilo
2026-01-12 07:51:36
346
原创 别让Makefile成为你的舒适陷阱
底层自动调用VCS或者Verdi，编译选项、时间精度、覆盖率开关全都配好了。新人上手快，团队协作也方便，大家用同一套环境，仿真结果不会因为配置差异出现偏差。最近观察到一个现象：很多做数字芯片的工程师，在公司干了三五年，仿真跑得飞起，但你让他离开公司的Makefile脚本，自己搭一个仿真环境，竟然不知道从哪下手。公司提供的编译脚本确实好用。
2026-01-11 07:46:42
357
原创 验证工程师越来越缺的另一点原因
验证工程师拿到这些IP,得先搞清楚每个模块到底干嘛用的,接口定义对不对,内部逻辑有没有坑。等于说别人设计的东西,验证团队要重新理解一遍,还得承担发现问题的责任。长此以往,验证团队会被低效工作拖垮,真正有价值的深度验证反而做不了。所以现在的局面就是:设计人员越来越依赖验证,IP集成越来越复杂,验证工程师的活越来越多。按理说,设计工程师写完代码应该自己先跑跑仿真,把明显的bug修掉,然后再交给验证团队做系统性检查。,有的是大厂出品质量过硬,有的是小公司凑合能用,还有的干脆就是开源社区捡来的,文档都不全。
2026-01-10 07:32:07
376
原创 真正能做出原创性突破的人才依然稀缺。问题出在哪儿?
真正的创新需要试错的空间。真正的创新往往是反常识的、不确定的、甚至一开始看起来有点”荒谬”的。但我们的文化里,更推崇的是稳妥、可控、有保证的东西。给一个明确的目标,比如”做一颗对标某某芯片的产品”,大家干得热火朝天。但要说从0到1的架构创新、算法突破,能拿得出手的寥寥无几。一个好的架构创新,往往来自对问题本质的洞察,而不是简单的技术堆砌。但现在的培养模式是什么样的?而培养真正的创新型人才,需要的不仅是资金投入,更是对创新规律的尊重和对人才成长的耐心。:容忍失败的文化、长周期的评价机制、鼓励冒险的激励体系。
2026-01-09 07:31:44
376
原创 在日常里也要制造积极情绪
因为芯片项目周期长,压力大,如果每天都绷着脸干活,人早晚得崩溃。但如果能在日常工作中保持一点积极情绪,把小进展、小发现随手分享出来,整个团队的状态就完全不一样。另一种技术可能差不多,但特别爱交流,碰到点小进展就要跟旁边的人分享一下。这时候,如果旁边有个同事正好解决了自己的问题,兴冲冲地过来说”诶你看我这个优化,省了200个寄存器”,这种积极情绪是会传染的。这种协作效率,比各自埋头研究高太多了。下次当你调通一个模块时,别憋着,告诉你的同事。不需要刻意,就是把工作中的小确幸随时说出来,让整个团队都能感受到。
2026-01-08 07:38:22
296
原创 那个永远积极的人升职了
办公室走廊尽头的茶水间,每天下午都会上演同一出戏:抱怨版图又要重画、感慨这个项目必死无疑。很多人好像天生就要端着一副”看透一切”的架势。聊起项目永远是”时间不够”、“资源不足”、“技术方案有问题”。——因为觉得做不成,所以真的做不成。代码能跑就行、验证差不多得了、文档随便写写应付一下。反正大家都觉得这项目早晚黄,谁还认真干?有个同事,刚来的时候被所有人嘲笑。每次开会他都最积极,别人说不行他偏要试试,失败了也不气馁接着改方案。他升manager那天,有人问他怎么做到的。
2026-01-07 07:30:51
212
原创 绝大部分时候工程师的大脑都在自动驾驶模式下运转
打开EDA工具,看到综合报告里熟悉的warning,大脑会自动调出过往经验:“这个可以忽略”、“那个改个约束就行”。整个过程快得像条件反射,。验证工程师看波形图也一样。一个assertion fail弹出来,凭经验就能猜到八成是哪个模块的问题。这种快速判断模式效率极高,解决了日常90%的问题。但代价也很明显——。
2026-01-06 08:57:35
250
原创 为什么大家明知道累死累活没有意义,还要抢着加班?
如果所有人都能准点下班,大家的效率反而更高,生活质量也更好。但只要有一个人开始卷,所有人就都得跟着卷,否则就是”不思进取”。但没人在乎这个,大家只看到”他又通宵了,真拼”。不是因为工作真的需要这么多时间,而是因为别人都在加班,你不加就显得不够拼,不够有”狼性”。那些卷出来的所谓”竞争优势”,往往只是暂时的。当所有公司都996,都通宵达旦,最后比的还是技术实力和资源积累。单个人做不到,因为职场是现实的,不卷就会被淘汰。熬夜改完bug的那一刻,确实有种”我很重要”的错觉。流片前的那几个月,基本告别正常作息。
2026-01-03 09:20:29
270
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人