目錄

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

1 用IDE進行邏輯分析

1.3 Netlist窗口的使用

網表窗口展示了經過Synthesis工具綜合后的網表的層次結構。

根據綜合設置
網表層次結構可能與原始RTL 100%匹配，也可能沒有層次結構。
通常，Synthesis工具默認保留大部分用戶層次結構，同時優化邏輯。這將產生一個更小、更快的網表。

使用合成工具的默認值，網表層次結構是可以識別的，但是層次結構的接口可能會被修改。可能缺少一些引腳和層次結構級別。層次結構的每一層都顯示它的層次結構樹。在每一層，工具顯示：

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

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

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

1.4 Hierarchy窗口的使用

打開Hierarchy窗口： Tool-> Show Hierarchy 或者 在Netlist窗口按F6。
這個窗口是網表的層次結構圖，層次結構的每一層的大小都是相對于該層的實例數量與設計中的實例總數的比值。

1.5 利用率報告的使用

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

1.6 Schematic 窗口的使用

原理圖是網表的圖形化表示。原理圖可以：

• 網表的圖形表示。
• 檢閱邏輯門，層次結構以及連接。
• 查找以及展開邏輯體。
• 分析設計。
• 更好的理解內部設計。

1.9 DRC報告的使用

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

在設計流的早期檢查DRC消息、Critical Warnings和Warnings，以防止以后出現問題。

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

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

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

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

2 時序分析功能

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

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

實現后的而設計，Vivado基于實際的布線信息估計net延時，如果已經完成了布線則使用時序報告查看。

2.1 Report Timing Summary

2.1.1 Report Timing Summary對話框的設置

page1：

Report:

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

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

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

Path limits:

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

Path Display:

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

• Significant digits:
  控制報表中顯示數字的準確性。
  等效Tcl選項：-significant_digits

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

page2:

Report:

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

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

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

File Output:

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

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

Miscellaneous:

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

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

page3：

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

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

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

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

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

2.1.2 時序總結報告的詳情

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

節說明

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

Design Timing Summary Section

Setup Area (Max Delay Analysis)：

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

Hold Area (Min Delay Analysis)：

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

Pulse Width Area (Pin Switching Limits)：

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

Check Timing Section
可以通過Reports -> Timing -> Check Timing 或者 Tcl命令check_timing單獨產生。

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

時序檢查說明

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

2.1.3 報告Clock Networks

Tcl命令： report_clock_networks -name {network_1}

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

報告CDC(Clock Domain Crossings)會進行分析的結構：

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

2.8.3 跨時鐘域報告規則

CDC拓撲的原理圖表示

單bit同步器

ASYNC_REG屬性必須在同步鏈的至少前兩個觸發器上設置。同步器深度由鏈式觸發器的數量定義。

多bit同步器

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

異步復位同步器
基于CLEAR進行同步：

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

基于PRESET進行同步：

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

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

在同一目標時鐘域中涉及兩個FIFO生成器的安全復位同步示例：

組合邏輯
在clk_a到clk_b種的組合邏輯LUT3，實現clk_a到clk_b同步。

這種結構傳統上不推薦，因為組合邏輯的輸出可能會出現小故障，它會被同步器捕獲并向下傳播到設計的其余部分。

扇出
在下圖所示的簡化的Fanout示例中，源觸發器驅動一個網絡，該網絡在以紅色突出顯示的clk_b域中同步了三次。不建議使用這種結構，因為它會導致目標時鐘域的數據一致性問題，因為通過同步器的延時是有邊界的，但不是周期精確的。

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

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

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

Non-FD Primitive

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

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

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

Mux-Controlled CDC

數據選擇器輸出的信號同步至clk_b 。

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

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

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。