我在芯片初创公司这年的「渣男营造法式」

来源:是说芯语发布时间:2023-07-121657浏览

询问 AI

“是说芯语”已陪伴您1638天

前些日子，气候显得不太正常。四月中旬过起了夏天，月底又似乎入了秋。新闻上说，今年厄尔尼诺会卷土重来，我们或许面临近年来最热的夏天。回想起去年夏天限电的场景，我不免又杞人忧天起来。

相比于气候变化、俄乌冲突这种宏大议题，讨论每个人的生活似乎会让我们更有安全感。我们控制不了大环境、大趋势，但可以去营造、去构建自己的小环境。

信息流里的种种叙事，常让我感到世界的荒诞不经和匪夷所思；而自己周遭的事和物，才是我面对真实世界的抓手。这抓手之一，即是工作。

上周，目前的工作刚好满一年。借着五一劳动节“打工最光荣，打工最伟大”的热烈氛围，我也简单梳理一下自己的工作内容和思路。回首过去，是为了更好地渣展望未来。

关于本职工作。

作为前端验证，工作职责是确保芯片的零缺陷交付，进而助力产品的成功。

从项目的角度看，自己深度参与三个项目，目前暂未发现重大功能bug。

从验证层次的角度看，除模块级验证外，自己还参与了系统级验证、DMS/AMS数模混仿验证。由于以前只做过模块级，系统级验证的过程弥补了自己很多知识上的盲区，如核的启动流程、C test和UVM test的相互配合、核的基本调试方法等。在DMS（Digital Mixed-Signal）和AMS（Analog Mixed-Signal）数模混仿验证的过程中，不仅掌握了两者的基本流程、工具及方法，更重要的是知道了DMS和AMS各自的优势和应用场景。此外，自己也接触了RNM（RealNumber Modeling），做了RNM与数字部分的联合仿真。

从验证内容的角度看，除功能RTL的验证，也参与了低功耗验证。自己参与编写了UPF文件，第一次知道UPF和RTL其实是并列的关系，而不是主从关系。参与了带UPF的低功耗仿真，也解决了一些奇奇怪怪的问题。

关于流程。

首先，作为前端验证，验证流程极大影响着项目能否按时交付。自己在项目实践过程中，也逐渐梳理出「数模混合SOC的验证流程」。

流程的重点是层次化、自动化、可重用、易扩展。层次化即把验证工作划分到不同层次，各个验证层次的侧重点不同，使其形成一种整体性的互补策略。自动化即验证工具、环境搭建的自动化，可在前期节约大量人力。可重用即验证组件的可重用，既包括组件在同一项目不同验证层次之间的重用，也包括组件在不同项目中的重用。易扩展即验证环境的扩展性，主要是为今后产品迭代升级做准备，留出扩展的可能性。当然，人是灵活的，我们必须要根据实际情况进行调整。在项目排期紧张的情况下，流程可以适当简化。但毕竟，手里有图，心里不慌，才能做一个情绪稳定的渣男。

数模混合SOC验证流程

其次，问题的记录、跟踪与回顾可以说是研发工程师的第二大脑。作为初创企业，诚然不会用那些大牌的工具，那我们能不能搞个同样灵活、敏捷的工具？经过一段时间的探索，我发现GitLab的Issue功能恰好可以满足大部分需求：问题单创建、问题单在同事之间顺畅流转、不同类型问题可以设置不同的模板，甚至，Git提交还可直接与问题单进行绑定。于是，自己怀着万分激动、无比喜悦的心情，编写并发布了「问题单提单流程与规范」。自此以后，项目的问题单越来越多，同事们提单越来越顺手。而我自己呢，则每天沉浸在各种问题单的海洋中，思考着一个问题：自己给自己挖坑是一种怎样的体验？

问题单可自动与Git提交绑定

再次，作为硅农，一定需要代码版本管理工具来保存我们的劳动成果。否则，很容易出现“辛辛苦苦几十年，一朝回到解放前”的窘境。公司使用Git进行版本管理，由于我之前没有接触过，刚开始使用时总出错。后来，想着干脆自己整理一份「Git流程图示」，既可以使自己加深印象，也可让其他同事去参考，何乐不为？这其中的精髓其实是下半部分（设计与验证的交互）。当时的想法是，代码验证通过后才上主分支，确保主分支的正确性。但无奈的是，由于在日常使用中经常出错，这一流程后来被不断简化和舍弃。不过，既然曾经拥有，又何必在乎天长地久？

Git流程图示

最后，作为前端研发，我们的工作方向完全受产品需求的指引。而产品的需求会进一步细化成为芯片的各项指标和功能规格。不夸张地说，芯片的功能需求规格说明书就是前端设计和验证的bible。因此，这本圣经的质量，就极大影响了我们的工作效率。每当我看到没有条例、毫无章法的规格书，我就想甩给对方一本《金字塔原理》让其好好拜读一下。这样几次过后，索性自己写了一份「Feature Specification 编写原则」，把“为什么要写”、“应该写什么”、“应该怎样写”这三个核心问题按照自己的理解阐述出来。这样，写文档的同事动笔之前都会先翻阅这份文档，想想这三个问题。就像直击灵魂的保安三问一样，每个人都需要花时间去思考：你是谁？你从哪里来？你要到哪里去？

关于工具。

在日常工作过程中，自己会开发一些小巧实用的工具，提升整个团队的工作效率。

首先，是验证环境搭建的自动化。记得当初刚进公司的时候，我满怀期待地问同事：“我们的环境通过什么生成？”，同事怀着一丝诡异的微笑对我说：“你自己生成”。当时我的感觉是：两手空空的自己，来了一个同样两手空空的公司……于是，我不得不想办法去自己生成。本着“不引入外部工具和工作量”的原则，我当时选择了VCS自带的uvmgen。不过，当我看到她那将近4000行的perl母体时，就对自己刚刚提出的原则产生了深深的怀疑。不过，鉴于当时时间比较紧张，我还是暂时接纳了她：花时间改了语法错误，加了几个模板，一款号称「自动化搭建UVM验证环境、自动生成文件列表/Makefile、自动执行用例回归及结果分析等功能」的工具就上线了。不过，正如当初我一瞥她那晦涩艰深的语法面庞后的不适感，她目前仍处于“不好用，但能解决问题”的状态，我也再没花精力对其保养和维护。自此以后，我常听到同事间在流传着的一个故事，主题是“赵琦果然是渣男”。

其次，还有一些小脚本，让我可以见缝插针——不是那个意思，而是大公司不去做的，我们可以自己做。「GUI弹窗」是现在同事使用最频繁的功能：验证发现个bug，设计想在他自己的屏幕上debug，怎么办？弹！模拟写了个接口和参数文件，数字需要参考但又太懒不想去敲路径，怎么办？弹！年纪大了，眼角隐隐出现皱纹，怎么办？还是弹！弹弹弹，弹走鱼尾纹！

另外，飞书灵活的接口也为我们提供了更多可能性。

上面说到，我们的版本管理使用Git，其分支合并请求默认通过邮件发送。但很多同事没有及时查看邮件的习惯，所以常常出现合并过晚，甚至冲突的情况。怎么解？首先我们尝试过把合并链接发在群里，主动提醒对方审核。但时间长了，感觉这也太低效了，而且容易出错，完全不符合「追求先进生产力」的工作理念。于是，我想到了飞书机器人。通过GitLab的Webhook接口，将合并请求发送到云服务端，经过云端报文转发，就可以实现飞书机器人的自动提醒。这里要说明的是，飞书本身有自动化的GitLab连接器，经过傻瓜式的配置就可以实现上述功能。但很无奈，该功能目前不支持自己部署的GitLab。经过和飞书同学的交流确认，最后还是自己写代码去做了报文转发。

Git合并请求确认手动(左) VS 自动机器人(右)

此外，身处一家心态开放、与时俱进的初创公司，我一直在思考企业和人工智能的关系。ChatGPT的出现，让我有机会小试牛刀，也亲眼看到了AI对于工作效率的提升。于是，我仍用飞书机器人作为主体，实现了基于gpt-3.5-turbo的对话机器人。除了把他拉进群里进行“适当地”调戏外，公司每位同事都可以私聊，向他提需求，他则源源不断地为各位同事生产代码、文案或解决方案。每当这时候，我便产生了一种虚幻的错觉：我们的角色进行了反转——自己不再是牛马，而是指挥牛马进行劳动的人。

ChatGPT给我们当牛马

说到这里，我就不得不由衷地赞美一下飞书这款产品。自认为它解决了很多传统办公流程中的痛点，比如说文档的协同编辑，又比如说任务的协作分配。

以上，就是我在芯片初创公司一年的「渣男营造法式」。

读到这里，你可能会好奇：难道做芯片的都这么渣么？芯片行业其他从业者的工作和生活是怎样的？在这里顺便聊聊我最近读到的一本书。

如果你不在芯片行业，但想了解这个行业的发展，对我们每天的工作内容感到好奇，那么可以读读王健老师最近出的新书《了不起的芯片》；如果你已经在做芯片相关的工作，但对于自己的职业发展有困惑和迷茫，也可以读读王健老师这本新书《了不起的芯片》。

我和王健老师相识于网络。虽未曾谋面，但我对「温戈」这个笔名是印象极为深刻的——是知乎芯片领域的大V了。王健老师毕业于西安电子科技大学，曾就职于全球顶级芯片测试公司Teradyne，现为某芯片大厂数字芯片设计经理。成功参与多款高性能CPU、GPU、服务器等超大规模SoC芯片产品的流片。在芯片设计、可测性设计、芯片测试及应用开发等领域具有丰富的实战经验。丰富的从业经历，已经可以让我相信这本书的专业度了。

更有缘的是，邸志雄老师也为这本书写了推荐序。因此，我觉得不好好读一下，实在对不起两位前辈。所以我在五一期间认真拜读了此书。