UltraFast設計法實踐(1) -- 初始設計檢查

---

平臺：Vivado16.4

芯片：xc7a200

《UltraFast Design Methodology Timing Closure Quick Reference Guide 》(UG1292)第一頁的主題是初始設計檢查，這一步是針對綜合後或者opt_design階段生成的dcp，該階段主要要讀懂三個操作生成的報告，這三個操作是：

1. report_failfast
2. report_timing_summary
3. report_methodology

1. report_failfast

1.1 命令使用

有的平臺一開始並不能直接使用report_failfast命令，需要安裝Xilinx Tcl Store，安裝方法見：幹掉Vivado幺蛾子（1）-- Xilinx Tcl Store。

在工程綜合完成之後，需要打開synthesized design（open synthesized design)，使用Tcl命令：xilinx::designutils::report_failfast ，會在Tcl Console窗口得到一張圖表，如下圖所示：

這張表反映的是工程對資源的使用情況，包括參考(推薦)比例、實際比例和狀態。當各項實際使用率都符合參考的話，工程進行後續的過程纔會相對可靠。我們尤其要關注狀態爲“REVIEW”的項，它表示超過的參考推薦值，可能存在風險。

我的報告中狀態爲“review”的有兩項：LUT Combining和Control Sets。

1.2 優化

1. 2.1 LUT Combining

先看LUT Combining，查閱《UltraFast Design Methodology Guide for the Vivado Design Suite》（UG949）中關於它的含義。文中對其的描述如下：

LUT combining reduces logic utilization by combining LUT pairs with shared inputs into single dual-output LUTs that use both O5 and O6 outputs. However, LUT combining can potentially increase congestion because it tends to increase the input/output connectivity for the slices. If LUT combining is high in the congested area (> 40%), you can try using a synthesis strategy that eliminates LUT combining to help alleviate congestion. The Flow_AlternateRoutability synthesis strategy and directive instructs the synthesis tool to not generate any additional LUT combining.

大意是有的LUT pairs共用一些LUT的輸入，從而把O5和O6都用上，然後導致線路擁堵。

隨後看到這樣一個tip:

意思是讓我執行report_qor_suggestions，試試看，反饋了一些結果，建議opt_design -remap，完成之後再report_failfast，結果反而惡化，但LUT使用減少，如下圖

隨後，UG949中建議嘗試方法：

• synthesis setting -- strategy -- Flow_AlternateRoutability

說可以採取修改綜合策略的方式來優化，將策略改爲Flow_AlternateRoutability可以減少LUT combining，從而可以優化擁堵的情況。改後綜合，report_failfast報告如下，LUT combining確實減少了，但LUT增加了，這是可以理解的，因爲LUT Combining就是複用一些LUT的結果，現在不復用了，所以LUT的使用率增加了。

1.2.2 control_sets

先不管LUT，因爲這個可以後期優化掉或者精簡代碼實現。現在只剩control_sets了，查UG949中對control_sets的描述，如下：

Often not much consideration is given to control signals such as resets or clock enables. Many designers start HDL coding with "if reset" statements without deciding whether the reset is needed or not. While all registers support resets and clock enables, their use can significantly affect the end implementation in terms of performance, utilization, and power.

大致理解是跟一些使能或者復位信號的不合理使用相關。使用report_control_sets -verbose 獲取control_sets的詳細情況，貌似是導致control_sets的一些設計，然後發現我的模塊中大量的跟以下這樣一個信號有關，而這個信號大量的作爲使能信號。

 assign w_divisor_valid = (mult_cnt == 6'd39);       // control set 過高可能有這個原因

這樣設計是有問題的，故改爲時序設計：

    always@(posedge clk or negedge rst_n) begin
        if(rst_n == 1'b0) begin
           w_divisor_valid <= 1'b0; 
        end
        else if(mult_cnt == 6'd38) begin
            w_divisor_valid <= 1'b1;
        end
        else begin
            w_divisor_valid <= 1'b0; 
        end
    end

之後，再綜合--report_failfast，滿足要求了！！

1.3.總結

report_failfast生成的項目報告，查看哪些項是REVIEW，然後針對每項內容是什麼含義，導致的可能原因，建議的優化方法等都可以從UG949中查看，不斷反覆嘗試，直至可以接受的結果爲止。

2.report_timing_summary

report_timing_summary可以生成時序報告，除了查看時序違例路徑之外，該報告還可顯示時序約束是否存在潛在問題。注意：此階段主要關注的是主要的時鐘約束有沒有加上？有沒有loop？ 即基本的時序設計有沒有問題，至於一些時序裕量不足的情況，個人認爲，此階段要完全解決是不太現實的。畢竟這是設計初期，想要解決所有問題是不可能的，後面還有很多優化過程要完成。

3. report_methodology

在有個工程的report_failfast報告中，有幾項有關TIMING的項報REVIEW，看不出哪個條線路或者環節出了問題，從UG949中並不能找到詳細的答案，這個時候就需要用到report_methodology。

執行該命令，主要檢查的是涉及到時鐘的RTL代碼設計，尤其需要關注Bad Practice，這就會詳細的風險問題出在哪個環節。

4. 總結

第一階段的初始設計檢查主要根據report_failfast報告的內容逐一優化REVIEW項，結合report_timing_summary和report_methodology 生成的報告，看看RTL和時序層面有沒有設計問題，反覆迭代，儘可能使三個報告“乾淨”。再次強調（當然是個人拙見），初期解決所謂時序問題是不太現實的，後面還有很長的優化過程，也許還有不斷反覆迭代，

5.遺留問題

• 實際上在report_failfast報告中有關TIMING的幾項，並沒有很好的理解其中的含義，換言之，爲什麼會出這些問題，時鐘之間到底存在哪些關係。

參考文獻：

1. UG949
2. UG1292
3. 深度解析ug1292（1）