Vivado崩潰調(diào)試的方案和預(yù)防

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

在某些情況下會(huì)出現(xiàn)日志不足的狀況，并且需要與賽靈思共享 RTL 設(shè)計(jì)，才能對(duì)問題進(jìn)行進(jìn)一步調(diào)試。

Elaboration 階段中的工具崩潰：

這意味著該工具是在對(duì) RTL 設(shè)計(jì)進(jìn)行細(xì)化時(shí)崩潰的，綜合日志看上去如下所示:

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

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

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

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

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

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

使用黑匣子的方法

賽靈思

假設(shè)設(shè)計(jì)結(jié)構(gòu)及層級(jí)如下所示：

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

(* black_box *) module B (

…)

end module

(* black_box *) module C (

…)

end module

(* black_box *) module D (

…)

end module

運(yùn)行 Synthesis 并檢查工具是否以崩潰。

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

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

這里有一個(gè)簡(jiǎn)單的示例工程：

在綜合上述層級(jí)時(shí)，該工具崩潰并在綜合日志中出現(xiàn)以下錯(cuò)誤：

….
….
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...

正如您在日志中可以清楚地看到的那樣，當(dāng)工具試圖對(duì)設(shè)計(jì)進(jìn)行細(xì)分時(shí)發(fā)生了崩潰。

為了調(diào)試這個(gè)問題，我們需要開始對(duì)模塊進(jìn)行黑盒測(cè)試。嘗試多個(gè)組合后，當(dāng)使用black_box屬性禁用ps2_to_ascii1時(shí)，綜合通過，同樣，當(dāng)僅啟用pas2_to_ascii2時(shí)，該工具會(huì)崩潰，如下所示：

…
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";
…

由于我們已經(jīng)確定了RTL文件/模塊，現(xiàn)在的目標(biāo)是要找到RTL中導(dǎo)致崩潰的部分。這可能是因大循環(huán)迭代、長(zhǎng)而復(fù)雜的賦值、復(fù)雜的位片操作或不正確的編碼方式或不支持的結(jié)構(gòu)而導(dǎo)致的。在上述示例中，由于不支持編碼方式，導(dǎo)致工具崩潰：

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;

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

例如，當(dāng)pas2_to_ascii2被設(shè)置為頂層模塊時(shí)，上述工程會(huì)以相同的錯(cuò)誤崩潰。

跨邊界優(yōu)化階段的崩潰：

什么是跨邊界優(yōu)化？

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

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

--------------------------------------------------------------------------
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

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

一個(gè)更好的方法是通過黑匣方法找到引起問題的層級(jí)，然后對(duì)該層級(jí)使用“KEEP_HIERARCHY/DONT_TOUCH”屬性來禁用該層級(jí)內(nèi)/來自該層級(jí)的任何跨邊界優(yōu)化。

也有一個(gè)可能是，工具在推斷/優(yōu)化 BRAM時(shí)崩潰。

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

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

另一種方法是將該模塊標(biāo)記為OOC、同時(shí)-max_bram標(biāo)記為'0'，并使用默認(rèn)值（即-max_bram "-1"）來運(yùn)行頂層模塊的綜合。

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

時(shí)序優(yōu)化中的崩潰：

Vivado是一個(gè)時(shí)序驅(qū)動(dòng)綜合引擎，對(duì)于所有設(shè)計(jì)，該工具都會(huì)嘗試查看是否有任何可能執(zhí)行的優(yōu)化以滿足設(shè)計(jì)的時(shí)序要求。在一些情況下，該工具可能會(huì)在時(shí)序優(yōu)化階段崩潰，日志如下：

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

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

調(diào)試此類問題的一種方法會(huì)是找到導(dǎo)致崩潰的約束/約束集。這可以通過注釋約束然后逐個(gè)啟用它們來查看工具何時(shí)再次崩潰來完成。一旦您有一組引起失敗的約束，請(qǐng)參考UFDM驗(yàn)證約束及其用法，然后對(duì)其進(jìn)行相應(yīng)的修改以避免這類崩潰問題。

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

其他重要調(diào)試步驟及其分析結(jié)果：

FSM 推斷崩潰問題：

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

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

該工具在堆棧的內(nèi)存耗盡時(shí)可能會(huì)崩潰，而且可能會(huì)不報(bào)告任何情況。此外，該工具甚至可能不會(huì)在運(yùn)行目錄中生成hs_pidxxxx.日志。對(duì)于與堆棧相關(guān)的崩潰，請(qǐng)使用以下命令調(diào)用Vivado工具：

“vivado -stack 2000”

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

Windows操作系統(tǒng)特定的崩潰：

有幾種原因會(huì)引起特定于Windows的崩潰，因此要確保您看到的問題不是Windows操作系統(tǒng)的特定問題，請(qǐng)?jiān)谌我恢С值?a target="_blank">Linux操作系統(tǒng)上運(yùn)行一次。

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

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