第一份工作的心得

在design house做了三年的DV，才疏學淺，但希望能夠將DV學完整，並有所發揮。目前大概就摸了半顆ic的程度。心得也只是在公司看到的狀況，不代表整個園區，觀念也不一定正確

很感謝當初找我進來的主管還有罩我的學長，不然以我講話很直的狀況，應該會一直被打槍吧。

未來不是現在，看看有沒有軟體部門要收留我吧，感覺os和compiler、fw那裡還滿有趣的

0.
Pioneer : ecosystem
Follower : E.C.O system
Fast Follower : still follower

1. 驗證、認證、測試，傻傻分不清楚

應該只有巷子內的人可以稍微分類出他們的不同吧，連HR都很難解釋了，學生更不會知道那在幹麼，反正統統歸到designer去。

測試，就是所謂testing，普遍會想到的場景就是跑測試機台，認為這是簡單的工作，實際上有很多人在研究scan、bist、memory test、at speed test，這些都要稱為DfT，design for test，因為和design掛勾才算是升格。

認證，所謂certification，針對一些通用規格所做的測試項目，目的是要過規格制定單位的一些規範，功能或電性，像是USB之類的，通過之後可以在產品上放上一枚標籤。

驗證(不考慮後段)，所謂verification，分很多層也有很多方法，我自己看過的就有simulation、emulation、FPGA、software，各有各的好處和限制，主要是以測function 的正確性為主，我從事的是simulation這一套方法，針對的是RTL階段的function，這裡稱之design verification(DV)，優點是visibility高，任何訊號都抓得到，驗證環境實做很有彈性，缺點是慢，而且有些實際狀況無法模擬。

2. 在硬體的領域，如果不是對驗證有興趣，在台灣那還是選ic設計比較好。(這裡指數位ic)

從學生時代就知道不管如何一定要有ic design的經驗，未來出路比較廣，面試時會假設除了RTL implementation以外，design flow 大部分都有經驗，包括FPGA、APR及DV，所謂design house就是design為主，其他只是支援的角色，如果是只做小ic或IP的公司，更是如此，所謂DV的人力也是分派給senior designer去做，並不會養專門驗證的人力，那，做小ic的公司是很多的。

如果是做SoC就是另當別論，軟體和驗證更顯得重要，邊長是公分級的die，壞一顆就是損失慘重，但專職的驗證一樣是支援角色，在公司內project leader看下來都是做design的，design team主管title 會比DV主管的職位高，就算前architect 是帶DV的，但別忘了他的第一份工作有作design唷。

目前好像有種特殊的公司，幾乎整顆SoC都是買IP，design是找整合的人力、還有驗證和軟體，優點是出貨可能比較快，缺點是成本，硬體方面受制於IP的能力。

之前矽島計畫及design house 的推波助瀾下，生產出非常多的ic designer，但是隨著大部份IP的一致化、標準化，例如I/O部份，公司也是走向整併，下線愈來愈貴，也不一定賺得回來，感覺design上能夠著墨的有愈來愈少的趨勢，這一兩年軟體蓬勃發展，雖然平均的人力價位好像還是比較低，但是板塊似乎有傾斜中，如果沒有之前打下的基礎，簡單的評估就是想到這家公司會想到他們什麼明星產品，那結果可想而知。

3. 那做專職驗證的，和designer相比的優勢到底是什麼

噢，除了SoC等級我認為有優勢之外，其他我並不認為有優勢，因為我感受不到。

這件事情是去年面試時面試主管提到的一點，我只是拿來印證。他說，專職的驗證優勢在sub -system，至少在我的經驗上我認同，designer了解自己的IP，這我們比不上，但是要如何讓不同的IP間相互作用，完成一個完整的功能，這是我們比較在行的，有點類似寫driver的感覺，但我們能看到完整的訊號傳輸。

在designer的培養上，正常情況下，考慮到穩定和產出速度，一個designer可能會專注在幾個IP上，而且一做就是好幾年相同的東西，但組織考量下無可厚非。

搭建驗證環境這件事情，我覺得要軟硬都會的人來做比較恰當，基本上我們學校出來的人應該都做得到，我覺得我們的平台還有很多要改善的空間，挪後再議，優勢部份，我們的環境太偏軟了，也許designer不會是應該的，但是如果採用比較偏硬的環境，那麼是否有優勢就很難講，但是我預期驗證架構走向會比design還要複雜而且偏軟，因此還是會需要專人來做，就我去年面試過的老外主管跟我講驗證的元件大概是design元件的三倍，依照現在的人力分配我想很難搞，我自己大概接5~6個 IP就是極限了。

4. 就算是同部門也有被分為核心價值的天龍team，此外就是其他team，最好是選對邊，這無可厚非，看看主管也都是天龍team的，但是聽到其他team抱怨分紅差很多其實心情也不太好，因為我也是其他team的一員。

5. 再次重申文件很重要。

第一次談考績就反應了

一開始進來的時候發現接手的程式幾乎沒有註解，程式架構沒有文件，變數幾乎沒有說明，只好透過問、透過猜來理解，靠著trace code、靠著經驗去了解其他底層在寫什麼，每次開始一個新的project，就會有文件漏掉沒有轉移，很多東西都是在記憶裡面，人走了就不曉得當初為何要那樣做。

對個人來說，也許是建立所謂技術障礙，但實際上我不認為這些真的有達到技術障礙的程度；但是對組織來說，卻是浪費時間，每次任務轉換，就整個pipeline flush再重新學習，有人離職了技術就失傳，對組織來說，可不是永續的辦法，就像上個project 竟然連系統的overview的spec都沒有，很多關於系統的觀念、規劃都在裡面，老人多的時候還好，當一個組織開始崩潰的時候就知道了，哼，今年每個人走都要我接，我都只能接半吊子，我也是相當無奈。

我相信以前的文件一定比較完整，去以前的project撈還是撈得到一些，但是愈來東西漏掉愈多，這已經不是英文的問題了，而是知道自己要如何表達、如何教學給別人看的技術，該有的文件、spec寫不清楚只會造成困擾，很多人都在爭主管位，可是如果連有價值的東西都理不出來，功能、流程、前因後果都不知道如何敘述、組織的話，那任務要如何交給下面的，哪有那種美國時間場場救援，只能期待找進來的人夠聰明，可以自己看懂。

我是還沒看過從a到a+啦

6. 我認為我們的環境缺少了根本的東西，而且一直都沒有改進

據我所之我們的環境用了五年以上，也是外來的，再怎麼樣也做了好幾顆ic，有一顆甚至第一版就量產，不得不說前人們真的很厲害，但可能這個team前身屬於軟體部門，所以很多程式高手，coding能力很強，但是，也許是我真的太蠢了，但是我面試完也有回來再看看我們的環境，我還是看不出來，這個環境有統計任何functional coverage，我覺得很重要啊。

有，我們有考慮coverage，但這是一種簡單的coverage，對於驗證品質，只能達到基本要求而已，根據理論，就算漫無目的打random，也是可以達到70~80%的coverage，至於functional coverage，似乎完全沒有統計，以至於random pattern怎麼打，對我而言，都是blind test，一旦人為沒有注意到，那就不會發現了，我是曾經出包的，但我相信如果去問別人有沒有測到什麼組合，我相信也答不上來。

這裡要建很多direct test 我也覺得很怪，理論上這應該是補洞用的，就我的觀念應該是設完random，看結果測到什麼，沒測到的再來補洞。

對我來講，知道洞在哪裡才有辦法補，不然我沒有方向，負責愈來愈多ip反而沒有抓住根本的東西。

面試被問到為什麼知道還不改善時，我是不好意思說沒有誘因大於沒有時間啦，我自己知道我是動不了整個平台的。

去看看別家，functional verification已經做到沒什麼可以做了，現在在做performance verification了，我們不能一直靠design guarantee做下去啊

7. 不得不說外來的和尚真的比較會念經，去看整個底層，包含文件，就是比較有規劃、整齊。

8. 兩年前問過是否有系統層級的performance 及power估計，現在還沒有人可以給我答案，不過有問到所謂的核心價值似乎有點那個，沒有競爭力了哦；也問到了之前改架構，是依據什麼理由，performance好多少，在怎樣的環境下測試？很抱歉，如同我預期的一樣，design經驗法則，靜態分析，雖然不是我要的，但至少得到答案了。power方面，很抱歉，沒有bus的power分析，只有ip的power分析，不是我想要的，但至少有個答案。

9. 一旦開始政治鬥爭，就知道該閃了，正在學習的時候，因為這種鳥事而浪費時間，對人生規劃實在是莫大的傷害，左岸都追上來了，還只會內鬥內行、外鬥外行，等捱到了那個位置再專心投入鬥爭吧

當人家說不管產品多爛都賣得出去時，我想也不用做多好了吧

不管到哪裡，老闆的人格是很重要的

10. 除了看新聞以外，看104也是個推估公司方向的方法唷，看看他們要找哪些人，加上自己的了解，除非裁掉所有人再重找啦，不然一下子找那麼多同類的人一定是要開發某些產品線，很有趣

11. ASIP 這個東西去年面試時聽到，覺得人家真的很厲害，已經在開發compiler來使用他們特殊的硬體了，我們當然也有特殊的硬體，但是刻組語來處理

12. SystemC、SystemVerilog、OVM、VMM、UVM

工具都是看人用的，看能夠把他發揮到怎樣的程度，沒有lib可用，自己還是可以手刻出來

每個語言都有他自己的特性，以前我沒有那個多體會，學長說SystemC適合做modeling，SystemVerilog適合做verification，應該是SystemC可以寫abstract level比較高的model同時又可以寫成cycle accurate，所以他拿來做system的profiling，也就是有關ESL方面的開發，例如系統的performance估計，比方說加L2好多少，很快就有數據出來了。

SystemC Verification Library內似乎有constraint random 的lib，但是google了一下原生的似乎不好用，有些關於constraint random 的研究是去提換掉原生的lib。

我太嫩了，之前還想去研究一下Constraint Programming，survey 了 google CP solver 和 gecode ，用 gecode 實做了一個小程式，但我覺得他的pattern太規律了不是我要的，偶然在check out tree的過程當中發現隔壁team的環境竟然有systemc verification lib，不管有沒有人在用，從來不知道有這好東西。

我的目的當然是拿來解那噁心的變數關係，當連一個switch選擇的限制都沒有漂亮的方式處理時，出了什麼漏洞我也不會知道。

此外如果不考慮空間問題，我也曾經想過拿SQLite去統計random過的狀況，因為我還算是稍微了解SQLite。

一切都在遇到SystemVerilog 後豁然開朗，因為他原生就是支援這些東西，他很適合verification，缺點就是綁tool，對我來講xxM只是一種基於SV的framework，想改還是可以改，學長說UVM是未來趨勢、牛人同事也這麼堅持，但是其他部門似乎比較保守。

之前想要把bus那套換成UVM，以增加更多彈性和維護、擴充方便，試了一下，還去trace了一下底層，因為我不知道他從哪裡拿到sequence item和如何處理連續request但是資料來不及給或是資料一直給但是前端還沒送完的狀況，但現在也忘了。

但是SV這套方法，到目前為止，我看到的都是測一些傳輸上的IP或是protocol，也就是資料上幾乎不太改變的IP，所以用基本的傳送接受就可以處理，但是關於我負責過的IP常常是處理複雜運算，data的內容和長度改變了，個人認為需要複雜的model參與，這就不知道SV的能力夠不夠了，也沒看到其他人有用。

另外一個替代方案是把SystemC的model和SystemVerilog接起來，這意味著又要多唸點書了


http://ovmworld.s3.amazonaws.com/ovm-uvm-update_dac_2010_presentation.pdf