當一家公司決定研發一款芯片時，起初架構師和幾位頂層設計一起創建一些需求、規范文檔。

例如各種寄存器、接口、使用手冊等等。不管文檔是否清晰規范，這些文檔就是各個模塊設計的起點。模塊設計拿著這些起始的需求規格文件，使用RTL建模實現預期的功能。

當然，實際的項目進程一般不會這么直接，很多東西存在變化和迭代。例如需求的變化、上下游模塊接口的變化，甚至整個芯片的架構變化等等。

功能驗證過程也和設計一樣，伴隨著各種變化。因為驗證就是設計的另一雙眼睛，和設計具有同樣一個需求起點（理論上）。

很多時候，設計會比驗證更早地接觸需求，但是有責任的驗證需要通過各類檢視活動從設計規格中追溯到原始需求，然后再將原始需求作為驗證起點。

簡單來說，設計工程師需要實現預期的需求（功能、性能、安全性、可靠性等等）， 驗證工程師需要確保設計正確地完成了這項工作。

驗證工程師可以說是設計的第二雙眼睛，理論上兩個人可以比一個人看得更加清楚。（但是不排除1+1<2的情況）。

驗證工程師和設計工程師并行地開發需求的模型（設計開發RTL模型，驗證開發參考模型和checker）。如果實現了真正的并行獨立開發，那出錯的概率就很小了，但是很多時候驗證模型為了和設計RTL模型比對，就會削弱獨立性，導致驗證模型和設計RTL模型錯成一樣。

驗證工程師和設計工程師，哪個看得更加清楚，因人而異，和職業本身沒有絕對的關系。

有時設計會驗證自己的設計，甚至選擇放棄第2雙眼睛（不需要驗證）。例如，需求要求實現2+2=4，但是設計理解成2+2=5，并將硬件實現為2+2=5。然后，設計自我驗證的參考模型預期依然是2+2=5。這個時候就需要第2雙眼睛的方法，另外引入一個驗證工程師獨立地理解需求，再次理解成2+2=5的概率就很小的，很大概率可以發現這個設計的bug。

真實的芯片項目中，會有多個層級的驗證，模塊級別EDA、系統級EDA、加速器和FPGA等等。所有人都錯的概率幾乎為零。

真實項目中的bug來源千奇百怪，可能來自代碼編寫錯誤、可能來自需求本身不合理無法實現、可能是系統配合等等原因，甚至可能是工具的bug導致芯片的bug。

審核編輯：劉清