目錄

• 1 用IDE進(jìn)行邏輯分析
• • 1.3 Netlist窗口的使用
  • 1.4 Hierarchy窗口的使用
  • 1.5 利用率報告的使用
  • 1.6 Schematic 窗口的使用
  • 1.9 DRC報告的使用
  • 1.10 驗證設(shè)計方法論DRC(Validating Design Methodology DRCs)
• 2 時序分析功能
• • 2.1 Report Timing Summary
  • • 2.1.1 Report Timing Summary對話框的設(shè)置
    • 2.1.2 時序總結(jié)報告的詳情
    • 2.1.3 報告Clock Networks
  • 2.8 報告跨時鐘域（Clock Domain Crossings）
  • • 2.8.3 跨時鐘域報告規(guī)則

1 用IDE進(jìn)行邏輯分析

1.3 Netlist窗口的使用

網(wǎng)表窗口展示了經(jīng)過Synthesis工具綜合后的網(wǎng)表的層次結(jié)構(gòu)。

根據(jù)綜合設(shè)置
網(wǎng)表層次結(jié)構(gòu)可能與原始RTL 100%匹配，也可能沒有層次結(jié)構(gòu)。
通常，Synthesis工具默認(rèn)保留大部分用戶層次結(jié)構(gòu)，同時優(yōu)化邏輯。這將產(chǎn)生一個更小、更快的網(wǎng)表。

使用合成工具的默認(rèn)值，網(wǎng)表層次結(jié)構(gòu)是可以識別的，但是層次結(jié)構(gòu)的接口可能會被修改。可能缺少一些引腳和層次結(jié)構(gòu)級別。層次結(jié)構(gòu)的每一層都顯示它的層次結(jié)構(gòu)樹。在每一層，工具顯示：

• 一個nets文件夾。
• 一個leaf cells文件夾（如果有該級別的硬件原語實例）。
• 在該級別實例化的任何層次結(jié)構(gòu)。

每個層級的屬性窗口顯示了資源使用統(tǒng)計包括：

• 整個分支樹基本資源的使用情況。
• 分支樹的net數(shù)量
• 層級的時鐘使用。

1.4 Hierarchy窗口的使用

打開Hierarchy窗口： Tool-> Show Hierarchy 或者 在Netlist窗口按F6。
這個窗口是網(wǎng)表的層次結(jié)構(gòu)圖，層次結(jié)構(gòu)的每一層的大小都是相對于該層的實例數(shù)量與設(shè)計中的實例總數(shù)的比值。

1.5 利用率報告的使用

打開窗口：Reports-> Report Utilization… 或者 Open Implementation Design -> Report Utilization

1.6 Schematic 窗口的使用

原理圖是網(wǎng)表的圖形化表示。原理圖可以：

• 網(wǎng)表的圖形表示。
• 檢閱邏輯門，層次結(jié)構(gòu)以及連接。
• 查找以及展開邏輯體。
• 分析設(shè)計。
• 更好的理解內(nèi)部設(shè)計。

1.9 DRC報告的使用

設(shè)計規(guī)則檢查（Design Rule Checks，DRCs）檢查設(shè)計并報告常見的問題，2016.1版后，drc被分成兩個不同的命令。方法學(xué)的drc已經(jīng)移到report_methodology命令中，而所有其他的drc都在report_drc命令中。使用report_drc命令運(yùn)行非方法學(xué)的drc。
在實現(xiàn)期間，這些工具也運(yùn)行DRCS。在布局和路由方面，drc變得更加完整和全面。

在設(shè)計流的早期檢查DRC消息、Critical Warnings和Warnings，以防止以后出現(xiàn)問題。

比如：在綜合設(shè)計(synthetic Design)中，Report DRC步驟為不受約束的I/O報告一個【嚴(yán)重警告】。布線設(shè)計DRC報告也會報告【嚴(yán)重警告】。這個時候必須審查這份報告。不然在write_bitstream時，DRC會被提升為【Error】，無法生成比特流。所以需要盡早審查DRC報告，以確定需要修改的設(shè)計領(lǐng)域。

1.10 驗證設(shè)計方法論DRC(Validating Design Methodology DRCs)

由于方法的重要性，Vivado工具提供了report_methodology命令，該命令專門檢查方法是否符合drc。根據(jù)設(shè)計過程的不同階段，有不同類型的drc。RTL lint風(fēng)格的檢查運(yùn)行在詳細(xì)的RTL設(shè)計上；綜合設(shè)計中采用了基于網(wǎng)表的邏輯和約束檢查；實現(xiàn)和時序檢查在實現(xiàn)上運(yùn)行。
要在Tcl提示符下運(yùn)行這些檢查，請打開要驗證的設(shè)計并輸入以下Tcl命令:
report_methodology

在Methodology窗口中列出了違例(如果有的話):

2 時序分析功能

報告時序總結(jié)（Timing Summary）： Implementation后，Reports -> Timing -> Report Timing Summary 或者打開implementation后打開。
Tcl命令： report_timing_summary

綜合后的設(shè)計，Vivado 時序引擎基于連接和扇出估計net延時，對于用戶已經(jīng)放置的單元之間的網(wǎng)，延時的準(zhǔn)確性更高。在一些預(yù)先放置單元(如I/O和GT)的路徑上可能存在更大的時鐘偏差。

實現(xiàn)后的而設(shè)計，Vivado基于實際的布線信息估計net延時，如果已經(jīng)完成了布線則使用時序報告查看。

2.1 Report Timing Summary

2.1.1 Report Timing Summary對話框的設(shè)置

page1：

Report:

• Path delay type: 選擇要運(yùn)行的分析的類型。對于綜合后的設(shè)計，只有最大延時分析(setup/recovery)是默認(rèn)執(zhí)行的。對于實現(xiàn)后的而設(shè)計，最大和最小延時分析(setup/hold, recover/removal)是默認(rèn)執(zhí)行的。若要只運(yùn)行最小延時分析(hold and removal)，選擇延時類型min。
  等效Tcl選項：-delay_type。

• Report unconstrained paths
  產(chǎn)生沒有時序要求的路徑的信息，IDE默認(rèn)勾選，但是等效的Tcl命令（report_timing_summary）默認(rèn)是不選的。
  等效Tcl選項：-report_unconstrained。

• Report datasheet
  生成報告數(shù)據(jù)表中定義的設(shè)計數(shù)據(jù)表。
  等效Tcl選項：-datasheet

Path limits:

• Maximum number of paths per clock or path group:
  控制每個時鐘對或路徑組報告的最大路徑數(shù)。默認(rèn)是10
  等效Tcl選項：-max_paths
• Maximum number of worst paths per endpoint:
  控制每個路徑端點可能報告的最大路徑數(shù)。此限制以每個時鐘對或路徑組的最大路徑數(shù)為限。因此，報告的路徑總數(shù)仍然受到-max_paths數(shù)量的限制。
  等效Tcl選項：-nworst

Path Display:

• Display paths with slack less than:
  根據(jù)松弛值過濾所報告的路徑。此選項不影響匯總表的內(nèi)容。
  等效Tcl選項：-slack_lesser_than

• Significant digits:
  控制報表中顯示數(shù)字的準(zhǔn)確性。
  等效Tcl選項：-significant_digits

Command: 顯示Tcl命令行，相當(dāng)于在上面的對話框中指定的各種選項。
Open in a New Tab:: 在新選項卡中打開結(jié)果，或者替換由results窗口打開的最后一個選項卡。
Open in Timing Analysis Layout: 將當(dāng)前視圖布局重置為定時分析視圖布局。

page2:

Report:

• Report from cell: 允許限制設(shè)計中特定單元格的時間報告。只有開始、結(jié)束或完全包含在單元格中的路徑才會被報告。
  等效Tcl選項：-cell

• Show input pins in path: 顯示用于路徑的單元格輸入管腳。保留此選項以提供路徑中使用的所有引腳的更多信息
  等效Tcl選項：-input_pins

• Report unique Pins: 為每種特殊的引腳只顯示一個時間路徑。
  等效Tcl選項：-unique_pins

File Output:

• Write results to file: 將結(jié)果寫入指定的文件名。默認(rèn)情況下，報告被寫入Vivado IDE中的Timing窗口
  等效Tcl選項：-file

• Overwrite/Append: 當(dāng)報告被寫入文件時，確定(1)指定的文件是否被覆蓋，或(2)新的信息被附加到現(xiàn)有的報告中。
  等效Tcl選項：-append

Miscellaneous:

• Ignore command errors: 忽略任何命令行錯誤并且不返回任何消息。該命令還返回TCL_OK，不管在執(zhí)行期間遇到任何錯誤。
  等效Tcl選項：-quiet

• Suspend message limits during command execution: 臨時覆蓋任何消息限制并返回所有消息。
  等效Tcl選項：-verbose

page3：

Interconnect: 控制網(wǎng)絡(luò)延時是根據(jù)leaf cell pins之間估計的布線距離計算的，還是由實際布線網(wǎng)絡(luò)計算的，或者從時序分析中排除net延時。對于綜合后的設(shè)計，該選項自動設(shè)置為“ Estimated”，對于實現(xiàn)后的設(shè)計，該選項自動設(shè)置為“Actual”。

• Estimated:對于未放置的單元，根據(jù)驅(qū)動器和負(fù)載以及扇出的性質(zhì)，凈延時值對應(yīng)于可能的最佳放置的延時。在時序路徑報告中，未放置的leaf cell pins之間的網(wǎng)被標(biāo)記為unplaced。對于已放置的cell，凈延時取決于驅(qū)動器和負(fù)載以及扇出之間的距離。這個網(wǎng)在時間路徑報告中被標(biāo)記為estimated。
• Actual: 對于已布線網(wǎng)絡(luò)，net延時對應(yīng)于路由互連的實際硬件延時。此net在定時路徑報告中被標(biāo)記為routed。
• None: 在時序報告中不考慮互連延時，凈延時被強(qiáng)制為零。
  等效Tcl命令： set_delay_model

Speed Grade Setting: 設(shè)置器件速度等級。默認(rèn)情況下，此選項是根據(jù)創(chuàng)建項目或打開設(shè)計檢查點時選擇的器件類型來設(shè)置的。您可以更改此選項，以根據(jù)另一個速度級別報告同一設(shè)計數(shù)據(jù)庫的時序情況，而無需重新運(yùn)行完整的實現(xiàn)流程。
等效Tcl命令： set_speed_grade

Multi-Corner Configuration Setting: 指定要分析的指定 timing corner 的路徑延時類型。有效值為none、max、min和min_max。選擇none將禁用對指定corner的計時分析。推薦設(shè)置建立(max)和保持(min)分析選擇的兩個區(qū)域。
等效Tcl命令： config_timing_corners

Disable Flight Delays: 不要在I/O延時計算中添加包延時。
等效Tcl命令： config_timing_analysis

2.1.2 時序總結(jié)報告的詳情

時序總結(jié)報告包含一下部分，Report Timing Summary不光包括其他報告的內(nèi)容(Report Clock
Interaction, Report Pulse Width, Report Timing, Check Timing) ，也包含一些特有的內(nèi)容，如Unconstrained Paths。

節(jié)說明

General Information Section	提供設(shè)計名稱，器件等信息
Timer Settings Section	包含有關(guān)Vivado用于在報告中生成時序信息的時序分析引擎設(shè)置的詳細(xì)信息。
Design Timing Summary Section	時匯總報告的設(shè)計時序匯總部分提供了設(shè)計時序的匯總，并將所有其他部分的結(jié)果合并到一個視圖中。
Clock Summary Section	包含類似于report_clocks生成的信息:設(shè)計中所有的時鐘；每個時鐘的屬性。縮進(jìn)反應(yīng)了時鐘的關(guān)系
Check Timing Section	包含關(guān)于缺少時序約束或需要檢查的帶有時序問題的路徑的信息。對于完整的時序signoff，必須約束所有路徑端點。
Intra-Clock Paths Section	匯總了同一源和目的時鐘的最嚴(yán)重松弛和總違例情況。
Inter-Clock Paths Section	與Intra-Clock Paths部分類似，總結(jié)了不同源和目標(biāo)時鐘之間的時間路徑的最嚴(yán)重松弛和總違例情況。
Path Groups	顯示默認(rèn)路徑組和自定義路徑組。
User-Ignored Paths Section	顯示了由于set_clock_groups和set_false_path約束而在定時分析中被忽略的路徑。報告的松弛是無限的。
Unconstrained Paths Section	顯示由于缺少計時約束而沒有時序的邏輯路徑。這些路徑按源時鐘對和目標(biāo)時鐘對分組。當(dāng)沒有時鐘可以與路徑起點或端點相關(guān)聯(lián)時，時鐘名稱信息顯示為empty(或NONE)

Design Timing Summary Section

Setup Area (Max Delay Analysis)：

• Worst Negative Slack (WNS): 這個值對應(yīng)于最大延時分析中所有時序路徑的最壞松弛。可正可負(fù)。
• Total Negative Slack (TNS): 僅考慮每個計時路徑端點的最壞違例時，所有WNS違例的總和。當(dāng)滿足最大延時分析的所有時序限制時為0ns，當(dāng)有違例行為時，是負(fù)的。
• Number of Failing Endpoints: 時序違例（WNS < 0ns）的點總數(shù)。
• Total Number of Endpoints: 被分析的端點總數(shù)。

Hold Area (Min Delay Analysis)：

• Worst Hold Slack (WHS): 對應(yīng)于所有時序路徑的最壞松弛，用于最小延時分析。可正可負(fù)。
• Total Hold Slack (THS): 當(dāng)只考慮每個計時路徑端點最嚴(yán)重的違例時，所有WHS違例的總和。
• Number of Failing Endpoints: 時序違例（WHS < 0ns）的點總數(shù)。
• Total Number of Endpoints: 被分析的端點總數(shù)。

Pulse Width Area (Pin Switching Limits)：

• Worst Pulse Width Slack (WPWS): 當(dāng)同時使用最小和最大延時時，對應(yīng)于上面列出的所有時序檢查的最壞松弛。
• Total Pulse Width Slack (TPWS): 當(dāng)只考慮設(shè)計中每個引腳最嚴(yán)重的違例時，所有WPWS違例的總和。
• Number of Failing Endpoints: 時序違例（WPWS < 0ns）的點總數(shù)。
• Total Number of Endpoints: 被分析的端點總數(shù)。

Check Timing Section
可以通過Reports -> Timing -> Check Timing 或者 Tcl命令check_timing單獨(dú)產(chǎn)生。

這個報告包含的時序檢查：

時序檢查說明

pulse_width_clock	報告只有與該時鐘引腳相關(guān)聯(lián)的脈沖寬度檢查，以及沒有setup或hold檢查，沒有recovery、 removal或clk > Q檢查。
no_input_delay	沒有任何輸入延時限制的非時鐘輸入端口的數(shù)量。
no_clock	定義的時鐘與時鐘引腳數(shù)不匹配。電平恒定的時鐘引腳也會報告
constant_clock	檢查接到一個恒定信號（gnd/vss/data）的時鐘信號
unconstrained_internal_endpoints	沒有時序要求的路徑端點數(shù)(不包括輸出端口)。數(shù)量與缺少時鐘定義直接相關(guān)，這也是由no_clock檢查報告的
no_output_delay	一個輸入延時約束都沒有的non-clock端口數(shù)
multiple_clock	一個時鐘引腳有多個時鐘，如果在一個時鐘樹中有一個時鐘多路復(fù)用器，就會發(fā)生這種情況。默認(rèn)情況下，共享同一時鐘樹的時鐘是一起計時的，這并不代表現(xiàn)實的時序情況。在任何給定的時間里，時鐘樹上只能有一個時鐘。如果沒有MUX，需要檢查為什么多個時鐘在同一時間到達(dá)
generated_clocks	不屬于同一時鐘樹的主時鐘源所生成的時鐘的數(shù)量。當(dāng)主時鐘和生成的時鐘源點之間的邏輯路徑上的時序弧被禁用時，就會發(fā)生這種情況。當(dāng)使用-edges選項指定時，此檢查也適用于生成時鐘的單個邊緣:邏輯路徑 unateness(反相/非反相)必須匹配主時鐘和生成時鐘之間的邊緣關(guān)聯(lián)。
loops	在設(shè)計中發(fā)現(xiàn)的組合邏輯loops的數(shù)目。循環(huán)被Vivado IDE時序引擎自動打破以報告時序
partial_input_delay	只有最小或最大輸入延時限制的非時鐘輸入端口數(shù)。這些端口在setup和hold分析中都沒有報告。
partial_output_delay	只有最小或最大輸入延時限制的非時鐘輸出端口數(shù)。這些端口在setup和hold分析中都沒有報告。
latch_loops	檢查和警告設(shè)計中通過鎖存器實現(xiàn)的loops。這些loops不會被報告為組合loops的一部分，并且會影響相同路徑上的鎖存時間計算。

2.1.3 報告Clock Networks

Tcl命令： report_clock_networks -name {network_1}

2.8 報告跨時鐘域（Clock Domain Crossings）

報告CDC(Clock Domain Crossings)會進(jìn)行分析的結(jié)構(gòu)：

• 在異步時鐘之間的所有路徑上。
• 僅在有下列時序異常的同步時鐘之間的路徑上:
  • Clock groups
  • False Path
  • Max Delay Datapath Only

2.8.3 跨時鐘域報告規(guī)則

CDC拓?fù)涞脑韴D表示

單bit同步器

ASYNC_REG屬性必須在同步鏈的至少前兩個觸發(fā)器上設(shè)置。同步器深度由鏈?zhǔn)接|發(fā)器的數(shù)量定義。

多bit同步器

基于寄存器的總線同步器在跨時鐘域處理中是不安全的，所以CDC-6規(guī)則會報一個警告供用戶判斷。
如果總線是格雷編碼，那么這種方法就是安全的，只要總線上已經(jīng)設(shè)置了足夠的時間限制，以確保接收域一次只能捕獲到一個數(shù)據(jù)。
如果總線不是格雷編碼，應(yīng)該用其他的同步器拓?fù)浣Y(jié)構(gòu)，比如CE控制的CDC或MUX控制的CDC。

異步復(fù)位同步器
基于CLEAR進(jìn)行同步：

*FDCE: D Flip-Flop with Clock Enable and Asynchronous Clear

基于PRESET進(jìn)行同步：

*FDPE: D Flip-Flop with Clock Enable and Asynchronous Preset

觸發(fā)器1分別連接同步clear或preset信號，它們對clk_a是安全的。
一般的建議是避免在目標(biāo)時鐘域內(nèi)多次同步復(fù)位信號這意味著從源時鐘域到目標(biāo)時鐘域的復(fù)位不應(yīng)該有任何扇出。此建議防止目標(biāo)時鐘域在不同的時間釋放復(fù)位，這會將設(shè)計置于未知狀態(tài)。未能遵循這一建議將導(dǎo)致從 launch flop到目標(biāo)時鐘的關(guān)鍵CDC-11扇出違例。
然而，在FIFO Generator IP的場景種，有多次同步的復(fù)位信號在目的時鐘域也是安全的。FIFO Generator異步進(jìn)入復(fù)位狀態(tài)然后同步釋放，雖然FIFO接收到異步復(fù)位，但它將真正的同步復(fù)位應(yīng)用于BRAM。只要設(shè)計使用其wr_rst_busy信號來保持?jǐn)?shù)據(jù)流，就不會出現(xiàn)邏輯部分未復(fù)位而部分仍處于復(fù)位狀態(tài)的情況。
AXI接口使用5個FIFO生成器IP來同步每個目標(biāo)時鐘域中的重置，并且是通過構(gòu)造安全的重置電路的另一個示例。在安全的情況下，可以多次同步重置信號，可以忽略CDC-11違例。

在同一目標(biāo)時鐘域中涉及兩個FIFO生成器的安全復(fù)位同步示例：

組合邏輯
在clk_a到clk_b種的組合邏輯LUT3，實現(xiàn)clk_a到clk_b同步。

這種結(jié)構(gòu)傳統(tǒng)上不推薦，因為組合邏輯的輸出可能會出現(xiàn)小故障，它會被同步器捕獲并向下傳播到設(shè)計的其余部分。

扇出
在下圖所示的簡化的Fanout示例中，源觸發(fā)器驅(qū)動一個網(wǎng)絡(luò)，該網(wǎng)絡(luò)在以紅色突出顯示的clk_b域中同步了三次。不建議使用這種結(jié)構(gòu)，因為它會導(dǎo)致目標(biāo)時鐘域的數(shù)據(jù)一致性問題，因為通過同步器的延時是有邊界的，但不是周期精確的。

N到N個不同時鐘域的扇出不是CDC問題，也不會觸發(fā)CDC-11違例。

多時鐘扇入
clk_a和clk_x兩個時鐘傳送數(shù)據(jù)通過組合邏輯（LUT2）給clk_b時鐘域的同步器：

建議首先分別同步來自clk_a和clk_x的源數(shù)據(jù)，然后再通過一些邏輯將它們組合起來。這改善了CDC整體結(jié)構(gòu)的MTBF特性，并防止小故障傳播到目標(biāo)時鐘域。

Non-FD Primitive

FDRE與RAMB之間發(fā)生了CDC，而RAMB原語內(nèi)部不存在同步邏輯。即使插入連接到clk_b的單級觸發(fā)器到RAMB前,由于FDRE和RAMB單元之間的路由距離，它仍然被認(rèn)為是一個不充分的同步器。

CE-controlled CDC
時鐘使能（clock enable）信號在【用于控制寄存器FF3前】在時鐘域clk_b同步。

CDC引擎僅檢查連接到FF3/CE的信號是否也由clk_b驅(qū)動。時鐘使能信號的同步方式?jīng)]有限制，只要它作為安全CDC路徑單獨(dú)報告即可。此外，您還負(fù)責(zé)約束從clk_a域到FF3的延時，這通常是通過set_max_delay -datapath_only約束完成的。

Mux-Controlled CDC

數(shù)據(jù)選擇器輸出的信號同步至clk_b 。

對于如何同步選擇信號沒有限制，只要它被單獨(dú)報告為安全。用戶負(fù)責(zé)約束在FF2_c上的傳遞延時。

Mux Data Hold CDC
數(shù)據(jù)選擇信號同步到clk_b，data_out反饋到數(shù)據(jù)選擇器。

總結(jié)

以上是生活随笔為你收集整理的【vivado UG学习】UG906学习笔记：对综合或实现后的结果进行逻辑分析的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。