晶元項目中，如果流片失敗或有重大 bug，能不能只問責於驗證人員工作的不充分？

01-16

當然不會。每次tapeout完都會有一個會議，所有人都要做檢討，從RTL團隊，到FW團隊，到驗證團隊，到後端。都要做報告，大意就是我是個傻逼，I know nothing，我有罪，我要怎樣做到更好，flow上哪裡出了問題，coding違反了什麼原則。開這個會不是為了整人，而是為了搞清楚哪些錯誤其實是方法流程上可以避免的。純粹的design錯誤反而不會特意深究，一般這種會都很熱鬧，因為平時很難有機會看到各種牛人/同事/老大做檢討。

當然，RTL designer始終是要被追問的，bug原因要搞得一清二楚，不可能只怪驗證團隊。還有，不存在問責。就算有天大的bug，也不會有人責備你，如果有，那說明該換公司了。

————————分割線——————————

很明顯很多人不清楚IC公司的流片過程。

每次tapeout之前都會有幾次試流片，只做少量樣品，樣品測過了才會大規模量產，但是樣品通常都有bug，如果FW能夠patch就最好，不能patch就會修ECO，再做下一版，如果ECO搞不定，就重新RTL再來一遍。沒有任何一個半導體公司tapeout之前敢說這就是最後一版，這一版肯定沒有問題，即便intel也有delay的時候。所以只要敢量產，就不可能有天大的bug，有也不是designer的錯誤，因為之前的大量測試已經保證了基本功能必然work，只可能在某些corner case下有問題。

就算不小心還是出了錯，晶元廢了，公司能怎麼辦？開了RTL designer嗎，降工資嗎？不可能。RTL Designer在IC公司地位都很高，你開了他，降他工資，員工分分鐘找下一家，但是他負責的module沒人管就是大事了，新員工需要幾個月才能完全接手，能改代碼還需要更久。一般RTL Designer都不會在項目一半的時候離職，因為對項目打擊太大。

出bug對IC公司是常有的事，IC本就是高風險行業，流片失敗也是常見，連這都處理不了，還要追究員工個人責任，誰還敢負責coding？這種公司只能說是傻逼。

一個原NV的同事提到台積電的時候咬牙切齒。問其原因，他說台積電因為很奇葩的原因讓他們tapeout失敗過一次。

某年，NV要搞一個新的晶元，讓台積電tapeout和生產。正好遇上台積電要工藝升級之類，那條流水線要暫停4個月。NV就說行啊，在暫停之前還有一個多月，把這個基本好了的先tapeout一下，至少這段時間我們能先看看性能什麼的。等2個月後，NV晶元設計的老闆告訴員工tapeout失敗，they dropped it。

大家開始問，為啥好好要放棄呢，我們設計不好就說嘛，放棄什麼放棄。老闆說，不是放棄，是drop。

其實，已經有樣品做好了，按照流程，應該放手推車上推到倉庫。當時生產線離倉庫10米，手推車放在20米外。工人就說，沒事我拿過去就行，就那麼兩步路。

嗯，就那麼兩步路，他摔倒了，"they dropped it"。。。

就這樣tapeout失敗。

匿名講個真事。

有次流片回來測試，某個引腳有問題，一上電就漏電，幾分鐘之內就是一縷青煙，板子帶晶元一起燒了。追查發現，該io的esd diode畫版圖的時候居然少畫一層layer，產生了錯誤的器件。（io和esd的版圖和design rule是特別難搞的事，做過的都知道）

調查結果大約是這樣，模擬工程師要求版圖工程師畫成某樣，版圖工程師發現去掉那層layer之後drc檢查就過了，然後跑去問負責design rule的CAD，這樣可以嗎？CAD說，可以。於是就憑這句轉述，一路review都通過。晶元回來大家傻眼。

事後扯皮，該CAD不承認說過可以。老闆問，空口無憑，有郵件證明CAD同意了嗎？沒有。於是黑鍋就要模擬和版圖工程師背。

處理結果是：

模擬設計經理：降級為工程師，過幾個月公司裁員被開

模擬工程師：過幾個月同一撥被開

版圖工程師：無責，但之後轉崗了

CAD：無責

不可以。SoC設計流程這麼複雜，bug源頭可能出在RTL, DFT,驗證，甚至SI分析，模擬電路等等。最悲催的是良率不穩又找不到root cause, 這才是最折磨人的。

流片失敗看是什麼的原因，正規/大公司還是會做一定問責的。

我職業生涯中還遇到過一次問責強制他辭職的，但是悲劇的是，同事只有他一個人股票賺錢了。

（強制辭職會要求強制執行股權，結果後來公司垮得太快，公司大家的股權全成廢紙了。）

如果流片失敗，最大問責是設計總監/項目經理，然後責任才會下查到設計、驗證或者後端等上面。

》如果流片失敗或有重大 bug，能不能只問責於驗證人員工作的不充分？

如果錢都是驗證人員拿了，才可以哦。

沒有扯皮的功力還敢在ic公司呆？趕緊匿

TO失敗本身不算什麼特別新鮮的事情，大片兒一般都要流個兩三回。

小的毛病都是Driver去做Workaround。

要是大面積的失敗，比如Intel兩次出現的浮點問題，那一般都是中層經理一級的人去背鍋，整個Team績效會受到一些影響，但是不至於開除。因為晶元驗證有很多步，每一步都有很多人有責任。還有，開了你找誰做去。。。

流片失敗，絕對不是驗證部門的問題。

重大Bug，這個真心要看Bug類型...

追責，更多的目的是為了避免下次悲劇重演，而不是抓個替罪羊。

通常是趕緊各種測試找根源，然後申請出下一個版本補救，但如果缺陷實在太大，RD項目經理會被幹掉，我就經歷過直接上司被總部拿掉，需要我協調推動進行到半途的流片，簡直酸爽。

update: 看到有其它答主在黑台積電，哈哈，我那個項目經理也是被台積電坑的，因為後來我確證了是他們製程缺陷導致MOS電容概率擊穿，等他們更新完，再流片就好了。

題主用大陸官僚體制運作思維套用在silicon design上了。是人都會犯錯，但要及時sync，避免/減少bug發生概率，而不是扯皮找替罪羊！

反過來說，如果晶元一版ok，是不是要把功勞歸於驗證，獎金多多呢？顯然這是不會的。那麼好事沒份，壞事被追打，誰還會幹這等苦差。

只問責驗證部門……看到這幾個字我彷彿又聽見了前公司那句：當初為什麼沒有檢測出來。檢測部門的老大回應是，這些bug怎麼來的？！你們的設計怎麼這麼爛！老闆偏袒研發，導致的結果是測試部門離職率非常高。

驗證部門往往是對產品是否符合技術指標以及過往的一些曾經發生的異常情況進行驗證。但是在產品實際使用中遇到的異常情況怎麼都會比你驗證過程中預想的到的情況複雜，即使做一個現場模擬的長期測試，出現的問題數量也比不過在外面使用時候出現的問題數量，畢竟在外面使用場景比實驗室里複雜，次數也多暴露的問題也更多。在這情況下，你怎麼能要求驗證部門萬無一失，既然驗證這麼重要，你的工資給夠了沒？

在問題出現後最重要的是補救而不是追責，趕走一個熟練員工成本不小啊。如果非要追責，那就看出現的問題是在什麼地方如果不是技術文檔里規定的技術指標出問題，那應該追責研發，研發設計的東西健壯性不好出現技術指標涉及範圍以外的bug，沒理由讓驗證部門背鍋。要是什麼都讓驗證部門背鍋，必然導致其他流程的部門懈怠。

研發部門:反正不用為自己工作負責任，那就隨便弄吧

某c開頭大公司，項目負責人自我感覺極度良好，親自上手做了一堆模塊的設計或驗證。由於能力實在有限，項目一拖再拖。最後手裡的設計模塊在tapeout前不到一個月交給dv。結果可想而知，帶著一堆已知的bug就tapeout了。chip回來就可想而知了，本來驗證做的就不充分，chip回來後不斷報bug，高端的和sb的bug出了一堆。已經respin了兩次了，聽說上一代chiprespin了四次。問我這個人怎麼樣了？之前憑藉人脈一路高升，現在去了創業公司還順手挖走了一票親信。直接導致現在一群沒參與過這個chip的人為這些bug擦屁股。所以很多時候，問責誰並不是責任劃分的結果，而是政治較量的結果。

最近正在做post silicon validation的一批片子，issue number已經編到109了，你感受一下。

不過最後決定下一次流片layout上只改了三個，其他全是firmware修復。

之前有碰到嚴重問題一個，那年那個模塊的設計和驗證績效都一般，但第二年兩個人的績效立馬又補回來了。所以說這個行業的公司還是以人為本...缺人...

一想到當年我們的片子只要是有問題，都要讓我們測試技術員背鍋，生產混片背，外延片漏電…電測電壓不對，VF，LOP。只要有問題就得背鍋，一說到這裡我就激動的拍著輪椅

每次流片，老闆都要去燒香

每個project,都是有個時間表的。事實是，只要不delay schedule,天大的錯誤都可以慢慢解掉的。到了時間做不出來，不管美國公司，還是歐洲公司，都是要找個替罪羊的