作為一個由經過層層面試和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的節點，系統RTL進行交付了！ 當然，伴隨代碼一起交付的還有方案文檔、接口文檔和寄存器文檔以及指令文檔。在歷經了一輪又一輪質量活動，迎接了一次又一次領導們的“挑刺”，解決了一頁又一頁的遺留問題后，終！于！交！付！了！ 項目間歇期長達一天！！ 第二天就是交付組PN100交付總結，顯然組長的情緒還是很高的： “咱們交付組提前一個月完成了系統交付，非常的可喜可賀。大家這段時間都辛苦了尤其幾位新同學，剛剛開始工作就馬不停蹄的投入到項目中，最后和大家一起按計劃完成了目標。” “當然了這只是階段性的勝利，接下來的這段時間我們還要鞏固質量活動的成果，驗證同學還要持續回歸查漏補缺，設計同學也要配合一起進行面積分析、性能分析和功耗分析，如果后續反饋有繞線問題大家也需要配合解決。” “即使這些工作都完成了，我們也還是不能懈怠。我們提前一個月完成了項目交付，這意味著什么呢？意味著什么呢？意味著咱們能提前一個月開始下一個項目，一上來就領先別的組一個月的進度呀！開不開心，幸不幸福！”

當時你就想站起來說一句“別卷了，求求你們別卷了”，這幸福啥大家加班加點也不是為了比別人先開始下一個項目呀。不過這場合這時間再加上你人微言輕的現實，還是乖乖的聽組長的話吧。 總結會之后大家的興致雖然不太高，但是也有種習以為常的淡定感。過了一會，導師來到你工位問你愿不愿意參加上一顆芯片回片后的導入工作：

在芯片制造完成后，將其從制造工廠送回設計單位進行測試和驗證的過程，也稱為回片階段的導入工作，導入會跑通和驗證芯片各項功能指標，為大規模生產商用提供指導。

在芯片回片階段，導入工作主要包括以下內容：

芯片測試和驗證設備的準備：在設計單位內準備好用于測試和驗證芯片的設備，包括測試臺、測試儀器以及相關的接口和軟件。

測試程序的開發：設計測試程序和測試算法，以確保能夠充分覆蓋芯片的所有功能，并檢測潛在的缺陷或故障。

測試載板設計：設計用于插入芯片并連接到測試設備的測試載板，確保良好的接觸和穩定的信號傳輸。

功能測試：對芯片進行各種功能測試，以確保它能夠按照設計規格正常工作。

故障分析和修復：如果在測試過程中發現芯片存在故障或缺陷，需要進行深入的故障分析，并采取相應措施修復。

“當然也會進行電氣測試、溫度測試包括性能評估等，可以說導入是走向資深設計工程師的必經之路！” “那這個累嗎？” “累是累了點，為了點亮芯片可能好幾宿睡不好覺，出現一個問題可能需要幾個小時去猜去想去實驗。整個過程會特別的有成就感！偷偷跟你說，咱們部分的主管領導項目經歷都是經歷過芯片導入才升上去的。” “哦那婉拒了啊，下回一定去!!!∑(?Д?ノ)ノ” 仔細想想現在經驗尚欠，哪有能力做導入這份重量級的工作呢。婉拒了導師的建議癱坐在工位上，回想起這一段時間自己作為一個新人參與了部門的芯片項目，又想到馬上要到來大家要搶跑的下一個項目，突然感覺到一些迷茫。

“難道以后都是周而復始的學方案-寫代碼-交付-學方案-寫代碼么？寫代碼寫不到60歲呀，那我一個設計工程師未來方向是什么呢？” “寫代碼寫不到60歲呀，那我一個設計工程師未來方向是什么呢？” 顯然這是一個非常現實的問題，當然這并不意味著你不喜歡寫代碼不想為代碼事業奮斗終生，畢竟客觀上說年齡危機還是存在的。你自己心里也清楚年輕時自己能加班能鉆研可是再大一些呢，心里就沒底了。于是這又到了導師登場的時間了，你很好奇導師已經工作了8年了對于年齡危機他是準備如何應對呢？你在聊天框偷偷框震了他一下，盡量不提他年齡的事問出了你的疑惑“設計工程師以后都有哪些發展方向呢？” “這個問題我也思考過，也和很多同學探討過，給你說說我的見解。在我看來，設計工程師未來有4個發展的防線：技術專家、架構師、項目經理、市場專家。”

“第一條路線是技術專家，或者稱之為資深設計工程師，就像你現在的進階版。技術專家需要具備深厚的專業知識、卓越的問題解決能力、更多對制程和工藝的了解、時序面積功耗優化能力、扎實的編程和腳本技能以及很高的責任心和自我驅動力。當把一個模塊系統甚至整個soc交給你來完成的時候，大家都會非常的相信你的交付速度和代碼質量。資深設計工程師可以說是一個團隊不可獲取的寶貴資源。” “第二條路線是芯片架構師。架構師負責制定和設計芯片整體架構，這就需要你具備深厚的專業知識，對所在方向有極高的理解；系統級思維，能夠劃分協調各個模塊和IP功能；性能和面積功耗平衡思想，在不同設計指標之間進行權衡；市場和產品意識，能夠設計出符合市場定位的芯片產品；風險評估和解決能力，能夠識別潛在的技術和設計風險，并提出相應的解決方案。”

“第三條路線是項目經理，或者說交付組長。項目經理顯然已經走向管理路線，需要有很強的項目管理能力、團隊領導和協作能力、溝通與協調能力、決策能力、風險管理與解決能力、時間管理能力以及應變和抗壓能力，當然也需要有技術背景，具備芯片設計和制造領域的技術知識，能夠理解和評估技術方案的可行性和優劣勢。也需要隨時保持對行業動態的關注，不斷提升自己的綜合素質。” “第四條路線是市場專家，這條路距離研發就更遠一些了。

想成為市場專家你需要著重培養自己的市場分析和市場調研能力，能夠對芯片市場進行深入分析，包括市場規模、增長趨勢、競爭格局等，為產品定位和推廣提供數據支持，也要去了解客戶需求、競爭對手、市場痛點等信息，為產品開發和營銷策略提供依據。當然有時也要花費心思去維護客戶市場、進行品牌建設、參與產品定位與定價。你的芯片設計背景會在這個過程中為你提供很大的幫助與優勢。” “路不是絕對的，事在人為走出你自己的路才是最好的！” 確實，你還有著充足的時間充沛的精力以及無限的熱愛來選擇探索你自己的路，一切才剛剛起步像初升的朝陽，廣闊天地大有可為！

編輯：黃飛