Q1

背景：

軟件 vivado2018.2

開發板 KC705

設計中涉及到兩個時鐘域（外部提供的238MHz時鐘和200MHz板上時鐘）

問題：

布局布線后的時序分析結果顯示：intra-clock path的setup時序違例，查看具體路徑的時序信息，發現數據路徑上有一個net延時高達8.6ns導致了時序違例。然后在device中看到這個net布線繞路了，看起來是擁塞所致，可是查看擁塞報告又顯示擁塞度很小。

而且第一幅圖中的幾個setup違例，幾乎都包含了這個net，所以是集體違例了。

下圖是這條net所在的電路，做好標記后，在device中查看具體布線情況。

下圖是device視圖，可見FDCE和LUT3挨得很近，但是他們之間的走線卻繞了很遠！上網查過，說可能是擁塞的原因。

于是查看了布局布線后的擁塞報告以及復雜度報告。。

看起來擁塞程度和復雜度程序都不算大，為什么net繞線很嚴重呢？

為了解決這個問題，我做了兩個嘗試：

1）將synthesis中的“no_lc*”選項勾選，取消LUT合并。

2）將implementation中的策略設置為congestion_spreadlogic_high。

但是這樣做之后setup時序依舊違例。

所以具體是什么問題導致的呢？

時序分析結果中，還有好幾項與上述信號同module的跨時鐘域的setup違例，有沒可能是因為沒有將這些跨時鐘域路徑set false path的原因呢？

A1

你提到的時序有問題的路徑本身沒有問題，主要原因是你沒有對異步跨時鐘路徑作有效的隔離。一旦去掉這些異步跨時鐘路徑的分析，之前提到的路徑就會正常布線了. （在邏輯上需要保障這些路徑上數據傳遞的正確性：握手信號或者是異步FIFO）

最后一條路徑是PLL時鐘直接連接寄存器D端導致的，全局時鐘信號一般只連Cell 的C/CLK 端. 能否通過代碼修改掉這種結構?

主時鐘建立的對象要盡量是端口，而不是pll的輸入 pin腳

Ex: 時鐘 clk_wiz_119MHz_inst/inst/clk_in1 (對象應該是get_ports clk_ab_p )

Q2

是不是因為沒有隔離時鐘，所以系統占用了大量的布線資源去盡量滿足這些跨時鐘的setup和hold，導致有些net只能繞路了呢？

A2

是的，Vivado是timing driven的工具，意味著會盡力對slack最差的路徑做修復，浪費了大量資源以及runtime. 其他net或者繞路，或者已經提前放棄，不作努力了.

Q3

如果隔離了時鐘，那么布局布線工具對待跨時鐘域的信號是不是就直接布線（比如走最近的路線），完全不去考慮setup和hold這些是否滿足條件了？

A3

是的，如果加了忽略時鐘的約束，那么布局布線工具對待跨時鐘域的信號就直接布線，完全不去考慮setup和hold要求，因為根本沒有這些要求.

同時請注意之前提到的一點：在邏輯上需要保障這些異步時鐘域路徑上數據傳遞的正確性：考慮握手信號或者是異步FIFO

Q4

上面提到的“主時鐘建立的對象盡量是pin腳，而不是pll的端口”，這句話是什么意思？是在寫xdc文件的時候，盡量用get port做時鐘約束的意思？

是不是意味著上面的set_clcok_group語句改成這樣更合適：

set_clock_groups -asynchronous -name my_ASYNC -group {get_ports adc_clk_p} -group {get_clocks mmcm_clkout1}

A4

這里是指create_clock 約束中的對象是FPGA的PORT，而不是用Cell(如PLL的Pin).

Ex：正確的寫法：

create_clock -name clk -period 10.000 [get_ports adc_clk_p]

不推薦的寫法：

create_clock -name clk -period 10.000 [get_pins clk_wiz_119MHz_inst/inst/plle2_adv_inst/CLKIN1]

在set_clock_groups中這么用get_ports adc_clk_p是不對的， 可以寫成 [get_clocks -of [get_ports adc_clk_p]]

責任編輯：haq