VLSI的設計周期分為兩個階段：前端和后端。前端涵蓋架構規范、編碼和驗證，而后端涉及目標制程技術節點上設計的物理實現。

本文主要介紹LEC（邏輯等效檢查）在ASIC設計周期中的重要性，如何檢查它以及當LEC失敗時該怎么做。我們將探索一個測試用例，看看如果LEC失敗會發生什么，如何查明問題以及采取哪些措施來解決問題。

LEC的重要性

ASIC在流片之前，要經歷一系列設計步驟，如綜合、布局布線、簽核（sign-offs）、ECO（工程變更單）以及眾多優化過程。在每個階段，我們都需要確保邏輯功能完好無損，并且不會因為任何自動或手動更改而中斷。如果功能在整個過程中的任何時刻發生變化，整個芯片就變得毫無用處。這就是為什么LEC是整個芯片設計過程中最重要的原因之一。

隨著制程技術節點的縮小和復雜性的增加，邏輯等效檢查在確保功能的正確性方面起著重要作用。

LEC包括三個步驟，如下圖所示：設置模式，映射模式和比較模式。

圖1：邏輯等效檢查流程圖

有各種用于執行LEC的EDA工具，例如Synopsys Formality和Cadence Conformal。這里，我們將Conformal工具作為參考，以解釋LEC的重要性。

邏輯等效檢查的步驟

讓我們仔細看看邏輯等價檢查的各個步驟：

1）設置

在設置模式下，Conformal工具讀取兩個設計。我們指定設計類型，即Golden（綜合網表）和修訂版（通常，修改后的設計是Conformal工具與Golden設計相比的修改或后處理設計）。對于LEC的執行，Conformal工具需要三種類型的文件。

1. .lec文件指導Conformal工具以系統方式執行不同的命令。

2. .scan_const文件提供與掃描相關的約束，例如我們是否要忽略此文件中定義的某些掃描連接/ serdes輸入/輸出引腳。

3. .stdlib文件包含標準單元庫的指針。

在從設置模式到LEC模式的過渡中，Conformal工具展平并模擬Golden和修改后的設計并自動映射關鍵點。關鍵點定義為：

主要輸入

主要產出

D Flip-Flops

D鎖存

TIE-E門（錯誤門，在修訂設計中存在x賦值時創建）

TIE-Z門（高阻抗或浮動信號）

黑匣子

2）映射

在等效性檢查的第二階段，Conformal工具自動映射關鍵點并進行比較。比較完成后，它會確定差異。Conformal工具使用兩種基于名稱的方法和一種無名方法來映射關鍵點。當對邏輯進行微小更改時，基于名稱的映射對于gate-to-gate比較非常有用。

相反，當Conformal工具必須使用完全不同的名稱映射設計時，無名映射方法很有用。默認情況下，它會在退出設置模式時使用名稱優先映射方法自動映射關鍵點。Conformal工具未映射的關鍵點被歸類為未映射的點。

未映射的點分為三類：

額外未映射的點是僅在其中一個設計（Golden或Revised）中出現的關鍵點。

無法到達的未映射點是沒有可觀察點的關鍵點，例如主輸出。

未映射的未映射點是可到達的關鍵點，但在相應設計的邏輯扇入錐中沒有對應點。

3）比較

在Conformal工具映射關鍵點之后，驗證的下一步是比較。比較檢查關鍵點以確定它們是等效還是非等效。比較確定比較點是否：

等效

非等效

逆等效（Inverted-equivalent）

中止

在中止比較點的情況下，我們可以將比較工作更改為更高的設置。因此，Conformal工具可以僅在中止的比較點上繼續比較。Conformal工具顯示用于比較的完整運行時間和總內存。

LEC完成后會生成多個報告：

非等效報告

未映射的報告

Blockbox報告

Abort.rpt

Unreachable.rpt

Floating.rpt

Mapped.rpt

在簽核或流片處理階段，時間表太緊，無法處理具有一些嚴重邏輯故障的塊。有時，在進行手動修復或定時ECO時會破壞邏輯連接。在流片階段，邏輯故障的可能性很高，物理設計工程師沒有太多時間來關閉塊。此外，當您獲得功能ECO并進行手動連接時，破壞邏輯連接的可能性很高。讓我們看一個塊中LEC失敗的實際例子，看看它是如何被解決的。

首先，如果LEC在所有級別失敗，請不要驚慌，如前所述。當LEC失敗時，第一步是檢查“non-equivalent.rpt”文件。由于連接斷開，可能會在“non-equivalent.rpt”文件中報告更多的單元名稱。

這背后的原因是許多路徑會經歷一個失敗/斷開的連接 - 因此它的所有端點（比較點） - 被報告為“非等效”。

第1步：非等效報告

第一步是檢查非等效文件。下面的示例非等效文件顯示了LEC中失敗的152個比較點。

這152個非等效觸發器是多位觸發器。在多位觸發器中，我們合并兩個觸發器以形成具有多個輸入和輸出引腳的單個觸發器。例如，如果我們將兩個單比特觸發器合并為一個多比特觸發器，它將以D0，D1作為輸入引腳，Q0，Q1作為輸出引腳。

由于是多位觸發器，報告顯示152個觸發器計數為非等效，但實際上只有72個是非等效的。由于這些是兩位觸發器，因此總計數為72x2 = 144個觸發器。剩下的是單比特觸發器。

第2步：未映射的報告

下一步是檢查未映射的文件。此文件顯示邏輯連接斷開的未映射網絡。我們需要跟蹤網絡并找出這些網絡缺失的連接。

在上圖中，我們可以看到在設計中沒有映射一個網絡（BUFT_net_362908）。從圖2中可以看出，一旦我們檢查LEC故障數據庫中的這個網絡（BUFT_net_362908）連接，我們看到它只連接到其他單元的輸入引腳（* _364714 / A），但是另一個連接（由于無意的單元缺失，使得該網絡缺失了。

下圖中突出顯示的網絡為unmapped.rpt文件中報告的網絡。

圖2：未映射報告中的網絡

這里，我們可以看到LEC失敗設計中報告網絡的連接。

當我們在未映射的文件中報告網絡扇出（BUFT_net_362908）時，它在LEC傳遞數據庫中連接到152個觸發器。

而LEC失敗數據庫中非等效文件中報告的152個觸發器與LEC通過數據庫中報告的網絡扇出（BUFT_net_362908）相同。

現在，我們需要在之前的LEC傳遞數據庫中找到該網絡的實際網絡連接。在檢查時，我們可以很容易地注意到報告的網絡連接到LEC故障數據庫中缺少的一個逆變器。

為了找到丟失的單元格，我們必須在之前的LEC傳遞數據庫中回溯跟蹤此網絡并檢查實際連接。

不要在未映射和非等效報告之間混淆。在未映射的報告中，我們只看到未驅動輸入引腳的浮動網絡，而在非等效報告中，我們看到所有單元格都是這個丟失單元格的扇出。

第3步：修復LEC問題

在找到LEC故障的原因后，我們必須插入一個丟失了的逆變器，并在LEC故障數據庫中重做該逆變器的輸入/輸出邏輯連接。圖3顯示了新增的逆變器及其輸入輸出連接。現在，如果我們重新運行LEC，它將通過，非等效報告將顯示零非等效點。

圖3：修復丟失的連接

LEC失敗的常見區域

如果在設計中使用多位觸發器，則將出現映射golden網表與修訂網表的問題，因為觸發器名稱將在修訂后的網表中更改。

在修訂的網表中克隆后，時鐘門控單元未被映射。

在定時修復期間或在執行手動ECO時，邏輯連接會中斷。

功能ECO實施。

缺少DFT約束。

LEC的益處

減少對門級仿真的依賴。

提高了對合成和布局布線的新工具修訂的信心。

在不編寫測試模式的情況下等效性幾近完美。

降低后端進程丟失的漏洞風險。

結論

本文介紹了邏輯等效檢查，及其流程設置、調試步驟和修復LEC的解決方案。使用真實場景，還展示了LEC完成后生成的報告，并提出了一種簡單的方法來找出LEC失敗的根本原因。

IC設計團隊遇到LEC失敗問題并不罕見，采取本文所述的步驟將幫助您解決與LEC相關的問題。