DSO.ai
由人工智慧驱动的设计应用
瞭解更多 →
提高偵錯生產力是顛覆 FPGA Prototyping現狀的關鍵
本文原文由张贴
英文原文：
透過 FPGA Prototyping進行 RTL 偵錯的挑戰
在&苍产蝉辫;一文中，我们谈到新思科技&苍产蝉辫;HAPS?-100 原型Prototyping系統這類的現代 FPGA Prototyping平台的偵錯能力多麼具有變革性，讓開發人員實現過去只能在仿真和模拟平台上才能達到的高偵錯生產力。
這並不代表 FPGA 偵錯具有和模拟與仿真相同的偵錯能力，只是說目前在 FPGA 原型设计系統上進行偵錯是可行。不需要再花費數天或數週時間，來重建已被分解小到能在仿真器或模拟器上重現的測試案例；而通常利用仿真器或模拟器偵錯更簡單、更快速。畢竟，你的 FPGA Prototyping系統验证環境可能獨一無二，無法透過仿真或模拟重現。就算你能忍受漫長的等待時間，在緩慢的環境中執行，該環境也可能無法完美複製 stimulus sequences而導致失敗，也可能來不及達到所需要的長cycle數，而無法偵測到第一個案例中潛藏的錯誤。因此，在快速 FPGA Prototyping系統上進行偵錯，是快速解決錯誤的必要條件。
接下來我們要思考，利用 FPGA Prototyping系統進行 RTL 偵錯的主要挑戰是什麼。
挑戰 #1 – 訊號採樣深度不足
當你分別以高達 20-50 MHz 和 500 MHz 的速度為複雜的SoC 和InterfaceIP 執行測試負載(test payload)時(這對於 HAPS-100 原型设计系統而言是可行的)，在短時間內可能會發生很多事情！尤其當你使用新思科技 ProtoCompiler? 深度追蹤偵錯(Deep Trace Debug; DTD)的高速偵錯功能進行偵錯，擷取可用於波型式偵錯分析的回收追蹤緩衝區。這一切取決於故障偵測時間點和偵錯有問題的區間之間的cycle數，以及你的追蹤緩衝區是否夠深，足以擷取感興趣的相關的time slice。如果追蹤緩衝區太淺，你可以透過提早觸發(Trigger)來調整觸發程序(Trigger Sequence)，將擷取的追蹤窗口陸續移到更早的time slice。
為了因應這項挑戰，HAPS-100 利用晶片上的记忆体，提供比前幾代高 4 倍的性能和 4 倍深的Sample Queue來追蹤感興趣的訊號。
挑戰 #2 – 當设计因不明原因故障時，不知道到底要檢測訊號的範圍有多廣
不用說也知道，晶片设计的尺寸正以指數成長中。隨著设计複雜度提升，偵錯也日益複雜。DTD 能大力幫助你的偵錯工作，透過高速追蹤擷取，滿足大部分偵錯案例的需求。如果你決定要利用選定的 DTD 探針進行偵錯時追蹤其他訊號，你可以選擇重新配置Probe Points，執行相關 FPGA 的Incremental rebuild，然後重新執行。
然而，有時你並不知道设计中哪些部分處於啟用狀態，因此需要完整的訊號能見度。這表示你需要能儲存 FPGA 中所有暫存器狀態的功能，而不要消耗太多FPGA的资源。你接著會想要停止Clock，下載所有相關的暫存器資料，前進一個Cycle，然後循環 N 次。FSDB 處理必須在主機上獨立完成，以免影響執行階段的效能。接著，Data expansion technology可以將 FPGA 暫存器Map到 RTL 程式碼，並算出所有中間訊號的數值。利用新思科技 ProtoCompiler GSV (總體訊號能見度) 可以因應這些挑戰，因此你現在擁有可全視(full-visibility)的 RTL 偵錯能力。
设计中還有多個以不同頻率運作的Clock，並與現實情況連結。ProtoCompiler 可讓你生成 IICE電路智能仿真器(intelligent in-circuit emulator)模型，為每個Clock進行獨立偵錯。
挑戰 #3 – 偵錯工作階段之間的處理時間
FPGA 帶來了turnaround time; TAT 方面的挑戰，也就是花費在修改RTL 设计重新Compile FPGA或調整偵錯所需工具的時間。每次重新设计都可能需要數小時才能完成，具體數字取決於是否要完全重新compile FPGA，或者能否進行更快速的Incremental Compile。
你需要的是能減少重新设计次數以減少偵錯 TAT 的工具，例如增加Mux Group，減少记忆体使用量以最大化訊號數量的功能。這表示你可以使用單一 IICE 建立並檢測多個不同的Mux Group。
偵錯需求通常是發生在多個 FPGA 设计中的單一 FPGA。在這個狀況下，你必須檢測單一 FPGA 以得到快速的 TAT，而這需要能夠對單一 FPGA 進行增量檢測的軟體。
除了應對上述 TAT 挑戰的功能外，ProtoCompiler 亦提供Incremental Compile，讓你能針對设计其中一部分進行Incremental Compile以改善 TAT。
挑戰 #4 – 易於使用
作為 RTL 设计人員，你的目標是透過 RTL 波形分析來验证 RTL 程式碼並對其進行偵錯。就如同你利用其他所有验证平台，無論是模拟、形式還是仿真執行測試週期的作法。FPGA 也是這個道理。你不會想在FPGA netlist level執行设计偵錯 ，尤其當你的设计已經被partition到數個FPGA上的時候，而有了偵錯邏輯和時多路調變 (time division multiplexing; TDM) 等 FPGA partition結構，來管理 FPGA 不同FPGA partition間的訊號頻寬。用戶可以藉由熟知的 Verdi? 偵錯 GUI，能夠透過波形分析進行高效的 RTL 級偵錯。
ProtoCompiler 和 HAPS-100 互相合作，可讓设计偵錯更容易，而其中絕大部分的工作都是在後台為使用者完成的。
為多個 FPGA partition设计產生單一個 .fsdb檔 非常重要且必需，因為這能將偵錯提升到 RTL 设计等級。使用者可利用 Unified Compiler中的 $dumpvars 來dump出波型。此外，dump出的訊號名稱可以透過mapping的方式annotate 到 RTL 上。
Verdi 整合提供一種在 ProtoCompiler 流程??中建立完整 Verdi 偵錯環境的自動化方法，可進行设计分析，並提供更好的 RTL 訊號相關性以進行資料擴充。
总结
在 FPGA Prototyping系統上進行 RTL 设计偵錯，終究是一個容易處理的問題。你必須要執行足夠的pre-silicon測試週期，才能避免通常只在post-silicon才會發現的錯誤。FPGA Prototyping平台在執行系統验证測試裝載時，可達到接近電腦模拟等級的產出量，但你需要高偵錯生產能力，才能以此作為實用的设计確認與验证平台。多年以來，HAPS Prototyping系列产物一直都擁有這些革命性的偵錯能力。有了 HAPS-100，讓情況變得更好了！