[導讀]"在設計RTL上加assertion一般和什么有關呢？芯片類型？設計人員素質？項目需求？還是其他因素呢"很多規(guī)范都可以做出成功的芯片，甚至有些公司根本就沒有什么規(guī)范，開發(fā)人員根本不按規(guī)范做也能做出成功的芯片。作為工程人員，用不用規(guī)范、怎么規(guī)范不僅僅是看能不能做出成功的芯片，更要考...
"在設計RTL上加assertion一般和什么有關呢？芯片類型？設計人員素質？項目需求？還是其他因素呢"很多規(guī)范都可以做出成功的芯片，甚至有些公司根本就沒有什么規(guī)范，開發(fā)人員根本不按規(guī)范做也能做出成功的芯片。作為工程人員，用不用規(guī)范、怎么規(guī)范不僅僅是看能不能做出成功的芯片，更要考慮投入和產出，要考慮怎么樣用最短的時間、最少的人力做出符合使用要求的芯片產品。這是一個做事方法的問題。說到底，規(guī)范就是輔助提高團隊溝通和合作效率、快速收斂問題的工具。
我認為加不加斷言跟設計人員素質是有關的，但更重要的是取決于整個團隊的素質水平。高效的斷言依賴前期需求規(guī)格穩(wěn)定明確，畢竟開發(fā)斷言需要時間，如果規(guī)格需求在代碼實現(xiàn)階段頻繁變動，斷言的優(yōu)勢就不明顯，斷言開發(fā)工作也就顯得雞肋了。
有多少人懂斷言？很多追求時髦，把uvm作為所謂標配，其實也就是噱頭，該驗的水還是水，不管你用什么方法學。國內很多設計變來變去，設計改來改去一直不穩(wěn)定，還有時間寫斷言？內部信號之間的時序關系是要很清楚明白定義出來寫成文檔，然后才好寫斷言！設計人員連寫文檔的時間都沒有還寫毛斷言。設計代碼很隨意，代碼一更改斷言全報廢，直接assert off掉，省得仿真器吐出不干凈的東西，整個世界都清凈了。非常希望設計人員能夠在代碼內部加斷言來檢查自己覺得容易出錯的地方，甚至可以加上功能覆蓋點來測試驗證人員是否驗證到了這個點。但是這無疑會給設計人員帶來工作量。
這個東西的核心不是規(guī)范，而是設計和驗證對于電路本身的理解，哪些地方是容易出錯，傳統(tǒng)驗證方法覆蓋不了的，需要內部檢查。功能覆蓋率收集不了，需要通過SVA的Cover來補充，檢查驗證完備性。這個就跟電路設計一樣，核心是對業(yè)務的理解和邏輯時序設計，所以規(guī)范不是芯片開發(fā)核心要素，不同公司都有不同規(guī)范，大家都能作出成功的芯片。
SVA要設計有效落地，一是設計人員的能力要提升，要懂得設計的可驗證性，甚至驗證方法學，二是要給設計人員時間。
快節(jié)奏，強工作量的開發(fā)模式，設計人員很難有時間去琢磨SVA的添加。最終的效果就是形式上看到一些部分強制的要求加了很多毫無價值的水SVA，最后看不到什么效果。以SVA發(fā)現(xiàn)問題的數(shù)量來看，少之又少。
我認為加不加斷言跟設計人員素質是有關的，但更重要的是取決于整個團隊的素質水平。高效的斷言依賴前期需求規(guī)格穩(wěn)定明確，畢竟開發(fā)斷言需要時間，如果規(guī)格需求在代碼實現(xiàn)階段頻繁變動，斷言的優(yōu)勢就不明顯，斷言開發(fā)工作也就顯得雞肋了。
有多少人懂斷言？很多追求時髦，把uvm作為所謂標配，其實也就是噱頭，該驗的水還是水，不管你用什么方法學。國內很多設計變來變去，設計改來改去一直不穩(wěn)定，還有時間寫斷言？內部信號之間的時序關系是要很清楚明白定義出來寫成文檔，然后才好寫斷言！設計人員連寫文檔的時間都沒有還寫毛斷言。設計代碼很隨意，代碼一更改斷言全報廢，直接assert off掉，省得仿真器吐出不干凈的東西，整個世界都清凈了。非常希望設計人員能夠在代碼內部加斷言來檢查自己覺得容易出錯的地方，甚至可以加上功能覆蓋點來測試驗證人員是否驗證到了這個點。但是這無疑會給設計人員帶來工作量。
這個東西的核心不是規(guī)范，而是設計和驗證對于電路本身的理解，哪些地方是容易出錯，傳統(tǒng)驗證方法覆蓋不了的，需要內部檢查。功能覆蓋率收集不了，需要通過SVA的Cover來補充，檢查驗證完備性。這個就跟電路設計一樣，核心是對業(yè)務的理解和邏輯時序設計，所以規(guī)范不是芯片開發(fā)核心要素，不同公司都有不同規(guī)范，大家都能作出成功的芯片。
SVA要設計有效落地，一是設計人員的能力要提升，要懂得設計的可驗證性，甚至驗證方法學，二是要給設計人員時間。
快節(jié)奏，強工作量的開發(fā)模式，設計人員很難有時間去琢磨SVA的添加。最終的效果就是形式上看到一些部分強制的要求加了很多毫無價值的水SVA，最后看不到什么效果。以SVA發(fā)現(xiàn)問題的數(shù)量來看，少之又少。
下載文檔
