在IC驗證者進行測試點評審的時候，或者在和DE（數字設計工程師）、SE（系統工程師）進行驗證場景討論的時候，常常會聽到“邊界”“異?！边@倆詞。他倆就像是一對形影不離的好朋友，同時出現在驗證者的耳畔和DE、SE的嘴邊。

就像丑媳婦早晚要見公婆，驗證者也注定要面對它們，無論何時何地。

其實，在每一位丑媳婦的心中，多多少少都有一些公婆的威嚴形象。對于“邊界”和“異?！?，驗證者也有咱們自己的理解。

其一、邊界場景。

“邊界”是與隨機驗證方法強相關的概念。

每一個隨機參數和變量都有各自的隨機范圍，有范圍，就有邊界。此其一也。

隨機驗證的底層邏輯是把DUT（Design Under Test）當成一個“黑盒子”，驗證者向其輸入隨機的激勵，隨機的去撞DUT內部的各個邏輯功能。每一次run隨機用例之前，驗證者都不知道會撞到哪部分DUT的邏輯功能。而在DUT內，不同的邏輯區域承載不同的功能特性。分了區域，就有邊界。次其二也。

若把DUT比作一個碩大的棗樹，隨機驗證用例就是一根棍子。驗證者仰頭望著繁茂的枝頭，要把手上這根棍子握緊。有棗沒棗，打幾桿子。

通常IC驗證者認為，配置變量、輸入數據的合法的取值范圍的“邊界”值，是一種邊界場景。這主要針對可由單個變量構成的場景，對于多個變量構成的場景，則要考慮每個變量的取值。通常，0x0，0xFFFF_FFFF（全F），Max-Value，Min-Value等被認為是“邊界”值。

“邊界”場景的變量數據必須是合法的（合理而有效的取值）。合法的則是“邊界”，非法的則可能是“異?！?。

相比于“邊界”場景，“異?！眻鼍霸隍炞C者和DE、SE之間偶爾會存在一些爭議。

比較典型的是，軟件的錯誤配置是否要當做異常場景在數字驗證中進行覆蓋。

認為“是”的人（大概率是DE/SE），通常覺得這種錯誤配置是有可能發生的，為什么不驗呢？

認為“否”的人（大概率是驗證者），回懟：汽車出廠檢驗的時候，是不是也要在河里開幾圈??？

竊以為：要判斷一個錯誤配置是不是“異?！眻鼍?，關鍵是要看芯片的方案和數字邏輯是否做了相關的“設計”。即，硬件電路是否支持這種軟件的錯誤使用。若支持，則應該作為異常，必須在驗證中進行覆蓋。若不支持，則不驗證。這也是為什么非法的數據可能是異常：若支持，則是異常；若不支持，則啥也不是。

此處的“設計”，不是只在DUT中有相關的邏輯電路，而在FS中缺失相關的描述。更不是只有SE/DE的空口白牙的說說而已。異常場景必須要在FS（Feature SPEC）中進行描述，并且數字邏輯也要支持。無文檔，不驗證，尤其是驗證者面對“異?！眻鼍爸畷r。

舉個例子，某芯片的一個配置參數范圍是1~127。如果在FS中寫了：若是配置0，則認為是軟件錯誤配置，芯片記錄錯誤配置信息并上報中斷。那么，配置參數=0是典型的“異?！眻鼍?，驗證者需要構造這種激勵，覆蓋該場景。若是FS中沒有相關的描述，則不覆蓋。若是FS沒有寫，但是SE口頭要求驗證者構造該場景，數字邏輯行為不可知，這時，驗證者可大膽的跟他說NO。

因此，異常場景的關鍵所在，還是FS中的相關描述。關于該場景，SE們在FS中至少要說清兩點：

軟件對硬件不能做什么。此其一也。

軟件若是做了不該做的事情，硬件會怎樣。此其二也。

站在軟件和應用的角度看“異?！?，它更應該是DUT的某種業務功能在執行期間，發生了錯誤或非預期的情況后，硬件邏輯的一系列相關動作，以幫助軟件更好的獲取信息，定位錯誤，撥亂反正，恢復正常。而不是業務開始之前就可知的配置錯誤（軟件本身的錯誤）。當然，硬件邏輯針對軟件錯誤做的這些所謂的“保護設計”，也能在某種程度提升芯片的問題定位效率和應用的魯棒性。但是這些“保護設計”都是實打實數字電路，會占芯片面積，也會消耗功耗。如何在提升芯片應用的魯棒性和降低冗余設計優化芯片整體PPA之間，尋找到最佳的平衡點，是擺在每一位SE、DE面前的大題目。

題外話：

“認清生活的本質之后，依然熱愛生活?！弊罱鼘@句話有了深刻的認識。生活之于每個人都或多或少有些許不易，不能因為這些而喪失對生活的熱愛。蘇軾說他看世間無一個不好的人。那估計他看世間的事也無一件不好的事。某件事咋一看去不甚好，換個角度再看，再看，總有好的一面。諸位明公，共勉之。

審核編輯：劉清