在之前的文章里面介紹了Canny算法的原理和基于Python的參考模型，之后呢在FPGA上完成了Canny算法的實現(xiàn)，可是遇到了時序不收斂的問題，記錄一下。

可以看到時序的建立時間不滿足。

我們在約束的主時鐘頻率是200MHz，也就是5ns，但是建立時間是-2.12ns，也就是說這個工程只能跑到7.12ns也就是140.45MHz，遠(yuǎn)遠(yuǎn)不能滿足我們預(yù)先的設(shè)計。

在之前文章里面介紹過怎么在SpinalHDL里面估計一個模塊可以跑到的最大頻率，可以參見：SpinalHDL--快速評估代碼性能

怎么根據(jù)時序約束和建立保持時間裕量來分析工程能跑到的最大頻率可以參考下面：

首先來看一下PR之后是哪條路徑不收斂，究竟是同一時鐘域下的還是跨時鐘域的路徑，兩者的處理方式不一樣。

可以看到是Intra-clock paths爆紅了，也就是同一時鐘域下的路徑時序不收斂。

接下來看具體的時序路徑：

可以看到logic delay遠(yuǎn)遠(yuǎn)比net delay大，那么我們就需要去降低logic delay，也就是要把我們的組合邏輯搞簡單一點。如果是net delay比較大就要考慮是不是布線擁塞的問題了，兩者的處理方式不太一樣。

再來看一下它的電路圖，可以看到在左邊的寄存器輸出之后經(jīng)過LUT，Carry等組合邏輯之后，給到DSP的輸入端。一般來說DSP的幾級pipline最好的都用上，這樣DSP可以跑到更高的頻率。

再來看一下具體的路徑報告：

可以看到logic的延時占到了82%，因此如果要解決這個時序為例，就必須要把logic delay給降低。

兩者的比例可以參考，七系列的FPGA和UltraScale系列的FPGA不太一樣：

來看一下這一個時序為例對應(yīng)的代碼：

可以看到其實挺復(fù)雜的，有減法，有乘法。其中減法是被vivado用LUT+Carry搭了起來，乘法用的DSP。

要解決這個問題，就是把這一大段代碼進(jìn)行流水拆開嘛，把減法拆一級流水，乘法器拆為三級流水。

將代碼修改為以下的樣子，再來綜合一下

可以看到時序就收斂了。

再來看一下生成電路結(jié)構(gòu)：

可以看到FDCE之后仍然是LUT+Carry的形式，用于做減法運(yùn)算，然后再接入DSP的輸入，在源碼里面做完減法之后還有這兩級寄存器，但是在電路圖里面看不到他們了，這是因為這兩級寄存器被DSP給吸收掉了，用于提高DSP的時鐘頻率，這兩級寄存器會利用DSP單元內(nèi)部的寄存器來實現(xiàn)，并不會增加我們的資源占用，DSP核里面的資源不用也是浪費。

上圖為DSP單元里面的寄存器排布，可以看到有六級。

本篇介紹了一次時序調(diào)優(yōu)的過程，就是重新計算流水線，看看哪里是時序瓶頸。這種重新計算流水線的方式代價還是比較大的，需要重新修改代碼，所以在設(shè)計初期就應(yīng)該考慮到這個問題，比如DSP的流水線寄存器，BRAM的輸出寄存器這些在設(shè)計初期就考慮使用到它們，來獲取更好的時序。

審核編輯：湯梓紅