造成調試困難的因素有很多，其中包括取值未知（“X”）的情況。X是VHDL、Verilog、SystemVerilog等邏輯標準所定義的眾多邏輯值之一，可以代表1、0或Z，也就是說X的值是未知的，從而能夠預示設計或驗證環境邏輯仿真中邏輯信號的不確定性。讓事情變得更加復雜的是，在RTL和Gate仿真中，X的不確定性是各有不同。默認情況下，RTL邏輯仿真器的處理方式較為樂觀，也就是允許X在邏輯上被阻塞。舉一個比較典型的例子，多路復用器的選擇信號具有X值時，這個X值是否會被傳播取決于其建模方式。具體請參閱下表。

▲圖1 該表格最初發表于一篇題為“I’m Still In Love with My X!”的DVCon 2013會議論文，作者是Sutherland HDL。

請重點留意在建模中如何確定仿真器是否允許多路復用器傳遞0、1或X值。請注意，在實際芯片中，信號值始終為1（高電壓）或0（低電壓）。

那么，為什么要關注這種樂觀的處理方式呢？

寬松的處理方式可能隱藏著一些潛在的設計缺陷。在上述表格中，如果Sel輸入未連接，則芯片電路的電氣行為將變得不可預測。如果預計輸出為1，但出現的是0，則實際的芯片電路可能不穩定，需要重置多次才能獲得所需的值1。

門級仿真傾向于在技術邏輯單元中使用支持傳遞X值的機制（或邏輯表），因此與芯片值的相關性更大。X值的傳播讓用戶能夠在制造芯片之前發現一些不良行為。

除了像RTL仿真中那樣因較寬松的傳播行為而阻塞X值之外，還存在一些場景，其中X值不應該被傳播。就拿下圖這個簡單的例子來說：

無論模塊A輸出端的X值如何，邏輯本身應始終在與門（AND）的輸出端生成0。在這種情況下，邏輯結構的建模/仿真處理就過于悲觀了。雖然在這種邏輯結構的輸出端上調試X值對于開發者來說有點浪費時間，但對這種設計結構類型加以了解將十分受用。

為什么很難找到X？

無論X在RTL或門級仿真中如何傳播，幾乎所有X都難以進行調試。為什么會這樣？首先，產生X的根本原因或來源可能有很多。例如，某個邏輯門具有X輸入（非驅動）；存儲器或觸發器未初始化為已知值；或是觸發器違反了建立時間或保持時間的規定，都有可能產生X。下圖是一個簡單的例子：就像這個與門，有一個X和同時有多個X的情況都很常見。輸入端i1和i2上的X導致輸出端o1輸出X。

當輸入端出現多個X時，用戶需要選擇其中一個作為調試X的起點，然后反復回溯到所關注信號的驅動源或扇入信號，直到能夠找出最早出現的X值或根本原因。而當所關注的信號或根本原因信號不是造成X值的唯一原因時，用戶需要選擇另一輸入X來追蹤其根本原因。找到的第二個根本原因可能與前一個錯誤的根本原因相同，也可能是另一個來源。這是造成X難以調試且費時費力的關鍵原因之一。

此外，X通常要在設計中傳播數千個RTL語句或門級邏輯，才能到達觀察點、調試入口點或輸出端口。當然，這要取決于具體部署的環境類型、模塊級別、芯片級別或SoC。單個根本原因也可能傳播到多個觀察點。此外，這些根本原因和觀察點的邏輯錐可能交織在一起。各種因素盤根錯節，使得追蹤X難上加難。下圖說明了X態傳播和輸出端上X重疊的概念。輸出Z1僅接收到輸入A，輸出Z3僅接收到輸入B，但輸出Z2卻能接收到輸入A和輸入B。

這個追蹤過程需要多次迭代操作，非常繁瑣。此外，還需要了解來源/根本原因的類型。例如，系統可能有意設置了一個尚未重置或賦值的內存數組，而某個地址可能錯誤地指向了這個未初始化的數組。所以追蹤這個數組并理解這個地址的邏輯也非常關鍵。話雖如此，是否有一種方法可以自動追蹤X的根本原因，并且在確定了根本原因后，對這些X進行分類或解釋原由？這種自動化將大大節省開發工作量，并大幅提升開發者的工作效率。

新思科技Verdi的XRCA組件

新思科技Verdi回歸調試自動化的XRCA組件是一種先進的根本原因分析工具，恰好能夠滿足上述自動化要求。XRCA是追蹤X和進行根本原因分析的出色引擎，不僅可以自動掃描FSDB中的X信號并追蹤X信號的根本原因，而且可以批量處理大量X信號以縮短調試時間。此外還能生成邏輯清晰的報告，按不同類別列出根本原因。報告會加載到新思科技Verdi的RCA主設備中，以便觀察結果和追蹤路徑。

XRCA是在啟動門級仿真和進行回歸處理時調試X信號的理想工具。除了許多根本原因分類之外，XRCA還支持門級網表追蹤、RTL級追蹤、新思科技VCS X態傳播追蹤、低功耗組件X追蹤，以及X值悲觀處理檢測。