要解決任何綜合崩潰問題，通常應該從了解崩潰發生在綜合的哪個階段著手，以及工具方面是否有任何跡象指向特定的模塊、賦值、聲明或推斷。

在某些情況下會出現日志不足的狀況，并且需要與賽靈思共享 RTL 設計，才能對問題進行進一步調試。

Elaboration 階段中的工具崩潰：

這意味著該工具是在對 RTL 設計進行細化時崩潰的，綜合日志看上去如下所示:

-------------------------------------------------------------------

Starting RTL Elaboration : Time (s): …

----------------------------------------------------------------

…….

Abnormal program termination (11)

Please check '..hs_err_pidxxxx.log' for details

Parent process (pid xxxxx) has died. This helper process will now exit

OR

----------------------------------------------------------------

Starting RTL Elaboration : Time (s): …

----------------------------------------------------------------

----------------------------------------------------------------

Finished RTL Elaboration : Time (s): cpu = …

----------------------------------------------------------------

RTL Elaboration failed

在綜合日志中，您應該會看到類似于“Abnormal program termination (11)”的崩潰相關消息（盡管可能是在沒有消息的情況下）。這些問題就是崩潰問題。

如果是細分崩潰問題，在大多數情況下，問題出在工具中未得到正確處理的 RTL 或 RTL 的某些部分。如果是這類情況，請與我們分享您的工程，以便我們可以在工具中添加修復程序，避免將來出現這類問題。

要在您這里調試此類問題，以下步驟可能會有用。這里的目標是將崩潰縮小到“設計模塊”，然后 -> “RTL 文件” -> “某部分 RTL” -> “Line of RTL 代碼行”。

確定發生問題的 RTL 文件是最艱巨的任務之一。要找到有問題的模塊，可以使用以下方法：

使用黑匣子的方法

賽靈思

假設設計結構及層級如下所示：

這里的目標是使用 black_box 屬性消除其他三個模塊。我們需要假設一個模塊有問題。假設 A 有問題：對于這種情況，保持 A 模塊完好無損，并將 RTL 文件中的 B、C 和 D 都設為 black_box：

(* black_box *) module B (

…)

end module

(* black_box *) module C (

…)

end module

(* black_box *) module D (

…)

end module

運行 Synthesis 并檢查工具是否以崩潰。

如果工具已崩潰，則問題要么出在模塊 A，要么出在其子模塊 (A11、A12 ... A21、A22 ......）中。在這種情況下，通過保留 A1 并將 A2 設為 black_box 繼續調試，依此類推。

如果工具沒有崩潰，則嘗試保持 B 模塊完好無損，并將 A、C 和 D 標記為 black_box。

這里有一個簡單的示例工程：

在綜合上述層級時，該工具崩潰并在綜合日志中出現以下錯誤：

….
….
Parameter break bound to: 8'b11110000
An unrecoverable error has occurred, synthesis canceled.
-------------------------------------------------------------------
Finished RTL Elaboration : Time (s): cpu = 0005 ; elapsed = 0007 . Memory (MB): peak = 3278.059 ; gain = 194.688 ; free physical = 20020 ; free virtual = 114523
-------------------------------------------------------------------
RTL Elaboration failed
INFO: [Common 17-83] Releasing license: Synthesis
4 Infos, 5 Warnings, 0 Critical Warnings and 1 Errors encountered.
synth_design failed
ERROR: [Common 17-69] Command failed: Synthesis failed - please see the console or run log file for details
INFO: [Common 17-206] Exiting Vivado at Thu Feb 21 2322 2019...

正如您在日志中可以清楚地看到的那樣，當工具試圖對設計進行細分時發生了崩潰。

為了調試這個問題，我們需要開始對模塊進行黑盒測試。嘗試多個組合后，當使用black_box屬性禁用ps2_to_ascii1時，綜合通過，同樣，當僅啟用pas2_to_ascii2時，該工具會崩潰，如下所示：

…
attribute black_box : string;
attribute black_box of Debounce : component is "yes";
attribute black_box of sinchronizer : component is "yes";
attribute black_box of SIPO : component is "yes";
attribute black_box of Driver : component is "yes";
…

由于我們已經確定了RTL文件/模塊，現在的目標是要找到RTL中導致崩潰的部分。這可能是因大循環迭代、長而復雜的賦值、復雜的位片操作或不正確的編碼方式或不支持的結構而導致的。在上述示例中，由于不支持編碼方式，導致工具崩潰：

process(…)
begin
case dummy is
when S1 =>
if rising_edge(clk) then
...
end if;
end if;
when S2 =>
if rising_edge(clk) then
...
end if;
end if;
when S3 =>
if rising_edge(clk) then
...
end if;
end if;
when S4 =>
...
end case;
end process;

**也可以通過使單個模塊成為綜合的“頂層模塊”來查看工具是否會崩潰來找到引起問題的模塊或RTL文件。

例如，當pas2_to_ascii2被設置為頂層模塊時，上述工程會以相同的錯誤崩潰。

跨邊界優化階段的崩潰：

什么是跨邊界優化？

該工具將基于synth_design命令嘗試在任何給定設計上執行許多優化。全局設置、塊級設置和屬性可以定義工具是否可以在層級（邊界）內或跨層級（邊界）執行優化。對于Vivado的默認設置，‘-flatten_hierarchy’ 被設置為‘rebuilt’，該工具會嘗試展平層級并執行跨邊界優化。

該工具會試圖找到跨邊界的優化可能性，并且可能會由于工具錯誤或由于設計問題而崩潰（在最壞的情況下）。在上述情況下，日志可能如下所示：

--------------------------------------------------------------------------
Start Cross Boundary Optimization
--------------------------------------------------------------------------
Abnormal program termination (6)
Please check 'hs_err_pid5649.log' for details
Parent process (pid 5649) has died. This helper process will now exit

為了防止這類崩潰，一個簡單的解決方法是通過將全局設置“flatten_hierarchy”更改為“none”來禁用跨邊界優化。使用“none”的缺點可能是一個糟糕的QoR，所以可能不適用于所有設計。

一個更好的方法是通過黑匣方法找到引起問題的層級，然后對該層級使用“KEEP_HIERARCHY/DONT_TOUCH”屬性來禁用該層級內/來自該層級的任何跨邊界優化。

也有一個可能是，工具在推斷/優化 BRAM時崩潰。

在這種情況下，您可以禁用BRAM推斷來看看這是否是真正的原因。要實現這一點，需要將-max_bram選項設置為‘0’。如果在將‘synth_design -max_bram’設置為0后工具即完成綜合，那么，崩潰與BRAM推斷有關。

由于禁用BRAM推斷不是一個可接受的方案，用戶將需要找到BRAM寄存器所在的模塊，并且基于客戶的應用情況，可以對存儲器寄存器使用“DONT_TOUCH”屬性以阻止BRAM推斷。

另一種方法是將該模塊標記為OOC、同時-max_bram標記為'0'，并使用默認值（即-max_bram "-1"）來運行頂層模塊的綜合。

如果您仍然遭遇崩潰，請將您的日志文件(hs_pidxxxx.log and runme.log)和詳細的設計信息發布到賽靈思官方中文論壇。

時序優化中的崩潰：

Vivado是一個時序驅動綜合引擎，對于所有設計，該工具都會嘗試查看是否有任何可能執行的優化以滿足設計的時序要求。在一些情況下，該工具可能會在時序優化階段崩潰，日志如下：

-------------------------------------------------------------------
Start Timing Optimization
-------------------------------------------------------------------
Abnormal program termination (11)
Please check 'hs_err_pid15514.log' for details

在這類情況下，首先要做的事是禁用約束(.xdc)文件并運行綜合。如果工具通過綜合操作，那么問題可能與設計加約束的方式（用戶問題）或工具處理設計約束的方式（工具問題）有關。

調試此類問題的一種方法會是找到導致崩潰的約束/約束集。這可以通過注釋約束然后逐個啟用它們來查看工具何時再次崩潰來完成。一旦您有一組引起失敗的約束，請參考UFDM驗證約束及其用法，然后對其進行相應的修改以避免這類崩潰問題。

如果您仍然看到崩潰，請將您的日志文件 (hs_pidxxxx.log and runme.log)及詳細設計信息發布到賽靈思中文論壇。

其他重要調試步驟及其分析結果：

FSM 推斷崩潰問題：

我們還看到了在綜合FSM時工具崩潰的一些問題，將全局設置-fsm_extraction設為“off”有助于解決基于FSM的崩潰問題。

堆棧溢出引起的崩潰問題：

該工具在堆棧的內存耗盡時可能會崩潰，而且可能會不報告任何情況。此外，該工具甚至可能不會在運行目錄中生成hs_pidxxxx.日志。對于與堆棧相關的崩潰，請使用以下命令調用Vivado工具：

“vivado -stack 2000”

這樣做有助于該工具獲得更多可用來執行綜合的堆棧內存，并且還可以避免與堆棧相關的崩潰問題。

Windows操作系統特定的崩潰：

有幾種原因會引起特定于Windows的崩潰，因此要確保您看到的問題不是Windows操作系統的特定問題，請在任一支持的Linux操作系統上運行一次。

OOC (Out of Context)與非OOC流程：

我們已經看了一些示例，當工程設置為完全非OOC（沒有IP、沒有RTL模塊為OOC）時，整個設計會通過綜合。在某些情況下，相反的情況也可行，可通過在OOC模式而不是“Global”模式下生成IP的輸出文件。