用智能的調試與綜合技術(shù)隔離FPGA設計中的錯誤

如果您的FPGA設計無(wú)法綜合或者沒(méi)能按預期在開(kāi)發(fā)板上正常工作，原因往往不明，要想在數以千計的RTL和約束源文件中找出故障根源相當困難，而且很多這些文件還可能是其他設計人員編寫(xiě)的?？紤]到FPGA設計迭代和運行時(shí)間的延長(cháng)，設計人員應該在設計流程的早期階段就找出可能存在的諸多錯誤，并想方設法重點(diǎn)對設計在開(kāi)發(fā)板上進(jìn)行驗證。

在特定條件下采用更智能的技術(shù)來(lái)隔離特定錯誤，找到問(wèn)題電路的源頭并漸進(jìn)式修復錯誤，這很重要。為了節省時(shí)間，您可以對時(shí)鐘、約束和模塊級接口進(jìn)行初步設置檢查以確保符合設計規范，這樣就不必在綜合與布局布線(xiàn)（PR）時(shí)浪費大量時(shí)間。

Synopsys公司的Synplify Premier 和Synplify Pro FPGA設計工具以及Identify RTLDebugger 等產(chǎn)品能幫助設計人員完成上述工作。這些工具的特性使得設計人員能快速隔離錯誤，有效縮短運行時(shí)間，并減少開(kāi)發(fā)板啟動(dòng)所需的迭代次數。

精確找到開(kāi)發(fā)板上的問(wèn)題

如果開(kāi)發(fā)板出現明顯的功能性錯誤，要縮小查找問(wèn)題根源的范圍可能會(huì )相當困難。為了進(jìn)行設計調試，我們應當創(chuàng )建附加電路并保留某些節點(diǎn)，以便我們對設計運行時(shí)得到的數據進(jìn)行探測、檢查和分析。下面我們就看看如何用板級調試軟件來(lái)查找錯誤。

按下列四步法并利用RTL調試器，您能精確查找問(wèn)題，并對信號和關(guān)注的條件采樣，然后將觀(guān)察結果關(guān)聯(lián)至原始RTL，從而將問(wèn)題鎖定在RTL規范或約束設置范圍內。

第一步：指定探測。在RTL中明確要監控哪些信號和條件。在此要聲明您所感興趣的觀(guān)察點(diǎn)（要觀(guān)察的信號或節點(diǎn)）和斷點(diǎn)（RTL控制流程聲明，如IF、THEN 和CASE 等）。

第二步：通過(guò)探測構建設計。利用附加的監控電路——即用于根據您的監控要求捕捉并導出調試數據的智能內部電路仿真器（IICE）——對FPGA設計進(jìn)行綜合。

第三步：分析和調試。設計綜合完成之后，運行設計并用RTL調試器觀(guān)察數據。在開(kāi)發(fā)板上運行測試時(shí)，觀(guān)察點(diǎn)和斷點(diǎn)共同觸發(fā)數據采樣，使您能在您所關(guān)注的非常明確的條件下觀(guān)察并調試特定節點(diǎn)的電路的行為。您可將觀(guān)察到的采

樣數據寫(xiě)入VCD 文件并將其關(guān)聯(lián)到RTL。

第四步：漸進(jìn)性修復錯誤(incrementaLfix)。一旦找到了錯誤所在，就可以通過(guò)分級、漸進(jìn)式流程在RTL或約束中漸進(jìn)地進(jìn)行修復。

時(shí)序和功能性錯誤的可視檢查

FPGA設計和調試工具還有一大優(yōu)點(diǎn)，就是能顯示RTL和網(wǎng)表級原理圖。舉例來(lái)說(shuō)，具有互動(dòng)調試功能的原理圖查看器能夠顯示設計的RTL和網(wǎng)表原理圖，便于您進(jìn)行觀(guān)察并將時(shí)序報告和VCD 數據（設計在開(kāi)發(fā)板上運行時(shí)產(chǎn)生）關(guān)聯(lián)至RTL源文件。查看器包含一個(gè)RTL視圖，用來(lái)以圖示的方式描述設計。該視圖在綜合RTL編譯階段后提供，由技術(shù)獨立的加法器、寄存器、大型多路選擇器和狀態(tài)機等組件構成。通過(guò)RTL原理圖，您可以交叉探測原始RTL，對不符合預定規范的設計進(jìn)行調整，同時(shí)也可以探測到約束編輯器，從而更簡(jiǎn)便地更新和指定約束（圖1）。

要將錯誤操作的源頭追溯到RTL，您可以利用RTL調試器在RTL原理圖上方實(shí)時(shí)插入觀(guān)察到的操作數據。

原理圖查看器包括一個(gè)網(wǎng)表級技術(shù)視圖，用于顯示綜合后的實(shí)際設計實(shí)現情況。在HDLAnalyst 原理圖查看器中，該視圖基于查找表、寄存器和DSP slice 等基本的賽靈思器件原語(yǔ)。您可在原理圖中對路徑進(jìn)行交叉探測，追溯到原始的RTL以及綜合后和布局布線(xiàn)后的最終時(shí)序報告，以便分析和提高整體性能。

在FPGA中原型設計的ASIC 門(mén)控時(shí)鐘結構并非FPGA實(shí)現中的必要環(huán)節，這會(huì )導致FPGA資源使用效率低下。解決該問(wèn)題的有效辦法就是用FPGA綜合軟件轉換時(shí)鐘。

大型設計的調試

在大型設計中探測所有信號是不可能，因為生成的數據量極為龐大，而且探測數據所需的額外調試邏輯也太大。片上調試方法的一個(gè)常見(jiàn)弊病是難以提前預測需要對哪些信號進(jìn)行探測和監控。

一些調試軟件通過(guò)分治法能夠在一定程度上解決這個(gè)問(wèn)題。利用多路復用的采樣組，設計人員可以有選擇性地進(jìn)行采樣并通過(guò)多路復用的路徑和共享的IICE 在信號組之間切換。這種方法增加了可觀(guān)察的信號和條件，而且不會(huì )增加數據存儲要求。您可以即時(shí)切換感興趣的信號組，不必花時(shí)間進(jìn)行重新調整或重新綜合新的設計。

不幸的是，在探測和采樣數據時(shí)用使的調試IICE 邏輯會(huì )占用包括存儲器BRAM 在內的芯片資源。您可在SRAM 存儲卡中對IICE 采樣數據進(jìn)行片外存儲，以減少片上BRAM 的使用。這種方法的另一個(gè)好處是能增加采樣數據的深度。

我的設計無(wú)法綜合

設計錯誤的出現可能導致無(wú)法實(shí)現有效綜合或布局布線(xiàn)。由于存在成千上萬(wàn)的RTL和約束源文件，因此可能需要幾個(gè)星期才能完成首次綜合與布局布線(xiàn)。進(jìn)行FPGA原型設計時(shí)，應讓ASIC 設計源文件處于“FPGA就緒”狀態(tài)。舉例來(lái)說(shuō)，就是要進(jìn)行門(mén)時(shí)鐘轉換。

在FPGA中原型設計的ASIC門(mén)控時(shí)鐘結構并非FPGA實(shí)現中的必要環(huán)節，這會(huì )導致FPGA資源使用效率低下。解決該問(wèn)題的有效辦法就是用FPGA綜合軟件轉換時(shí)鐘。例如，門(mén)控或生成時(shí)鐘轉換功能可將生成時(shí)鐘和門(mén)控時(shí)鐘邏輯從順序組件的時(shí)鐘引腳轉移到使能引腳，這樣您就能將順序組件直接綁定到源時(shí)鐘，消除偏移問(wèn)題，并減少設計中所需的時(shí)鐘源數量，進(jìn)而節約資源。

在Synplify Premier 軟件中啟用門(mén)控時(shí)鐘選項：

– 選擇Project->Implementation Options

– 在GCC Prototyping Tools 標簽中點(diǎn)擊Clock Conversion checkbox

或在TCL中使用以下命令

set_option -fix_gated_and_generated_ clocks 1

在Synplify Pro/Premier 中執行門(mén)控和生成時(shí)鐘轉換，而set_option -conv_mux_xor_gated_clocks 1則針對基于Synopsys HAPS 的設計在Synplify Premier 時(shí)鐘樹(shù)的多路選擇器或OR 門(mén)上執行門(mén)控時(shí)鐘轉換。

“完整”的系列時(shí)鐘約束包括在所有正確位置定義時(shí)鐘并在生成的時(shí)鐘之間定義關(guān)系。有時(shí)候，時(shí)鐘會(huì )出于某種原因與真正的源斷開(kāi)關(guān)聯(lián)，例如時(shí)鐘源和時(shí)鐘目標端間產(chǎn)生了黑盒，這樣會(huì )造成順序組件的時(shí)鐘缺失或時(shí)鐘約束放置錯誤，導致首次時(shí)鐘轉換因為缺少時(shí)鐘約束而失敗。在許多情況下，轉換失敗是由約束不完整造成的。舉例來(lái)說(shuō)，門(mén)控邏輯中可能存在一個(gè)組合回路，應在時(shí)鐘轉換之前利用異常處理約束將其打破。綜合編譯階段之后會(huì )提供一個(gè)門(mén)控時(shí)鐘報告，告訴您有哪些門(mén)控和生成時(shí)鐘已被轉換以及被轉換時(shí)鐘的名稱(chēng)、類(lèi)型、分組和相關(guān)約束。另一個(gè)時(shí)鐘列表則顯示的是未轉換的時(shí)鐘，并包含故障信息，用于說(shuō)明原因。圖2 給出了報告實(shí)例。

舉例來(lái)說(shuō)，如果設計中有黑盒子，您可以在RTL中指定具體的軟件命令，用于為自動(dòng)化門(mén)控時(shí)鐘轉換提供輔助。比方說(shuō)，采用syn_gatedclk_clock_en 指令在黑盒子中指定啟用引腳的名稱(chēng)，用syn_gatedclk_clock_en_polarity 指令指出黑盒子上時(shí)鐘使能端口的極性。每個(gè)轉換實(shí)例和驅動(dòng)實(shí)例的時(shí)鐘引腳都被賦予一個(gè)可搜索的屬性，從而能在設計數據庫中識別，并提取到定制TLC/Find 腳本生成報告中。

端口不匹配

設計包含公司內外部提供的文件。在設計中進(jìn)行IP 實(shí)例化或預驗證分級模塊時(shí)，經(jīng)常會(huì )出現“端口不匹配”錯誤，而且難以檢測，特別是出現在混合語(yǔ)言設計中更是如此。舉例來(lái)說(shuō)，如果頂層VHDL實(shí)體“Top”實(shí)例化Verilog 模塊“sub”，那么頂層VHDL聲明sub 有4 位端口，而實(shí)際Verilog 模塊只有3 位端口。就Synplify Premier 軟件而言，會(huì )立即將其標記為不匹配，并在單獨的日志報告中通過(guò)超級鏈接引用該錯誤。

視圖work.sub.syn_black_box 和視圖work.sub.verilog 之間的接口不匹配

細節：

========

源視圖work.sub.syn_black_box 中的以下位端口在目標視圖work.sub.verilog 中不存在。

=======================================

Bit Port in1[4]

Bit Port in2[4]

Bit Port dout[4]

多級層次中，如何將不匹配問(wèn)題追蹤到問(wèn)題模塊的RTL定義呢？工具應以某種方式給所有模塊實(shí)例打標簽，比方說(shuō)采用orig_inst_of 屬性。屬性的值包括模塊的原始RTL名稱(chēng)，可方便地檢索至RTL。例如，假設sub_3s 導致端口不匹配錯誤，那么我們就能用以下TCL命令找回RTL模塊的原始名稱(chēng)“sub”：get_prop -prop orig_inst_of {v:sub_3s} 返回值為“sub”。

約束的清除

指定充足且正確的約束將影響到結果質(zhì)量和功能。約束聲明通常應包括三個(gè)元素：主時(shí)鐘和時(shí)鐘組定義、異步時(shí)鐘聲明、錯誤和多循環(huán)路徑聲明。

進(jìn)行綜合之前檢查約束是一個(gè)很好的方法。提供約束查看器的工具能發(fā)現語(yǔ)法錯誤并分析時(shí)序約束和實(shí)例名稱(chēng)是否適用，警示問(wèn)題所在。比方說(shuō)，它會(huì )報告通配符擴展后約束如何應用以及在定義時(shí)鐘約束后產(chǎn)生的時(shí)鐘關(guān)系。它會(huì )標出那些由于參數或對象類(lèi)型無(wú)效或不存在而未被應用的時(shí)序約束。

進(jìn)行綜合之前，在Synplify Pro/Premier 軟件中生成名為projectName_cck.rpt 的約束檢查器報告：

Synplify Pro/Premier GUI: Run -> Constraint check

或采用TCL命令：project -run constraint_check

注意，要避免潛在的MetA不穩定性，應運行“異步時(shí)鐘報告”，提醒您注意那些在一個(gè)時(shí)鐘域啟動(dòng)而在另一個(gè)時(shí)鐘域中結束的路徑。

在Synplify Pro/Premier 軟件中生成時(shí)鐘同步報告projectName_async_clk.rpt.csv：

Synplify Pro/Premier GUI：Analysis->Timing Analyst并選擇Generate Asynchronous Clock Report 選項。

采用TCL命令： set_option -reporting_async_clock

正確的方法是確保您充分且全面地對設計進(jìn)行約束，而且不會(huì )過(guò)度約束（過(guò)度會(huì )導致運行時(shí)間延長(cháng)，生成關(guān)鍵路徑錯誤報告）。確保您已完全指定多周期和錯誤路徑，并且已為得到的時(shí)鐘設置了約束（set_multicycle_path,set_false_path）。

縮短調試時(shí)間

實(shí)施潛在的RTL或約束故障解決方案可能需要好幾個(gè)小時(shí)才能看出結果。我們來(lái)看看如何利用分級“分治法”設計方法和“錯誤繼續”功能在單次綜合迭代中發(fā)現多個(gè)錯誤，從而減少迭代次數。

為縮短運行時(shí)間，模塊化流程必不可少。這種流程支持設計保存，能鎖定已經(jīng)證明有效的設計部分。支持模塊化流程的工具能幫助您在進(jìn)行綜合前創(chuàng )建RTL分區，也就是編譯點(diǎn)。一些軟件還能幫助設計人員將有故障的設計部分變成黑盒子，徹底將該部分導出并作為獨立的設計子項目進(jìn)行再加工。一旦解決問(wèn)題，子項目還能夠以網(wǎng)表形式通過(guò)自下而上的流程或用作為RTL通過(guò)自上而下的流程整合回原設計，甚至還能綜合利用自上而下和自下而上兩種流程。

要集成和調試大型設計，應盡早在設計進(jìn)程中發(fā)現錯誤的說(shuō)明。舉例來(lái)說(shuō)，“錯誤繼續”功能可提供涉及每個(gè)綜合通過(guò)信息的組合錯誤報告。“錯誤繼續”能容許非致命的非語(yǔ)法HDL編譯問(wèn)題和某些映射錯誤，因此設計人員可在每次綜合迭代中分析并完成盡可能多的設計內容。為了在帶有SynplifyPro/Premier GUI 的Synplify Premier 軟件中調用“錯誤繼續”功能，應啟用項目視圖左側的Continue-on-Error 選項。

在TCL中：set_option –continue_on_error 1

用屬性is_error_blackbox=1 標記故障模塊和帶接口錯誤的實(shí)例父模塊，如圖3 所示。

用TCL找到所有“故障實(shí)例”：

c_list [find -hier -inst * -filter

@is_error_blackbox==1]

用TCL列出所有“故障模塊”：

get_prop -prop inst_of [find -hier -inst

* -filter @is_error_blackbox==1]

要查看將被關(guān)入黑盒子或導出的故障模塊，請查找HDLAnalyst RTL視圖中的紅色塊（圖3）。

通過(guò)導出模塊隔離問(wèn)題

您可將故障模塊作為完全獨立的綜合項目導出，以便專(zhuān)門(mén)對該模塊進(jìn)行調試。導出過(guò)程會(huì )產(chǎn)生隔離的綜合項目，其中包含所有該模塊的源文件、語(yǔ)言標準和編譯庫，以及所含文件的目錄路徑和路徑順序，以達到對該模塊進(jìn)行單獨綜合與調試的目的。如前一節所示，出現錯誤的模塊會(huì )自動(dòng)在設計數據庫中標出錯誤屬性，并在設計原理圖中突出顯示，便于對該模塊進(jìn)行查找和提取。

為了導出模塊及其所有相關(guān)源文件進(jìn)行隔離調試，應首先在Synplify Pro/Premier 軟件GUI 中（圖4）的設計分級視圖或RTL視圖中選擇設計模塊或實(shí)例，然后點(diǎn)擊右鍵并在彈出菜單中選擇“Generate Dependent File List”。

將每個(gè)分級模塊的錯誤進(jìn)行修復后，您可將其再集成到設計中，既可作為RTL在整個(gè)設計環(huán)境中重新綜合（自上而下的綜合流程），也可作為網(wǎng)表（自下而上的流程）進(jìn)行綜合（見(jiàn)圖5）。

要滿(mǎn)足時(shí)序要求就不可避免地要用到設計分級，這可能會(huì )帶來(lái)挑戰。層級界限可能會(huì )限制性能，除非為設計的每個(gè)層級分區建立時(shí)序預算。使用RTL分區（也稱(chēng)為手動(dòng)鎖定編譯點(diǎn)）時(shí)，一些工具能自動(dòng)設置時(shí)序預算。Synplify Pro/Premier 軟件還能提供自動(dòng)編譯點(diǎn)，能創(chuàng )建自動(dòng)分區，比方說(shuō)通過(guò)多處理加速運行速度。預算功能為每個(gè)RTL分區建立接口邏輯模型（ILM），這樣軟件就能知道如何滿(mǎn)足每個(gè)分區的時(shí)序目標。這樣，您可為每個(gè)編譯點(diǎn)指定一個(gè)約束文件，從而覆蓋手動(dòng)鎖定編譯點(diǎn)自動(dòng)時(shí)序預算。

Synopsy 近期進(jìn)行的全球用戶(hù)調查發(fā)現，59% 的設計人員認為“設計規范的正確性”是最重要的設計挑戰之一。這個(gè)挑戰會(huì )造成設計延期，最壞情況下可能導致設計失敗。設計工具必須能盡早捕捉到錯誤，并就設計工作提供更高的可視化，確保設計規范得到有效驗證和修復。這些工具還必須就提出的設計修復方案提供反饋途徑。