入职芯片开发部后，每天摸鱼之外的时间我们要做些什么呢_芯片设计 pn85 pn95

作为一个由经过层层面试和offer筛选，刚刚以优秀的面试结果入职某fabless芯片研发公司的芯片前端工程师，每天摸鱼之外的时间，你需要做些什么呢？

一大早（当然11点前都算一大早）走进位于一线城市黄金地段的公司大门，坐在部门每月花了3000块钱为你租的工位上，打杯咖啡配上刚刚买的一屉小笼包开心的补充好能量。而后起身去打水顺便环顾了下四周，你发现了原来这个研发部门的组成是这样的：

当然了这个部门划分没有什么定式，甚至有些团队放的也有些牵强还有些组和部门没有画上去，主要是比较强迫症，不整整齐齐的摆好就浑身难受。所以大家意会就好，不用太较真哈。

也有可能你加入的芯片团队是新的团队或产品线，那么一般来说呢芯片部门起步至少SOC团队是需要优先组建的（要不买来的IP谁给拼起来？），规模稍大后会扩充IP开发团队（主打一个自研！），后续即便后端部分外包给其他公司也应该会需要BES作为接口人统筹前后端的开发与反馈（或者设计自己兼任，title：全能）。同时吸纳优秀的验证人才依次填补TOP、SOC、SYS和IP的验证空缺，完善芯片的功能、性能、功耗等多方面的质量保证。当然了在这一过程中，建模团队和兄弟部门必然也是在有条不紊的组建之中的。

自然也有可能你看到的部门构成是这样的：

或者是这样的：

甚至是这样的：

也不能完全排除一进门老板就站在你面前，告诉你“从今天开始你就是芯片部老大，团队组建就全靠你了！”，那这个时候吧你赶紧翻回“一大早”那一段把那个部门结构仔仔细细的看一下，再掂量掂量自己，然后抓紧提桶跑路。

好了扯的有点儿远，打水的杯子已经溢出来了再不拿走回头你得赔公司财产损失。端着水杯回到座位，再次环顾四周发现果然你是来的最早的（毕竟第一天上班嘛），周围的老司机们还堵在路上：

过了一会同事们陆陆续续的来到工位，姗姗来迟的主管亲切的找到你，叫你到会议室介绍了下公司和部门的情况以及你的职位和所属团队，可能还会为你分配一位工作导师带你入门，为你答疑解惑。这个时候如果你有问题呢一定要抓紧问，毕竟主管不是天天有时间和你聊天的。

忙碌的social结束后回到电脑前，会发现你被拉进了很多的群组：

“HHH公司一家人” “芯片研发部” “芯片设计组” “技术分享讨论组” “XXX芯片交付组” “XXX芯片设计交付组” “芯片研发部新员工群”...

在各个群中潜伏了一天之后，你发现了很多在工作上的合作伙伴以及若干领导，于是你尝试着去理解了一下每个人在一款芯片项目中担任的角色。

打开通讯录仔细一看，原来部门里大家的title如此五花八门，有芯片架构师、设计（Design）、验证（DV）、集成、流程（Flow）、后端对接（BES）、功耗专家、质量管理、项目经理、工具支持等等等等，最可怕的是除了和你一同来部门的小伙伴，似乎每个人都是你的领导

。

想想之后在工作中大家肯定会越来越熟悉，还是先把通讯录关上吧。过了一会部门秘书找到了你，将云端盒子、笔记本和显示屏送了过来，并且把《新员工的第一天》备忘录发给你，留下一句“有不会的的再找我”后飘然而去。于是你一边装电脑一边艰难的跟前后左右的大佬打招呼，顺便把大家的名字努力的记了几遍。

忙忙碌碌再一抬头工作时间已经所剩无几，不过奇怪的是部门小伙伴们仿佛沉迷工作忘记了时间，或是开会讨论或是嬉笑打趣，竟然没有几个人起身下班。正不解时，部门秘书的消息闪烁：“8点半后下班有夜宵补助，10点后下班有打车补助，下班记得打卡呀。忘打卡是要补卡的，每个月有次数限制呦！”

思索了一下，刚回了句“收到”部门老大就走了过来对一众新入职的小伙伴说“没什么事赶快下班吧，咱们可不是996的部门

”。于是你果断骑上共享单车直奔公交站，坐上公交直达地铁站坐上地铁扬长而去，哪怕再再苦再累今天也要为公司剩下这一笔打车费！

转天，工作导师凑过来和你讲“中午咱一起吃个饭，欢迎你加入部门，正好我这还有新员工培训的活动资金呢”。于是中午和导师一起在公司边上的馆子好好地吃上一顿，顺便听导师又天南海北又纪要秘闻的给你讲了讲部门的历史和大事记，听得你边竖拇指边感慨“这部门还真是厉害！”

接下来的一段时间，你每天折腾电脑安装软件注册账号，登录了工作站熟悉了git/svn版本管理工具，也终于习惯了和同事一起10点上班8点下班（确实不是996

）。一个星期后，导师仿佛突然记起来这里还有一位新同学等着他带。于是一边念叨着“怎么我不找他他也不找我呢”一边到了你的工位：

“咱们的项目节奏比较紧，原本还安排了一些培训和虚拟项目的，不如咱们就直接进项目参与开发吧，这样成长更快！”

不等你答应导师把你拉进了“XYZ项目交付组”，突然间你听到了一声熟悉的——

“welcome to join the conference！”

一声未来几年内会让你魂牵梦绕的女声带你进入了XYZ项目会议中。

今天的会议是需求对齐会，主要是项目的芯片架构师在与产品线的产品经理以及算法、软件等需求侧进行需求敲定后，向大家解释和说明芯片的feature和规格，也就是PRD文档（Product Requirements Document）。

PRD文档是用于详细描述产品或项目所需功能、特性、性能以及其他相关需求的文档。在软硬件开发、产品设计等领域，PRD通常被用来确保开发团队、设计团队以及其他相关方在同一个页面上，从而在开发过程中避免混淆和误解。

在PRD文档上，罗列了芯片整体的很多信息，比方说：

你一边听着架构师针对每一项需求进行详细的说明偶尔会有小伙伴打断提出各式各样的疑问，一边思考着这个需求和自己有没有关系。一场2个小时的会议下来你惊喜的发现，好像都和你没啥太大关系呢。比如说芯片采用最新的chiplet封装，这似乎也不影响你的编码开发。事实也是如此，一份芯片的PRD距离具体落实到某个系统某个模块某个人还是有一定的距离的。于是今天的工作随着需求对齐会的结束也基本落下帷幕，回去的路上你已经隐隐的为能够参与世界第一款聚焦“XX”场景“YY”需求的高性能“ZZ”芯片而感到无比自豪了。

回到家里，工作群发来一条群通知，明天9点半项目组全员开工会。于是第二天早上你没敢迟到，早早地来到会议室占据了角落的位置，片刻后XYZ项目组的开发人员陆陆续续走进会议室，其他城市的小伙伴也线上接入。项目经理，当然了，也有可能是某系统交付负责人（反正你也分不清，都是领导就对了）看着人到的差不多了，于是说了声“人差不多齐了，咱们开始吧！”

开工会的内容主要是项目系统规划和时间安排，当然会一开始还是强调了一下大家在参与的是一份多么伟大的事业，如果成功了明年公司市值能上千亿，老板分分钟换辆玛莎拉蒂（虽然双押但是这句没说出来）。之后就是对整个芯片交付团队的交付组进行了划分，分了控制通路交付组、计算通路交付组、访存通路交付组、SOC集成交付组，然后分别任命了各组的交付组长以及设计验证组长。好家伙你一看12个人的交付组，3个组长还有1个方案接口人1个后端接口人，就剩下了4个设计3个验证来干活，瞬间感到压力巨大斗志满满。

会议的剩余时间，项目交付leader把排好的交付节点打在了屏幕上，“芯片明年5月流片，需要给顶层和后端留出充足的时间，所以明年1月咱们向SOC交付，今年11月底各交付组可以陆续锁代码。各交付组内部的时间节点自己来确定，打出提前量，先紧后松不要留到后面delay再加班啊！”好家伙你一听，按照这个提前量按理说今天你就应该把模块RTL代码开发完了

。事情分派完，开工会也随之结束，大家说说笑笑的离开会议室，直奔食堂而去。不过吃了两周食堂你已经吃腻了，就约了几个同为底层苦力的小伙伴去了旁边的一家快餐店，吃饭什么的不重要一吐为快才是刚需。

中午好好地休息了一下，下午起来发现群里多了一个confluence链接“XYZ项目·访存通路系统·功能点提取与模块划分”，点进去之后发现是交付组长根据芯片PRD拆分出的系统功能点和系统模块划分。其中的一个模块后面@了你的名字和一位验证小伙伴，因此你将会作为这个模块的前端设计进行RTL开发，并且和验证小伙伴一起完成模块交付。

突然交付组长又在群里@了所有人：“1.请大家根据系统的交付安排和模块分工，排一份自己的进度计划表，计划排期越详细越具体越好；2.从今天开始，每周需要发送项目周报，每天需要更新项目日报。收到请回复。”

于是你赶紧打开了svn的工程文档路径的project/plan目录的daily_plan_demo.xlsx认认真真的看了起来。

看完个人计划示例文档后瞬间感觉一头雾水，“TR3”“PN85”“PN95”这都是个啥？这上学时候也没学过这个呀，老师倒是教过PN结异质结二极管啥的，不过看起来跟这个计划表也不搭边。

这个时候就需要求助下工作导师了，导师一看就是老谋深算深谙此道深受其害，对着你就侃侃而谈：

"Technical Review"（技术审查）是项目管理中常用的一种方法，用于评估项目中的技术方案、设计、开发等方面的进展和质量。一般来说，技术审查通常包括以下几个常见的节点：

TR1：需求分析与产品等级规格评审，也包括初始设计评审，主要关注项目的初步设计方案，确保设计方向符合项目目标和需求；

TR2：总体架构与设计框架的技术评审，同时也会关注项目的详细设计，验证设计是否满足需求、是否可实施；

TR3：详细设计评审，包括各部分的方案文档、架构文档、互连接口、软硬件交付文档等各类交付文档评审，并评估设计的可靠性和可维护性；

TR4：开发进展的审查，确保开发过程能够满足整体交付节奏，代码质量遵循规范，满足性能要求；

TR5：集成和测试审查，评估项目的集成进展和测试策略，验证不同系统之间的协同工作和整体性能；

TR6：系统验收审查，用于评估整个项目是否满足最终用户需求和预期目标；

“当然了，这些节点的名称和具体流程可能因组织、项目类型、项目管理方法等而有所不同。在某些情况下，一些节点可能会合并或细分，以适应具体项目的需求。”你一看导师这是奔着项目经理发展的啊，眼神逐渐崇拜。再总结了一下似乎只有TR3阶段~TR5阶段是和你紧密相关，怪不得个人计划表中是从TR3的准备阶段开始的。那后面的的PN85、PN95和PN100又是干嘛的呢？

这就是沿用某大厂的芯片项目交付节点管理了：

在TR3节点完成主要的方案和架构文档（由架构师输出）评审后，设计要根据方案架构文档完成模块的设计文档，并根据设计文档进行RTL编码；验证同样根据方案架构文档输出验证方案文档和测试点文档，并进行验证环境搭建；后续可以通过PN85/95/100节点进行项目开发验收；

PN85节点验收标准：

设计——代码开发完成整体的85%，主体功能基本开发完成，能够支撑验证sanity测试与顶层的代码集成；

验证——测试点评审通过，验证环境组件与主体搭建完成，完成sanity通包；

PN95节点验收标准：

设计——代码开发完成整体的95%，主体功能全部完成，主要异常场景和例外场景开发完成，剩余极少数corner场景如动态复位、带流改配、中断恢复未开发；

验证——环境开发完成，主功能与主要异常场景验证充分，随机用例与定向用例配置合理，每日回归稳定进行，plan coverage达到90%以上；

PN100节点验收标准：

设计——代码全部开发完成，时序优化基本完成，面积、功耗与布局绕线等通过验收（可能留有一定的优化空间），代码覆盖率达到95%以上；

验证——全部用例规划完成，定向测试、动态测试、性能测试等基本完成，plan coverage达到100%，function coverage达到95%以上；

高材生不解：“那是不是说PN100之后项目就交完成了？可是为什么个人项目计划表里PN100节点之后还有这么多代办项呢？”（单纯清澈又无辜）

“PN100不是终点，而是新的起点！PN100之后是质量活动的时间，质量活动之后才是项目间歇期，间歇期的时候你就轻松了！”

“那质量活动会持续多久呢？”

“大约持续下一个项目开始吧！”

“嗯？？？”

​​​

一声叹息之后，你默默的汇总了一下手头有的资料，看看该如何规划下个人计划。目前能够查阅到的文档只有：

《XYZ芯片PRD》

《XYZ芯片·访存通路系统·功能点提取与模块划分》

以及架构师刚刚上传的：《XYZ_MAS_FS》，访存通路系统（Memory Access System）FS文档。这名字就很让人困惑，这个FS什么意思呢？他写FS了那你要写什么S呢？

于是你打开了公司的文档体系说明，查阅到了芯片开发spec的三级文档体系：

FS - Functional Specification（功能规格）："FS" 表示功能规格，它是芯片设计和开发的早期阶段的一个文档。功能规格详细描述了芯片的功能、性能和特性，以及各个模块之间的交互。该文档通常由系统工程师编写，用于明确芯片需要实现的功能，为后续的设计和开发工作提供指导。功能规格可以作为开发过程中的基础，帮助确保设计和开发团队在同一页面上。

AS - Architecture Specification（架构规格）："AS" 表示架构规格，它是在功能规格之后，芯片设计进一步细化的一个文档。架构规格描述了芯片的整体架构、模块划分、接口定义等。在架构规格中，可能会包括每个模块的功能描述、接口定义、数据通路等详细信息。架构规格通常由架构师或设计团队编写，为设计和开发提供了更具体的指导。

DS - Design Specification（设计规格）："DS" 表示设计规格，它是在架构规格之后，进一步细化和准备进入实际设计和开发的文档。设计规格包含了硬件模块的详细设计信息，包括电路图、时序要求、数据通路、控制逻辑等。设计规格可以由硬件工程师或设计团队编写，为实际的电路设计和开发提供指导。

看完这很懵啊，这该怎么确定一个功能点一个设计方案应该写在FS上还是AS上还是DS上呢？带着疑问你又去烦了一下导师（反正带你是他的职责嘛），导师分四次一句话总结了下：

“对外交付的，项目经理、客户和产品线伙伴需要了解的信息就写在FS上，咱这FS一般由架构师来完成。”

“内部交付的，架构师、设计、验证和交付伙伴需要了解的信息就写在AS上，咱这AS也是由架构师完成，当然也可以由设计完成。”

“不交付的，设计自己看帮助自己梳理代码，以及对代码进行解释的信息就写在DS上，这个文档必然是设计来完成。”

“所以，接下来你的任务就是，把FS融会贯通之后完成AS和DS文档，当然了，文档写完之后是会进行评审的，加油嗷！”

明确了大方向之后事情就顺利多了，于是你参考着其他人已经上传的计划排出了自己的项目计划表。

看了看自己排的计划，不由得感到非常的满意，于是信心满满的把文档上传了svn文档目录，一抬头发现又要到下班的时间了，刚要起身去吃饭群里突然@大家：“明日上午10点交付组周会，请大家按时更新日报与个人计划表，收到请回复”。

啥啥啥，还要更新日报？于是抓紧在群里回了个“复”，就打开了交付组的confluence主页 - daily_report界面，在上面创建了第一个天的个人日报：

更新完成后，就可以静待第一次交付组组会到来了。

第一次交付组组会到来了！

交付组组会顾名思义就是交付组的各位小伙伴坐在一起，在交付组长主持的流程下，大家总结下上周的工作，说明下下周的安排，评审下进度与个人计划表是否匹配，顺便再说一说是否遇到问题或是被其他事情阻塞了进度。

你一看，这不是跟读研时候的项目组周会一样吗，那还不是轻车熟路。于是作为交付组的新人，你只需要安安静静的在椅子上听大家过进度就好了。这一听不打紧，你是眼睁睁的看着某领导把另一位小伙伴的计划3天改成2天，2天合成1天，5个月的计划硬生生的压成了3个半月。然后该线程又repeat(9)了一下，令人瞠目呀。

这你定睛一看“我屮艸芔茻，真·多人·时间消失术啊”，这比实验室压榨的可狠多了。好巧不巧的，下一个轮到的就是你。于是会议室里不可避免的上演了一出“时间保卫战”。虽然你拿出了浑身解数“这块学习时间不能省啊”“这个模块这么复杂4天哪够”“质量活动咋能合并同类项呢”并且反复强调了自己的菜鸡属性，但是在领导的不拖交付后腿、打出提前量、你的实力有目共睹、相信你一定可以克服苦难、先紧后松后面就简单了、早做完早拿项目奖早进入间歇期等一轮大饼攻势下，最终你还是败下阵来，无奈的说了一句：“行，那我下去把计划按照今天说的改一改吧…”

之后组长又过了一下上周的遗留事项，汇总了下每个人研发进度，将比较慢的几位小伙伴进度状态表为delay，正事的环节基本就完成了。

组会的最后一部分是令人惊喜的表扬环节，可以由大家主动对组内其他小伙伴进行提名表扬，然后大家一致同意选出两位小伙伴为本周的优秀童鞋并由组长自费购买小礼物送给他们，虽然这周的小礼物呢只是是两瓶酸奶不过精神鼓励大于物质鼓励嘛。于是你蹭的窜了起来：“我要表扬一下我导师，这一周要是没有他给我答疑解惑估计我不一定能挺到组会开始╮(╯﹏╰）╭”。

导师听后连忙推辞了，笑着回了一句日后让你非常有感触的话：“无论是你的导师还是领导，他们存在的最大价值就是帮你解决问题。项目上他们不一定会干很多活，但是关键时刻一定得顶得住。”

最后本周表扬花落了两位一起新入职的小伙伴，你也暗暗思量着是不是也要加加油不要一上来就落到人后了呢？组会结束之后组长将记录在confluence上的18条遗留问题同步在群里，并且群发了周报邮件抄送了交付组长、项目经理、质量经理等若干领导。

夕阳西下，开会人在天涯。组会结束后感觉整个人被掏空，索性把所有的事情都推到明天，虽然刚刚是想着加油但是也得吃饱喝足睡够了才能加油是不是？

接下来的日子就是平淡但是充满斗志的项目开发阶段，来一杯冰美式，喝美式想美事做美式青年的生活到来了！

对于一个成熟的芯片设计而言，项目开发的第一阶段自然是熟悉方案与FS文档。不得不承认FS文档写的非常全面和完备，看得出架构师的经验丰富，水平确实高。但是有很多的地方你不是很理解，甚至有些方案点认为是前后矛盾的，这应该怎么办呢？

遇事不决问导师，导师啥都懂：“FS有不明白或者觉得有问题的地方，你就提jira单给架构师，啥？jira单你不懂啥意思？”

Jira 是一种广泛使用的项目和任务跟踪管理工具，由Atlassian公司开发和维护。它主要用于帮助团队和组织进行项目管理、故障追踪、任务分配、团队协作以及问题解决。Jira 可以通过Web界面来进行访问和使用，支持各种平台和设备。

Jira系统的功能很多，包括任务和故障追踪、项目管理、工作流程管理、报告和分析、协作和团队沟通，同时具备可定制性和丰富的插件生态系统。Jira 可以用于不同类型的项目，包括软件开发、IT运维、项目管理、市场营销等。它广泛应用于各种规模的团队和组织，帮助它们更有效地进行任务管理、协作和项目追踪。

“简单来说就是，你对文档有歧义有问题可以提单，觉得内容有缺失有冲突也可以提单。之后在RTL代码开发的过程中，如果其他人对你有任务需求也会提单给你，debug的时候也会提大量的问题单到你这里。当然了，对于FS文档之后架构师还会为大家进行串讲，你可以把问题汇总一下，在进行串讲时当场提出来也是可以的，在反串讲之前把这些内容搞清楚了就可以了。”

“串讲和反串讲又是什么啊？”

“串讲简单理解就是架构师为大家详细说明技术指标、方案架构等细节，并为大家进行答疑。而反串讲就是设计和验证对将方案理解透彻后，反向给架构师和交付组长等说明自己对整体方案和各项特性的理解，避免在信息传递的过程中出现差错。当然了，反串讲一般可以由验证来完成。”

闻言之后虽然似懂非懂，但不影响方案学习。于是接下来的日子，你一边研究方案一边将所有的疑问汇总在一个jira单上提到了架构师那边，直到串讲会上所有的问题都被解决、明确或调整，整体的方案最终敲定。而你个人计划表中方案学习阶段的时间也所剩无几，是时候开始模块AS文档的编写，毕竟再不开始的话验证的小伙伴就要进度就要被阻塞了|ू･ω･` )

幸好你FS学习的很认真，结构和接口也是理解的非常透彻，在领导三番五次的push进度下，仿照其他前辈格式的第一版AS文档终于压线完成了。刚刚想松一口气，验证小伙伴又找到了你：“光有AS不行，你还得出寄存器文档，要不然我这边的测试点分解文档怎么写？”

“为什么有这么多文档啊！要不，你在jira上提个任务单给我？”

费了九牛二虎之力，终于成功的交付了AS文档、寄存器文档、接口文档和自己看的DS文档，一段时间下来感觉身体被掏空。再看计划，是时候组织AS文档的串讲了，于是在会议预定系统上预定了2个小时的评审会和会议室。

到了评审当天一看，咋乌央乌央这么老多人，平时也没几个人关心文档进度啊咋一评审都来了呢，这是借着开会跑这来摸鱼来了吧？不过人都来了也不能往外轰不是，只好在会议纪要上都记上了：

在把线上接入也打开后，按照预定时间开始评审。开始评审这才发现，大家伙不是来摸鱼的，是来玩大家来找茬的啊，每评审一段都是举步维艰：

“模块的输入和输出接口是不是不全啊，跟YYU模块怎么互连呀？”

“模块有哪些性能指标和性能场景呀，文档里需要列出来啊。”

“模块采用了哪些特殊的电路设计？有multicycle么，有designware么，需要着重说明一下。”

“模块的corner case列的太少了吧，是不是还有其他的异常场景需要处理？总线上出现问题了是什么处理流程呀？”

“模块在芯片中的位置和布局是怎样的有考虑过吗，数据流的流向和ram的预期如果有精力也在文档中说明下，有助于后端开展工作。”

“模块sram需求是不是太大了，这么多块ram之后你绕线会是个问题。”

“关键控制通路的校验方案需要更加详细。”

“你这模块的主要功能是什么？”

我屮艸芔茻你连功能是啥还要问，那来开啥评审会啊！

你是一边评审一边心里翻白眼加吐白沫，但是没办法人在会议室不得不低头只好一条一条的记遗留问题，记到了第34条的时候终于把文档评审完了，这会议室的空气肉眼可见的浑浊整个人似乎要喘不上气一般。同事们三三两两说说笑笑的走出会议室，聊起了午饭聊起了晚上的健身聊起了回家带娃。

不管过程如何曲折，终于还是将前期的文档工作推进过去了，于是你开始了艰难又幸福的RTL编码行程。

写代码如盖房子，你仔细思考模块的逻辑结构、性能、功耗和面积，借助设计图与逻辑图完善在文档上。之后一点点的为这座房子选取通用单元和ip，结合承载你逻辑的一个个寄存器、加法器、乘法器、选择器、比较器，一砖一瓦一草一木分合互连，一个崭新的模块拔地而起，日渐丰满完备。而后精心美化内外装潢，优化代码结构时序面积简洁代码编写补充代码注释，终于某年某月某天第一版模块代码交付给验证小伙伴了！

此中艰辛自不必提，而你也突然明白行百里者半九十，代码交付只不过是新征程的起点罢了。这突然的境界提高得益于一天早上打开了jira单网站：

“啥？才一天就提了14个bug单？”

第一版RTL交付之后，就开始了漫长的验证流程，这时你才深刻的理解了什么叫做debug工程师。不得不说相比于debug的时间，编写RTL代码的时间仿佛九牛一毛。不过你惊喜的发现，相较于你的验证搭子每天从白天忙到晚上再忙到半夜，你竟然算是比较清闲的。

验证小伙伴在完成测试点后就开始进行验证环境编写，根据接口文档完成接口组件utils，根据寄存器文档生成寄存器模型ral model，根据功能完成reference model，最后把所有的组件封装形成完整的验证环境。而后就等待你初版RTL的交付了，如果设计这边拖的时间太长的话验证小伙伴可能会先要一般顶层的dummy文件用来完成RTL的环境集成。

RTL集成进环境后，就可以开始冒烟测试（sanity case）了。

冒烟测试是在芯片设计完成后的早期阶段进行的测试，旨在尽早发现设计中的明显错误或问题。冒烟测试的主要目标是确认芯片的基本功能是否能够正确启动并运行，而不需要详尽地验证所有功能和特性。这样可以节省时间和资源，尽早发现设计中的显著问题。

显然作为第一版用于测试的交付代码，一天出那么二三十个bug也不是什么问题嘛(；´д｀)ゞ出问题你就改，改完再出，出完还改，千锤百炼吧！

在漫长的debug阶段，验证小伙伴在sanity pass之后根据测试点补充更多的随机测试用例，也发现了越来越多的bug。你一遍遍的拉分支改代码跑用例合代码，终于熬到了RTL基本稳定下来。小伙伴一看，“终于攒了足够的用例，可以起回归啦！”听到这你大为不解“起回归是什么？”

“回归测试就是将已经通过的用例添加到回归列表中，然后通过归回配置脚本对所有添加的用例进行自动执行配置的次数，简单的理解就是批量跑用例。一次回归可以跑成百上千条用例，将之前完成的测试在短时间内重复运行检查，扩大场景覆盖避免新修改的代码引入未知的bug，也可以集中收集覆盖率真实的反映出验证进度。而且因为回归是工具自动定时运行的，把跑回归的时间设定在每天午夜12点，能够达到人下班机器不下班连轴转的效果，代码收敛速度嘎嘎的提升！”

你一听好家伙人下班机器不下班，连轴转这也太狠了，幸好你只需要好好的配合验证一起改bug就行倒是也不用操心太多。当然只改bug肯定是不够的，bug大幅减少代码基本稳定之后，其他的RTL修改工作自然也要抬高优先级了。

首要的任务自然是清理RTL的lint问题，虽然在编码过程中你已经清理过很多次了，但是由于频繁的代码修改合入导致又出现了很多的问题，尤其是大量的warning也没有得到及时清理。因此你专心了三五天的时间集中清理了模块中所有的lint error和warning，对于实在无法处理的那就只好通过文件请工具“忽视”掉了。

之后是代码优化中的重中之重——时序优化。严格来说，时序优化不应被归入代码优化环节，而应该是bug修改更为准确，因为时序没有达标的RTL是无法进行后续布局布线生成网表以及流片生产加工的。而相较其他，时序优化又是最为考验设计经验与能力的环节，着实令你叫苦不迭。

BES小伙伴帮助大家通过工具完成了模块的预综合，提醒你们根据结果进行时序优化。果然这是谁都逃不掉的一步，怀着侥幸心理你打开了报告期待着最差路径是一个正数，结果映入眼帘的的数字：-1.883！1GHz时钟频率的芯片，满打满算只有800ps时序空间供逻辑来辗转腾挪，然后你这最差路径违规了1883ps！

当时你感到虚汗唰的流了下来，“我是啥神人能写出这么深的逻辑，这怎么修呢？”

不过越是这种关头越要冷静，找时序路径的源头找重点，一点点分析时序可优化点，逻辑前提、增加流水、简化计算，修完一条之后再瞄准下一条周而复始循环往复。

经过数轮的优化和迭代终于整个模块的时序路径全部达标，同时你惊喜的发现时序达标之后，模块的面积也有了很显著的降低。带着这个疑问又找到了许久未露面的导师来解惑：

“确实时序比较好的模块相较于同等规模的模块面积会有降低，因为工具不需要为了路径优化去插入很多不必要的buffer来推时钟推复位推前后级的逻辑，努力满足建立时钟与保持时钟要求。同时你也应该发现了，当把时序最长的几条路径修好之后，其他的违规路径有可能逻辑深度也大幅降低，这是因为工具可以把优化最差路径的精力用来优化其他路径了，那么自然整体就会变好很多。这也就是为什么在进行优化时要抓住最差的来搞，最差的解决了很多时候就带动其他一起解决了。”

听君一席话胜读十年书，这一刻你感觉自己的能力条上限又涨了，但是血条有点空。显然这一段时间的时序优化令你心力交瘁，想着是不是周末该好好休息下了，不过转念一项周末加班双倍工资呀什么休息不休息的，这不是主要为国家芯片事业奉献嘛，毕竟你这孩子从小就有这伟大志向！

接下来的日子显得平静和闲适，习惯了工作节奏的你甚至能够抽出时间去学学算法学学协议，技能点每天都在更新。验证伙伴每日回归，与你一起保卫着模块的功能和性能；后端伙伴串上了数据流带着布局定期综合和布线；而你每天跟验证要来一版回归结果，对着覆盖率结果思考补充，功能空间覆盖的越来越充分。其他时候偶尔系统层的童鞋会找到你帮忙定位问题，有时软件的小伙伴会询问你信号的意义，时不时质量主管也会溜达过来和你聊聊进度。每周的周会也还是很准时，大家聚在一起像聊家常般“辞旧迎新”，你也在邮件中得到了很多次的表扬。精神鼓励虽不像物质鼓励那般货真价实，却也让你有了被认可的快乐。

日复一日流水不息，终于来到了PN100的节点，系统RTL进行交付了！

当然，伴随代码一起交付的还有方案文档、接口文档和寄存器文档以及指令文档。在历经了一轮又一轮质量活动，迎接了一次又一次领导们的“挑刺”，解决了一页又一页的遗留问题后，终！于！交！付！了！

项目间歇期长达一天！！

第二天就是交付组PN100交付总结，显然组长的情绪还是很高的：

“咱们交付组提前一个月完成了系统交付，非常的可喜可贺。大家这段时间都辛苦了尤其几位新同学，刚刚开始工作就马不停蹄的投入到项目中，最后和大家一起按计划完成了目标。”

“当然了这只是阶段性的胜利，接下来的这段时间我们还要巩固质量活动的成果，验证同学还要持续回归查漏补缺，设计同学也要配合一起进行面积分析、性能分析和功耗分析，如果后续反馈有绕线问题大家也需要配合解决。”

“即使这些工作都完成了，我们也还是不能懈怠。我们提前一个月完成了项目交付，这意味着什么呢？意味着什么呢？意味着咱们能提前一个月开始下一个项目，一上来就领先别的组一个月的进度呀！开不开心，幸不幸福！”

当时你就想站起来说一句“别卷了，求求你们别卷了”，这幸福啥大家加班加点也不是为了比别人先开始下一个项目呀。不过这场合这时间再加上你人微言轻的现实，还是乖乖的听组长的话吧。

总结会之后大家的兴致虽然不太高，但是也有种习以为常的淡定感。过了一会，导师来到你工位问你愿不愿意参加上一颗芯片回片后的导入工作：

在芯片制造完成后，将其从制造工厂送回设计单位进行测试和验证的过程，也称为回片阶段的导入工作，导入会跑通和验证芯片各项功能指标，为大规模生产商用提供指导。

在芯片回片阶段，导入工作主要包括以下内容： 

1. 芯片测试和验证设备的准备：在设计单位内准备好用于测试和验证芯片的设备，包括测试台、测试仪器以及相关的接口和软件。

2. 测试程序的开发：设计测试程序和测试算法，以确保能够充分覆盖芯片的所有功能，并检测潜在的缺陷或故障。

3. 测试载板设计：设计用于插入芯片并连接到测试设备的测试载板，确保良好的接触和稳定的信号传输。

4. 功能测试：对芯片进行各种功能测试，以确保它能够按照设计规格正常工作。

5. 故障分析和修复：如果在测试过程中发现芯片存在故障或缺陷，需要进行深入的故障分析，并采取相应措施修复。

“当然也会进行电气测试、温度测试包括性能评估等，可以说导入是走向资深设计工程师的必经之路！”

“那这个累吗？”

“累是累了点，为了点亮芯片可能好几宿睡不好觉，出现一个问题可能需要几个小时去猜去想去实验。整个过程会特别的有成就感！偷偷跟你说，咱们部分的主管领导项目经历都是经历过芯片导入才升上去的。”

“哦那婉拒了啊，下回一定去!!!∑(ﾟДﾟノ)ノ”

仔细想想现在经验尚欠，哪有能力做导入这份重量级的工作呢。婉拒了导师的建议瘫坐在工位上，回想起这一段时间自己作为一个新人参与了部门的芯片项目，又想到马上要到来大家要抢跑的下一个项目，突然感觉到一些迷茫。“难道以后都是周而复始的学方案-写代码-交付-学方案-写代码么？写代码写不到60岁呀，那我一个设计工程师未来方向是什么呢？”

显然这是一个非常现实的问题，当然这并不意味着你不喜欢写代码不想为代码事业奋斗终生，毕竟客观上说年龄危机还是存在的。你自己心里也清楚年轻时自己能加班能钻研可是再大一些呢，心里就没底了。于是这又到了导师登场的时间了，你很好奇导师已经工作了8年了对于年龄危机他是准备如何应对呢？你在聊天框偷偷框震了他一下，尽量不提他年龄的事问出了你的疑惑“设计工程师以后都有哪些发展方向呢？”

“这个问题我也思考过，也和很多同学探讨过，给你说说我的见解。在我看来，设计工程师未来有4个发展的防线：技术专家、架构师、项目经理、市场专家。”

“第一条路线是技术专家，或者称之为资深设计工程师，就像你现在的进阶版。技术专家需要具备深厚的专业知识、卓越的问题解决能力、更多对制程和工艺的了解、时序面积功耗优化能力、扎实的编程和脚本技能以及很高的责任心和自我驱动力。当把一个模块系统甚至整个soc交给你来完成的时候，大家都会非常的相信你的交付速度和代码质量。资深设计工程师可以说是一个团队不可获取的宝贵资源。”

“第二条路线是芯片架构师。架构师负责制定和设计芯片整体架构，这就需要你具备深厚的专业知识，对所在方向有极高的理解；系统级思维，能够划分协调各个模块和IP功能；性能和面积功耗平衡思想，在不同设计指标之间进行权衡；市场和产品意识，能够设计出符合市场定位的芯片产品；风险评估和解决能力，能够识别潜在的技术和设计风险，并提出相应的解决方案。”

“第三条路线是项目经理，或者说交付组长。项目经理显然已经走向管理路线，需要有很强的项目管理能力、团队领导和协作能力、沟通与协调能力、决策能力、风险管理与解决能力、时间管理能力以及应变和抗压能力，当然也需要有技术背景，具备芯片设计和制造领域的技术知识，能够理解和评估技术方案的可行性和优劣势。也需要随时保持对行业动态的关注，不断提升自己的综合素质。”

“第四条路线是市场专家，这条路距离研发就更远一些了。想成为市场专家你需要着重培养自己的市场分析和市场调研能力，能够对芯片市场进行深入分析，包括市场规模、增长趋势、竞争格局等，为产品定位和推广提供数据支持，也要去了解客户需求、竞争对手、市场痛点等信息，为产品开发和营销策略提供依据。当然有时也要花费心思去维护客户市场、进行品牌建设、参与产品定位与定价。你的芯片设计背景会在这个过程中为你提供很大的帮助与优势。”

“路不是绝对的，事在人为走出你自己的路才是最好的！”

确实，你还有着充足的时间充沛的精力以及无限的热爱来选择探索你自己的路，一切才刚刚起步像初升的朝阳，广阔天地大有可为！