本文**：
人們對乙個行業所產生的偏見多半是由於沒有親身體驗過，而在晶元領域驗證所接收到的偏見也絲毫不少於其它行業所面臨的窘境。在每次新開學與我的學生們交流的時候，他們對於驗證的理解仍然停留在當初學習vhdl或者verilog所學到的通過乙個簡易包裝的測試盒子，固定的激勵源和細緻的時序激勵調整來測試設計。當我在第一堂課將數十種以上的驗證方法列舉出來的時候，一看他們的神情便知道他們對此的一無所知。這麼看來，象牙塔裡的教育要落後工程界很多年，要知道那些老套的驗證方法從十多年前就一直是那樣教育的啊。
對於驗證的偏見
讓我們將目光再切回到企業，而即便是企業中，從執行層到管理層對於驗證的偏見也一樣不見得少，常聽到的和看到的有下面的情形，讀者可以對照一下自己的所見所聞，看看言中了幾點：
公司a目前的設計複雜度低，而且有面向市場的壓力，所以他們更願意將設計做完經過簡單的測試直接將原型通過fpga來實現和測試，至於rtl驗證的投入，還少得可憐。
公司b的驗證平台已經有很多年沒有更新過了，儘管設計越來越複雜，但是因為一直缺少經驗豐富的驗證師來更新換代公司的驗證平台，所以在新的專案開始儘管能聽到越來越多對於驗證平台老舊不方便的抱怨，專案管理者還是以缺少合適的人力來理由，讓大家通過加班來彌補驗證平台的硬性資源缺失。
公司c沒有專門的驗證團隊，而驗證的工作幾乎是公司內部的設計人員之間互相合作驗收的，至於驗證標準、計畫、環境、文件缺失驗證，所以設計師也同時擔任了驗證師。如果你們設計師驗證是否困難，他們會回答，這不就是新增激勵，看看行為是否異常嗎？看來，設計師心中的設計工作一直是最需要受到公司關注的……
公司d的驗證師團隊整體實力與設計團隊有不小的差距，通過分析我們可以發現該公司的驗證團隊是將公司不合格的設計師和新進公司的人員拼湊成的團隊。公司的管理層認為，驗證的好處不單單是可以發現一些漏洞，還可以讓那些做不好設計、暫時沒經驗的人先到驗證環境去熟悉情況，至少不會因為一些簡單的錯誤給設計種下一些嚴重的漏洞。看起來，公司d的驗證團隊接收到的是一種**的「二等公民」的待遇。
公司e的設計團隊和驗證團隊比較健全，然而他們之間的溝通經常不順利。當前期驗證發現一些漏洞的時候，還可以跟設計人員**修復漏洞的問題，而到了專案後期如果再發現什麼嚴重的漏洞，設計人員就表現得沒那麼愉快了，除了抱怨漏洞怎麼到了後期才發現，還因為發現漏洞以後設計要做更多的修補工作才有可能不影響專案節點，這無形中增加了設計修正的難度。
我們暫時找不到這種對驗證的偏見的歷史根源在什麼地方，但恰恰是一開始設計複雜度低而驗證也簡單時，這種對於驗證技術含量低的錯誤認識從很多年以前就積累了下來，以至於無論在教材、工程應用書、學術**還是從管理、公司技術路線層面都讓驗證缺席了很多年，得不到該有的尊重。這些問題積累下來對任何一方都沒有什麼好處，最直接的是影響公司晶元的質量。我們再回過頭來看看上面舉例的幾家公司一些錯誤認識具體在什麼地方：
公司a雖然看起來在用fpga可以快速得到測試結果，但是更多地是將設計作為黑盒驗證，缺少內部訊號的檢測除錯、同時也缺少隨機激勵的場景來達到驗證的完備性。
公司b為什麼缺少合適的人？深層次的原因恐怕跟對驗證不重視有很大關係，如果一開始從驗證人員招聘和後期對驗證貢獻的充分肯定上入手，那麼驗證人員的培養不會比設計人員滯後那麼多。
公司c除了對於設計師的驗證能力充分「信任」之外，也沒有覺得驗證師一項單獨需要培養的技能。而真正的事實是，驗證確實不是一項技能，而是許多項的綜合技能。
公司d看起來倒是通過這種小聰明使得那些燙手的員工沒有做出什麼可能讓公司無法挽回的損失，但除了讓員工被感到不信任之外，公司又如何能夠保證他們的驗證工作就做的足夠好發現的漏洞足夠多？要知道，設計種下了漏洞，如果沒有被發現，那麼在沒追究是哪一方過錯之前，公司的損失仍然無可挽回，這也已經是一種事實了。
公司e的設計師越到後期越不情願聽到自己的設計被發現漏洞，而且和驗證人員溝通起來也都頗為困難。除了對於設計和驗證的關係需要正確理清之外，該公司也得多鼓勵鼓勵驗證團隊讓他們在關鍵時刻可以頂住壓力，該報出的設計漏洞需要義無反顧的提交，公司也應該開啟香檳慶祝。當然不是為了又乙個加班的夜晚做設計補修，而是慶祝又乙個漏洞在流片之前被發現，為公司挽回了**的損失。
驗證面臨的現狀
晶元業對驗證的偏見不單單**於公司和業界的成見，就連之前提到了教育行業也是如此。高校的教育與晶元行業的脫節在這近十年以來越來越驗證，當我問同學們是否學習過物件導向程式設計語言的時候，在場的近百位同學有只有兩名舉起了手，其中一名還問我，為什麼要學習一門軟體程式語言？這種晶元設計有何關係？國內頂尖的微電子高校研究生在本科期間缺失的專業教育可見一斑。
我在為同學們選擇教科書的時候，也實在是捉襟見肘。最直接的限制就是國內晶元驗證領域的書目嚴重缺少，而國外優秀的圖書又缺少引進和翻譯。對於已經深入到驗證行業的人，業界優秀的圖書本身也與實際工作聯絡不夠緊密，而大多數人又缺少時間和資源來查閱每年最新的關於設計驗證會議上的驗證領域**，再加之國內本身缺少驗證行業交流的大會，使得工程師在驗證經驗積累和技術突破上缺少可以互動交流的平台。
可驗證師們不能因為缺少這些資源，而不去發聲、不去吶喊。驗證師也應該從幕後走到台前，無論在公司內部、業界形象、教育領域都能夠將驗證職業化、深入化，同時積極參加與驗證技術有關的會議，發表**，針對各種複雜的晶元驗證問題展開交流。實際上，設計之間的交流可能會有洩漏公司秘密的風險，而驗證則不然，它完全可以將設計的功能屬性在表述問題時簡化，將問題主要停留在解決驗證複雜性上面，如此更加有利於驗證的交流。同時，隨著目前個人知識傳播的興起，有望借助驗證領域技術專家的訂閱號、網路直播來開展更深入的專案問題討論，傳播關於驗證的文章和專案經驗。
就公司自身而言，在驗證師的職業發展路徑上，需要給出明確的訊號，不但需要作出及時的讚賞、認可，也需要就驗證職業發展給出清晰的路線圖，讓新員工和有經驗的驗證人員懂得，長期在驗證領域深耕一樣可以同設計師作出同樣重要的貢獻，甚至更多。驗證經理也需要在公司內部多推廣驗證的理念、宣揚其價值重要性，而專案經理也應該具備基本的驗證知識，尤其在分派驗證工作、評估驗證工作量、回顧驗證質量時可以有客觀合理的認識。
驗證標準化
驗證領域如果需要得到更清晰的認識，就首先需要將自身的流程標準化、量化，就想軟體測試的環節一樣。對於乙個驗證團隊或者一位驗證師，他如何可以表明自己足夠優秀？對於乙個團隊而言，可能我們會看他們往期晶元的成績，從專案難易度、執行時間長短、是否有延期、有重大缺陷等方面，對於個人呢？如果他是不足五年的工程師，我們主要會看他的技能和經驗兩方面是否具備所要求的水準。但這些參考部分仍然不足以、或者不清晰地評估驗證水平，我們需要乙份綜合的評估**，如同計分板一樣，將每個節點所需要做的工作，完成度、完備性、效率、復用等各個維度作出評估，將整體驗證的功能覆蓋率、效能、能耗檢查都作出量化計算。無論對於團隊還是個人，只有趨向標準化、量化的驗證才能更穩固地推進專案，做到心裡清楚，手下不慌。
驗證團隊除了需要優秀的驗證師，也需要經驗豐富的驗證經理。這一要求的著眼點並非單單在於日常管理，也包括就晶元整體規劃驗證框架、環境、流程，制定驗證計畫、評估人力、時間節點等等。與設計不同，設計經理通常不會要求設計符合一定的框架規範（儘管大公司內有設計**規範，然而遵循的人少也沒有嚴格的**檢查工具檢查**風格），而驗證經理會就本專案、之前的專案、未來的專案之間驗證環境的復用和優化兩方面考慮，要求模組、子系統和晶元級驗證環境可以保持垂直復用和水平復用的要求。同時，驗證經理也需要考慮採用何種驗證方法、選派合適的人進行驗證等。可以這麼講，正是由於驗證環境對於復用度和剪裁度的高要求，我們才更需要有合格的驗證經理給出整體的規劃，所以他的角色不單單是日常管理，更是體現在了對於整體驗證所有周邊事務的掌握上面。
驗證經驗的積累和突破
經驗分享是需要長期貫徹的事情，它包括了公司內部分享和公司外部分享兩方面。驗證的事務做久了容易讓人產生倦怠，原因主要在於驗證師對於以後的驗證環境逐漸了解、趨向於按照現有環境的框架去思考問題，也容易對現有環境的效率產生滿足，很難做到主動突破現有框架，作出改善甚至是驗證環境換代的舉措。
公司內部交流值得推薦，除了溝通成本小，不同驗證團隊、不同事業部或者分公司之間都可以就驗證技術展開交流，因為沒有哪乙個驗證團隊做的環境、技術是最完美的，這種交流經常能夠碰巧火花，產生進一步合作、分享、成果復用的可能性，當然對於提高乙個優秀驗證團隊整體影響力也是很有幫助的。
此外，我們也建議驗證團隊可以將現有的技術突破、成體系的驗證思想和框架同外面的公司做分享，畢竟驗證環境還不能算入公司的機密，這也不存在**外洩的情況，例如通過發表驗證大會的文章分享公司自開發的優秀技術、同時也聽取其他公司的新動態，這些看起來在更大的驗證生態環境中經常「走動」，也能有不小的收穫，往往自己之前有困惑的疑難點，可能早已是其它公司證明了的技術，當然，你們的驗證技術也會對其它公司帶來啟發和幫助。
至此，我們已經將驗證執行環節的檢查清單、專案驗證中的各個要素、驗證進度的收斂和跟蹤、驗證團隊和驗證師的培養以及如何長期推廣正確驗證理念的《驗證的管理篇》同大家介紹完了，感謝你們對於這一篇的跟蹤。
驗證的方法篇之七 效能驗證
本文 在邁過了效能驗證的坎以後，我們來到了效能 performance 驗證部分。顧名思義，在這部分驗證當中我們需要測試晶元的效能，而測試效能又離不開大量的運算或者資料傳輸。我們之前提到過，矽前rtl驗證的瓶頸之一在於 速度，而且一旦到了晶元級 這一因素就更進一步放大了。由於在產品定義過程中，對於系...
驗證的管理篇之六 驗證師的培養
本文 我們在之前的 晶元驗證全視篇 中針對驗證師的 自我修養 提出了包括技術和專案在內的要素分析，從 一名驗證師的自我修養 一文可以發現驗證師需要得到各方面的鍛鍊。在這些因素背後，通過日常的觀察，我們可以發現優秀驗證師之間的共同能力。這些能力不完全是與生俱來，如果你願意下功夫，也可以在下面總結出的出...
驗證的管理篇之三 驗證的收斂
本文 伴隨著隨機驗證的方式，遞迴 regression 驗證的方式變得更加有意義。一般來講，我們基於兩種目的來提交遞迴測試表 通常而言的遞迴測試指的是每次將所有測試用例提交到伺服器上，檢查測試結果。對於模組級的遞迴測試，這種方法在時間和計算資源上也許是可行的，然而對於晶元級，這種方式每次要消耗的時間...