vivado中的rtl中电路图无发生成_Vivado 综合崩溃调试指南
歡迎FPGA工程師加入官方微信技術群
要解決任何綜合崩潰問題，通常應該從了解崩潰發生在綜合的哪個階段著手，以及工具方面是否有任何跡象指向特定的模塊、賦值、聲明或推斷。
在某些情況下會出現日志不足的狀況，并且需要與賽靈思共享 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 = 00:00:05 ; elapsed = 00:00:07 . 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 23:37:22 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 的輸出文件。
歡迎通信工程師和FPGA工程師關注公眾號
FPGA微信技術群
歡迎大家加入全國FPGA微信技術群，這里有一群熱愛技術的工程師，在這里可以一起交流討論技術！
用手指按住就可以加入FPGA全國技術群哦
FPGA IP核服務：各類優質IP核服務商，服務到位，有保障！有需求的可以直接聯系群主！
FPGA技術群平臺自營：Xilinx?Altera 鎂光、三星、海力士、ADI TI ST NXP 等品牌的優勢代理分銷商，歡迎大家有需求隨時發型號清單，我們將在第一時間為您提供最優競爭力的報價！價格低于您原有供應商5%以上！歡迎詢價-直接把需求發給群主！
FPGA技術群官方鳴謝品牌：Xilinx、 intel(Altera)、microsemi(，Actel)、LattIC e，Vantis，Quicklogic，Lucent等
總結
以上是生活随笔為你收集整理的vivado中的rtl中电路图无发生成_Vivado 综合崩溃调试指南的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： android javamail获取邮件
- 下一篇： java build path entr