工作总结
2026-04-12 工作总结 通信芯片系统工程师通信芯片系统工程师工作总结(通用版)。
这一年下来，手上三个项目——两颗Wi-Fi 6芯片、一颗Wi-Fi 7+蓝牙双模原型——都过了量产门禁。指标摆这儿：流片后不需要改版的一次成功率，按项目算2/3，按晶圆批次算99.2%（这个分母是12个工程批，每个批抽测500颗）。客户现场工单，全年接到43单，关了41单，剩下两单一个是客户自己的电源纹波超标，另一个是第三方协议栈的bug，不属于芯片问题。客户满意度评分，平均4.6（满分5），样本来自六个ODM客户的对接窗口。
我不爱列虚数。说实在的，做系统工程师，每天坐实验室面对频谱仪和逻辑分析仪，数据好不好自己心里清楚。今年最大的长进，是学会了在协议栈和射频之间来回跳着看问题，不再死守某一层。
一个让我重新审视“共存”二字的问题
第二季度，一款Wi-Fi 6芯片在客户某游戏本上出了怪事：蓝牙鼠标和Wi-Fi同时用，Wi-Fi下行吞吐量直接从600Mbps掉到80Mbps。内部PTA（包流量仲裁）我们测过，信号没问题。客户怀疑是天线隔离度不够，要求改硬件。
我没急着推硬件改版。先把实验环境搬到自己桌上：同样的笔记本、同样的鼠标型号、同样的路由器。用频谱仪看2.4GHz频段，发现蓝牙每次传数据时，Wi-Fi的信道空闲评估（CCA）被频繁置为忙状态。问题不在PTA的优先级，而在于Wi-Fi的NAV（网络分配向量）更新机制——蓝牙的同步连接（SCO）包周期性地触发Wi-Fi接收端的误解析，导致MAC层误以为信道被占。
怎么定位的？我用了两天时间，抓了Wi-Fi和蓝牙的空中包，用Wireshark和蓝牙分析仪对时间戳。发现每次蓝牙传完SCO包后的200微秒内，Wi-Fi的Beacon帧接收会失败。进一步查芯片内部的log，是基带的状态机在收到蓝牙收发指示后，重置了Wi-Fi的CCA窗口。
解法不在硬件，在固件。我修改了Wi-Fi MAC的状态机：在蓝牙SCO活动期间，不重置CCA累积窗口，而是用一个滑动平均来平滑信道忙闲判断。同时调整了PTA的grant时序，让Wi-Fi的高优先级帧（比如Beacon和ACK）可以打断蓝牙的未开始包。代码改完，跑了两天压力测试——同时打游戏、传文件、连蓝牙耳机——吞吐量稳定在520Mbps以上，抖动小于10%。
客户那边，我没有只给一个补丁。我整理了一份《Wi-Fi与蓝牙SCO共存调优指南》，里面画了时序图、标了关键的寄存器地址、给了三组不同负载下的推荐参数。后续这个文档成了我们内部系统设计评审的必读附件。
说一次链路预算翻车的教训
今年上半年，一颗低功耗Wi-Fi芯片的接收灵敏度始终差3dB。仿真显示能达到-98dBm，实际测出来只有-95dBm。我排查了一周：换板子、换仪器、换温度，都没用。
最后把目光放到LNA的输入匹配上。我们用的是一颗外置的平衡-不平衡转换器（Balun），数据手册给的S参数是在50欧姆环境下测的。但我忽略了一个细节——芯片内部LNA的输入阻抗在低增益模式下会偏离50欧姆。仿真用的是理想匹配，实际板子上没有做额外的匹配网络。
怎么办？改板子来不及，流片已经完成。我翻遍了Balun的供应商资料，发现可以通过调整外围的两个电容值来微调阻抗。花了三天，焊了二十多种电容组合，找到了最优值：把两个并联电容从1.2pF换成1.5pF和0.8pF的串并联组合。灵敏度回到-97.5dBm，离目标差0.5dB，但量产可以接受。
这个事儿之后，我定了一条规矩：以后每个项目，在原理图设计阶段，必须用实测的LNA输入阻抗（不是仿真的）去重新算一遍匹配网络，并且做至少三个工艺角的蒙特卡洛仿真。这条写进了部门的设计规范。
日常怎么管住系统质量
说实话，我以前也爱做漂亮的PPT，后来发现没用。真正管用的是三张表。
第一张表叫“场景-参数映射表”。每个客户投诉的场景，我都会拆解成具体的芯片工作状态：MCS速率、带宽、天线选择、PSM模式、温度、电源电压。今年这张表已经攒了87行，每行对应一个能自动化复现的测试用例。新项目回归测试，先把这87个用例跑通，再谈别的。
第二张表是“链路预算余量账本”。每个模块的增益、噪声系数、线性度，不光记典型值，还要记-40℃、+85℃、低电压（3.0V）、高电压（3.6V）下的余量。今年有一个项目的PA在高温和低压组合下输出功率掉了1.5dB，我就是翻账本提前发现的，改了一版驱动偏置，没带到流片去。
- ▲泡泡演讲稿前沿洞察:
- 通信芯片系统工程师 | 系统工程师工作总结 | 智能驾驶系统工程师工作总结 | 活动总结通用版工作 | 通信芯片系统工程师工作总结 | 通信芯片系统工程师工作总结
第三张表最朴素——“我犯过的错”。今年新加了三条：一是做方案时一定要算时钟抖动对EVM的贡献（之前漏过）；二是评估外部干扰时不能只看频域，要看时域包络（那个USB 3.0的问题就是教训）；三是任何与客户环境有关的bug，先问“他们用的什么路由器、什么驱动版本、什么拓扑”，别上来就怀疑芯片。
带人这件事，我换了种干法
部门来了两个新人，我让他们做的第一件事不是看代码，是把过去两年bug库里最典型的15个问题，每个都用文字写清楚：现象、根因、定位过程、为什么当初没在设计阶段拦住。写不出来就来找我，我带他们重演一遍。这叫“学情分析”——以前教书的时候养成的习惯，放到工程上一样好使。
其中一个新人，三个月后自己定位了一个问题：蓝牙连接耳机时，偶尔会爆音。他翻了那15个案例，发现有一个类似的是因为LPO时钟校准周期太长。他顺着查，果然是我们芯片的LPO校准间隔在某个低功耗模式下被拉长到了2秒，导致频率漂移。这个问题后来用固件改了校准策略解决。他高兴得请我喝奶茶，我说别谢我，谢那15个bug。
最后，还有两件事没做好
一是Wi-Fi 7的多链路操作（MLO）特性，我今年的方案做保守了。当初评估认为MLO的可靠性还不够，只开了非同步模式。结果友商的芯片已经支持同步模式，客户比测时我们落后了一截。明年得把MLO的状态机完整过一遍，不能因为怕风险就砍功能。
二是跨时区的客户支持。欧洲一个客户晚上发邮件，我第二天早上回，一来一去就丢了半天。后来我跟FAE商量，排了个“接力表”——我这边下班前把当天进度和待确认问题写在共享文档里，他们那边上班后直接接着干。效率高了，但说实话，有时候半夜还是会被消息震醒。这行就这样，芯片不等人。
明年，手里还有一颗Wi-Fi 7 + 蓝牙 6.0的芯片要做系统方案。我会把今年的三张表和那15个案例摆在手边，少翻车，多产出。就这些。
- 为了您方便浏览更多的工作总结网内容，请访问工作总结
