當一家公司決定研發(fā)一款芯片時，起初架構(gòu)師和幾位頂層設(shè)計一起創(chuàng)建一些需求、規(guī)范文檔。

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

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

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

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

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

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

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

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

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

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

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

審核編輯：劉清