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

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

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

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

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

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

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