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

可以看到時(shí)序的建立時(shí)間不滿足。

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

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

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

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

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

接下來看具體的時(shí)序路徑：

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

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

再來看一下具體的路徑報(bào)告：

可以看到logic的延時(shí)占到了82%，因此如果要解決這個(gè)時(shí)序?yàn)槔?，就必須要把logic delay給降低。

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

來看一下這一個(gè)時(shí)序?yàn)槔龑?yīng)的代碼：

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

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

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

可以看到時(shí)序就收斂了。

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

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

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

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

審核編輯：湯梓紅