VCS OBC技術(shù)的評估

當前，設計驗證已經(jīng)成為半導體芯片設計過(guò)程所面臨的主要難題之一。如何確認芯片能夠在相關(guān)應用中正確運行呢？除了要面對需要寫(xiě)出盡可能多的測試來(lái)驗證芯片的各方面功能的挑戰以外，下列問(wèn)題也變得日益重要：如何測定這些測試的質(zhì)量呢？測試包到底覆蓋了多大范圍的芯片功能呢？對于這些問(wèn)題，傳統的解決方法是應用代碼覆蓋率分析工具。利用這些工具可以測量出在仿真狀態(tài)下實(shí)際執行了設計的多大部分，并能提供有關(guān)代碼行覆蓋率、條件覆蓋率、信號翻轉覆蓋率的報告。但是，代碼覆蓋率分析工具所能給出的覆蓋率數值在本質(zhì)上屬于樂(lè )觀(guān)性的估計。舉例來(lái)說(shuō)，它們可以指出一條代碼行得到了執行，但是卻不能指出這條代碼行上的代碼正確性是否得到了驗證。因此，有可能出現這種情況，即有報告顯示一條代碼行已經(jīng)在仿真狀態(tài)下得以覆蓋，但是由此產(chǎn)生的效果卻未在仿真中檢查出來(lái)，并未檢查到這條代碼行的錯誤功能。測試結果可能會(huì )顯示合格，但卻沒(méi)有察覺(jué)到錯誤的功能行為。
這項挑戰可以通過(guò)應用VCS 7.0版新增的Observed Coverage (OBC)能力得到解決。這項功能包含在VCS 7.0的測試版中，也正是我們用作OBC評估的版本。

OBC工具
OBC是一項在VCS仿真器內新增加的覆蓋率測量工具。OBC是建立在代碼行覆蓋率分析基礎上的，并在其中加入了可觀(guān)測性的概念：一行代碼在已經(jīng)執行的情況下，而且執行的效果可以傳播到觀(guān)測點(diǎn)，我們就認為這是已經(jīng)觀(guān)測的代碼行。在缺省情況下，OBC技術(shù)把包括在TestBench內最頂層的實(shí)例的輸出認定為觀(guān)測點(diǎn)。而且可以將用戶(hù)設計中的任意信號定義為觀(guān)測點(diǎn)。
通過(guò)加入可觀(guān)測性的概念，OBC工具糾正了代碼覆蓋率分析中的樂(lè )觀(guān)估計傾向，所報告覆蓋率也更為接近實(shí)際的觀(guān)測結果。OBC工具的能力在于模塊的輸出可以不必直接與觀(guān)測點(diǎn)有所連接。這一信號可以首先送入其它模塊，隨后穿過(guò)一些組合邏輯電路，儲存在第3個(gè)模塊的寄存器中，并最終在若干時(shí)鐘周期后到達觀(guān)測點(diǎn)。在這種情況下，OBC工具依然能夠檢測到信號傳播鏈路中起始部分的賦值操作已經(jīng)被觀(guān)察到。

未觀(guān)測到代碼行的原因
OBC工具可以識別出8種不同的為何代碼行被認定為未觀(guān)測到的原因。
無(wú)扇出(NFO)
在一個(gè)模塊中未能讀取的信號明顯地不會(huì )被傳播到任何觀(guān)測點(diǎn)。
未執行的讀取操作(UXR)
如果一條語(yǔ)句從未得到執行，就可能造成一次本應通過(guò)這條語(yǔ)句進(jìn)行傳播到觀(guān)測點(diǎn)的賦值操作未能執行。
未接線(xiàn)的輸出端口(UCP)
如果一個(gè)子模塊的輸出端口未接線(xiàn)，則會(huì )成為某個(gè)信號無(wú)法觀(guān)測到的明顯原因。
賦值操作未改變信號(SUA)
一個(gè)信號被賦予了與本身已有值相同的數值時(shí)，則此次賦值被認定為是無(wú)法觀(guān)測到的。這時(shí)就需要進(jìn)行另外一次賦值操作，賦予其不同的數值，方能傳播到輸出處并被認定為已觀(guān)測到。
賦值次序混亂(AOO)
這種情況經(jīng)常在若干個(gè)賦值操作必須按一定的順序進(jìn)行，以達到將某個(gè)信號數值傳播到某個(gè)輸出的目標。但是，如果這一特定順序在仿真過(guò)程中從未出現過(guò)，則此賦值鏈會(huì )斷開(kāi)，而賦值鏈的前一部分不認定為已經(jīng)觀(guān)測到。
賦值操作不受子表達式數值的影響(AIS)
在諸如x = a & b或x = a | (~b)的賦值操作中，在b的值為零時(shí)，a的值是“不關(guān)心的”。因此，所有對信號a的賦值均將被認為是未觀(guān)測到的。
僅用于事件控制(UEC)
內部時(shí)鐘或復位信號在典型情況下從來(lái)不會(huì )傳播至芯片的輸出端。但是，這些信號會(huì )觸發(fā)其它可在觀(guān)測點(diǎn)觀(guān)測到的信號的操作。無(wú)論在何種情況，OBC工具都不會(huì )認定此種時(shí)鐘和復位信號是可觀(guān)測到的。
寄存器重寫(xiě)(ROW)
如果某個(gè)寄存器數值在此數值傳播到觀(guān)測點(diǎn)前被重寫(xiě)，則產(chǎn)生原來(lái)數值的賦值操作被認定為未觀(guān)測到。

OBC工具的使用
圖1是OBC工具運行方式的概述以及報告生成的過(guò)程。
運行OBC工具需要3個(gè)步驟：
＊編譯和在代碼中建立相應的觀(guān)察機制
vcs -cm obc source.v
＊運行仿真并生成一個(gè)有關(guān)行代碼覆蓋率和可觀(guān)測性結果的數據庫
simv -cm obc -cm_obc history -cm_name test1
＊在批處理方式下生成報告
obcView -b -cm_name merged
前兩個(gè)步驟為VCS編譯和仿真的標準執行步驟，只包含了有關(guān)OBC工具的少數幾個(gè)開(kāi)關(guān)。最后一個(gè)步驟是專(zhuān)用于OBC的，這一步驟中生成若干個(gè)有關(guān)覆蓋率和可觀(guān)測性的報告文件：
?報告中可提供若干個(gè)層次的詳細信息：所有代碼行，只對未觀(guān)測到的代碼行，或者是對每個(gè)模塊的一個(gè)總結報告。
?每個(gè)模塊實(shí)例生成相應報告，但是如果同一個(gè)模塊有多個(gè)實(shí)例，也可針對每一個(gè)模塊提供一份累計報告。
?一份可用于追溯某一特定代碼行被報告為未觀(guān)測的歷史記錄報告。

OBC工具的應用
在模塊級上應用OBC工具
在模塊級上應用代碼覆蓋率分析工具是最為廣泛的應用形式，模塊設計人員需要通過(guò)它們來(lái)確認驗證了設計中的所有組成部分。但是，傳統的代碼覆蓋率分析工具在典型情況下所給出的覆蓋率結果過(guò)于樂(lè )觀(guān)。通過(guò)為OBC工具定義合適的觀(guān)測點(diǎn)后，以這種觀(guān)測為基礎的覆蓋率結果有助于查明模塊中那些已執行的部分，但其執行代碼的正確性可能根本未經(jīng)這項測試進(jìn)行驗證。在模塊級上使用OBC工具的目的就是盡可能百分之百地使所有的行都被覆蓋到并被觀(guān)測到。
在芯片級上使用OBC工具
在芯片級上同樣會(huì )發(fā)生存在于模塊級上的問(wèn)題，這些問(wèn)題的解決難度遠大于模塊級：測試包覆蓋了多大范圍的芯片功能？哪些測試是屬于冗余的？芯片中哪一部分的覆蓋率比其它部分更低？如果設計中存在一處缺陷，則是否至少會(huì )在一項測試中不能通過(guò)？
特別是對于復雜程度較高的單片系統芯片，包括一個(gè)或多個(gè)處理器、許多外設，在模塊級上的代碼覆蓋率結果是無(wú)法對下列這些問(wèn)題做出答復的，其原因有多種：
?所有的模塊均已經(jīng)假設為在單元級經(jīng)過(guò)了驗證，也就是說(shuō)，在單獨測試中已經(jīng)達到了很高的代碼覆蓋率。因而，在芯片級的驗證中，其目的不在于重復進(jìn)行相同的測試，這是由于模塊的功能已經(jīng)得到了驗證。在芯片級，我們所要驗證的是模塊的集成是正確的，而且相鄰模塊之間的信息交流是正確的。芯片級上100%的代碼覆蓋率也由于仿真資源方面的限制而無(wú)法達到。
?在芯片啟動(dòng)時(shí)，許多操作均開(kāi)始自動(dòng)執行：各個(gè)鎖相環(huán)電路均進(jìn)行啟動(dòng)，產(chǎn)生出復位序列，核心部分從ROM代碼開(kāi)始啟動(dòng)等等。這些操作將至少對某些模塊產(chǎn)生相當高的代碼覆蓋率，但是這就意味著(zhù)所有的代碼均已真正得到了測試嗎？答案或許是否定的。這是由于在較大的芯片中，只有很少數的內部信號真正傳送到了芯片的輸出端。
因此在較大的芯片中，我們就會(huì )發(fā)現這樣一種特殊的情況：一方面，標準的芯片操作產(chǎn)生出相當高的某種代碼覆蓋率，而另一方面，絕大多數的數據僅在芯片內部進(jìn)行傳送，而在芯片引腳上是觀(guān)測不到的。針對這種情況，OBC能夠有助于在芯片級仿真中產(chǎn)生更為有效的測量結果。
在隨機測試中使用OBC工具
隨著(zhù)當今的芯片設計變得越來(lái)越復雜，采用傳統的直接式激勵越來(lái)越難以達到很高的測試覆蓋率。因此，隨機驗證技術(shù)的應用越來(lái)越廣泛。但是，隨機激勵必須完全依賴(lài)于自動(dòng)檢查，因為通過(guò)對波形的目視檢查或其它手工方法無(wú)法檢查出這種仿真的正確性是不可行的。
OBC技術(shù)的概念對于在這種隨機驗證方法中判斷隨機激勵的質(zhì)量和覆蓋率是非常有用的。
但是，對于OBC工具來(lái)說(shuō)，觀(guān)測點(diǎn)的選擇對于分析來(lái)說(shuō)是至關(guān)重要的：只有通過(guò)自動(dòng)檢測得到了驗證的信號方可定義為觀(guān)測點(diǎn)。OBC不檢查某個(gè)信號數據的正確性，但是它假設其它方(人員或自動(dòng)檢查)能夠在所有的觀(guān)測點(diǎn)驗證信號的正確性。
對于觀(guān)測點(diǎn)的選擇來(lái)說(shuō)，存在著(zhù)一個(gè)非常重要的限制，這一限制對于隨機測試和直接測試一樣有效。如果觀(guān)測點(diǎn)處的信號數值沒(méi)有得到檢查，則OBC工具所報告的數字是無(wú)指導意義的。

OBC工具所獲得的首批結果
對OBC工具的首次評估只在模塊級上執行，采用了一個(gè)JTAG控制器作為受測試的模塊，然后在模塊上運行了一個(gè)有8個(gè)不同測試的測試包。表1是對這個(gè)JTAG控制器模塊所達到的覆蓋率的概述。
如表1所示，這8項測試的代碼行覆蓋率(標準覆蓋率分析)是相當高的，但是在采用了所有模塊輸出作為觀(guān)測點(diǎn)的OBC分析中，已觀(guān)測到代碼行的百分比出現很大幅度的下降。此結果表明，14%的代碼行得到了執行，但它們的執行效果并未在模塊輸出端得到直接的觀(guān)測。這些代碼行的絕大多數均與控制邏輯有關(guān)，這是由于控制信號極少直接與模塊的輸出端直接連接，而是對數據信號進(jìn)行控制。但是，OBC工具將這種情況認定為未觀(guān)測到(原因：UEC)，即使這些控制信號有可能與輸出端之間存在著(zhù)一些非直接的效應。
如果選TDO輸出端為僅有的觀(guān)測點(diǎn)(如同TDO輸出端是芯片級僅有的輸出端一樣)，則觀(guān)測到的代碼行的百分比將會(huì )出現極大幅度的下降。一方面，這一結果表明某些測試可能需要進(jìn)行改進(jìn)，以保證測試結果能夠在TDO輸出端上被觀(guān)察到。另一方面，出現大幅下降是基于許多JTAG模塊輸出均為控制信號的事實(shí)，這些控制信號都被送到芯片上的其它模塊，而且是不能夠直接觀(guān)測到的。
表2列出了一些關(guān)鍵性的數值，這些數值表明了OBC工具在仿真運行中對性能所起的影響。本結果顯示了如上所述的JTAG模塊的結果，也顯示了作為一個(gè)較大規模設計的范例的微控制器芯片的結果。每欄右側的數值表明與標準的VCS仿真相比較的性能，即沒(méi)有OBC工具或任何其它覆蓋率分析工具的情況下。
在JTAG芯片的設計中，編譯和仿真的時(shí)間較短，所以對OBC工具使用的影響是觀(guān)測不到的。但是，在更大的微處理器設計中，對于仿真時(shí)間的影響會(huì )變得非常明顯。
作為一項有意義的成果，我們發(fā)現OBC工具所產(chǎn)生出的多余數據(test.line文件)并不大。但是，OBC的能力對于仿真所需的RAM有著(zhù)顯著(zhù)的影響。這一點(diǎn)對于較大的模塊來(lái)說(shuō)，在對內存量的需求超過(guò)工作站中可提供的RAM時(shí)，可能會(huì )成為一個(gè)瓶頸。

結果和建議
盡管評估OBC時(shí)，它尚處于測試版，但該工具的表現非常穩定，而且比較容易使用。只需在標準的VCS編譯和仿真命令中加入幾個(gè)開(kāi)關(guān)項即可。
對于小規模和中等規模的模塊，它對磁盤(pán)空間和工作站內存的要求是適中的，因此可以容易地將OBC工具加入到現有的設計流程中。但是，對于大規模的芯片級仿真，OBC對于仿真時(shí)間將會(huì )有顯著(zhù)的影響，并要求占用工作站的較多內存。OBC對于這種非常大規模的設計所帶來(lái)的好處尚有必要進(jìn)行進(jìn)一步的研究。
可觀(guān)測性的概念對于傳統的代碼行覆蓋率分析來(lái)說(shuō)，是一項非常有價(jià)值的補充。它對于提高一個(gè)測試包質(zhì)量的好處是確定無(wú)疑的。將數據的變化傳送到一些觀(guān)測點(diǎn)的概念與傳統的故障仿真類(lèi)似，但是OBC解決方案在仿真速度和內存需求方面所要求的代價(jià)較低。
在評估過(guò)程中也發(fā)現了少數幾項缺點(diǎn)：
?運行OBC時(shí)需要進(jìn)行一次單獨的編譯，而且不能與其它諸如條件覆蓋率和翻轉覆蓋率等選項結合使用。
?在觀(guān)測到某個(gè)寄存器的某一位時(shí)，OBC假定整個(gè)寄存器均被觀(guān)測到。這一假定對于移位寄存器來(lái)說(shuō)屬于典型情況，但很明顯這項假定過(guò)于樂(lè )觀(guān)。在內存中的一個(gè)字被觀(guān)測到時(shí)，也會(huì )發(fā)生同樣的情況：OBC假定整個(gè)內存均被觀(guān)測到了。
?OBC對數據路徑代碼的分析是良好的。但是，它把時(shí)鐘信號、復位信號等僅用于always塊的事件控制的控制邏輯信號認定為未觀(guān)測到。
這就導致了分析結果會(huì )過(guò)于悲觀(guān)。但是對于通過(guò)采用“if”和“case”等語(yǔ)句描述的控制邏輯的判斷是不錯的，即OBC認定它們屬于可觀(guān)測到的信號。
OBC改進(jìn)建議：
?有關(guān)上述移位寄存器的問(wèn)題：很明顯，如果要對所有寄存器的所有位均單獨進(jìn)行分析，會(huì )過(guò)于耗費時(shí)間和內存。但是，應該提供一項參數選項，使得OBC能夠對所選擇的寄存器進(jìn)行逐位的處理。較為理想的是，OBC應該從源代碼中自動(dòng)地檢測出移位寄存器。
?對于內存來(lái)說(shuō)也是如此：由于內存數量可能非常大，逐字對所有內存地址進(jìn)行處理在絕大多數情況下不可能實(shí)現。但是，OBC應該能夠對所選地址范圍進(jìn)行逐字處理。
?目前，OBC可以在所選定的模塊上執行其分析任務(wù)，其中包括整個(gè)次層級。
但是，對于芯片級的仿真來(lái)說(shuō)，獲取低級模塊中所觀(guān)測到的代碼行的相關(guān)信息并無(wú)多大意義。在芯片級的集成中，其重點(diǎn)更主要地集中在最高2至3層級。是否存在一種方法，能夠規定OBC不到模塊級做檢查，或者只到極少數的幾級做檢查？■