DV 工程師的閒聊

IC設計流程可以簡化成下圖, 首先需要有一份規格, 複雜的規格可能需要先設計演算法, 簡單的規格設計者直接依照規格規劃 Micro-Architecture, 然後把設計做完. 之後就開始做 Synthesis 和後段的 Place & Route. 如果一切順利就可以Tapeout. IC 設計驗證在上述的設計流程上歸類到第二步驟, 主要是確認設計是否正確, 設計正確與否根據第一步驟的規格, 規格包含很多面向, 設計這要滿足規格上所陳述的每個面向和細節才能算是正確的設計. 設計是人做的, 人會誤解規格, 會做錯設計, 所以要如何確保設計不出錯, 是一件很不容易的事. 在學校裡學設計的時候, 自己做設計, 自己根據助教測資試試看結果對不對, 覺得差不多就把作業交了. 在業界做IC, 設計者(Design Engineer)可以如同學校做作業一樣, 自己驗證自己的設計; 另外一個選擇, 是由其他的工程師來做這件事, 負責做這件事的人, 叫做設計驗證工程師(Design Verification Engineer 簡稱 DV). 回顧前面兩張IC設計流程, 原本一件事被拆成兩件事來做, 成本明顯增加了, 斤斤計較的業界為什麼還是會選擇這樣做? 原因是犯錯代價越來越高. 目前高階製程的光罩費很貴, 犯錯之後產品上市的時間也會遞延, 動作慢市場就可能競爭對手拿走. 一個功能有缺陷的產品如果流向市場, 更可能造成巨大的賠償損失, 所以投資DV非常值得, 在國內也形成一個趨勢. 台灣的IC 設計業, 早期發跡時往往沒有DV team. 驗證工作由Deisgn team 做掉. 近幾年來大型IC 設計公司體認到這樣的分工, 無法負荷專案需求, 便開始投資DV人力, 目前正在蓬勃發展. 就驗證技術本身,由於要面對的問題越來越困難, 也越來越複雜, 所以無論是驗證觀念、驗證方法或驗證工具, 都在持續進步中. 下面這張簽名是 Writing Testbenches 的作者 Janick Bergeron 2009 年來台灣拜訪客戶時, 剛好有幸到公司來當面請教他一些問題, 並且把手上的書拿給他簽名. Errare Humanum Est! 翻成中文最接近的意思是"人非聖賢, 孰能無過", 這可以解釋為什麼要有驗證. 因為設計是人做的.  

 由於DV是實作型的工作, 學校很少會去接觸到這一塊, 以下就我所知列出一些可以參考的材料. 不管事有志於從事這個工作的新人, 或想成立DV team 而不知道怎麼開始的團隊都可以從中得到一些啟發: 書單 Writing Testbenches Using Systemverilog   Systemverilog for verification   IEEE 1800 Systemverilog UVM User guide  or  IEEE 1800.2 UVM   Assertion based design   影片 Doulus UVM tutorial  網站 Testbench.in Doulus Easier UVM On-line simulatior EDA playground