1. 程式人生 > >FPGA時序約束——實踐篇

FPGA時序約束——實踐篇

距離上一篇有關時序的理論篇已經有一段時間了(可以參考博文FPGA時序約束——理論篇),實際上此段時間,甚至到今天對FPGA的時序一直還是處於一種“朦朧”的狀態,經歷了一個階段的學習和專案時間,稍微有點感觸,故藉此總結一下。

1. 理論回顧

先來回顧一下有關時序的理論知識,上圖是典型的同步時序模型及其時序圖,由發起暫存器(rega)、組合邏輯、捕獲暫存器(regb)及其中間的走線組成。

源時鐘clk到達rega的時鐘埠時,會有一定的延遲,從而形成clka。同理,時鐘延遲到達regb的時鐘埠,形成clkb。Tco為有效資料出現在發起暫存器Q埠所需時間。Tdata為資料延遲,包括組合邏輯延遲和走線延遲。Tsu表示捕獲暫存器建立時間要求。Th表示捕獲暫存器保持時間要求。其中Tco、Tsu和Th是由FPGA的晶片工藝決定的。所以,我們所謂的時序約束,實際上就是對時鐘延遲和Tdata做一定的要求或者干預,其中Tdata由組合邏輯(程式碼)及佈局佈線決定,這也決定了系統最高的工作頻率。

2. 時間裕量

時間裕量包括建立時間裕量和保持時間裕量(上圖中的setup slack和hold slack)。從字面上理解,所謂“裕量”即富餘的、多出的。什麼意思呢?即保持最低要求的建立時間或保持時間所多出的時間,那麼“裕量”越多是不是就意味著時序約束越寬鬆呢?應該是這樣的。

通俗的講,一個FPGA工程在綜合實現後,是否滿足時序約束,其實就是看所有的捕獲暫存器是否能正確穩定捕獲到發起暫存器發出的資料。如上圖所示,也就是說到達捕獲暫存器的資料輸入埠D(regb/D)的資料要滿足建立和保持時間要求,也就是說在Tsu之前,current data valid就要準備就緒,而在Th之後呢,current data valid還要多維持一段時間。換言之,在Tsu之前以及Th之後多出的這部分時間,我們就稱之為“裕量”,裕量越大,時序越寬鬆。裕量的大小與時鐘頻率、程式碼設計以及佈局佈線有著緊密的聯絡

。一個設計的時序報告中,裕量為負數時,表示時序約束出現違例,雖然個別違例不代表你的工程就有致命的問題,但是這是一個風險(時序報告是按照工藝、電壓以及溫度的上下限給出的結果)。當違例數較多,也就意味著設計在實際環境中出現問題的概率也會越大。

3. 最大延遲和最小延遲

如下圖所示,“資料有效視窗”表示捕獲的資料滿足建立時間和保持時間,在此視窗中要捕獲的資料不能發生變化,否則將引起不穩定的結果。

我們來看1、2、3三種情況,在分析之前,首先要明確Data的持續時間長度一定是一個時鐘週期(多週期打拍另說)。1:當延遲時間大於T-Tsu時,Data在建立時間區域內才到達regb,所以不滿足建立時間要求,這就是說資料來的“太晚了”;2:當Data延遲了很小一段時間(<Th),Data在保持時間內就變化了,所以不滿足保持時間,這就是說資料來的“太早了”。3:當Data延遲了Th,Data則滿足建立時間要求又剛好滿足保持時間要求,這就是說資料來的“正巧”。

綜上所述,資料的最大延遲是T-Tsu,最小延遲是Th。一看是看到這兒有點納悶,最大延遲我們還能理解,延遲太大,捕獲不到資料,這是理所當然。延遲還有下限是什麼意思?仔細看看文章開頭的時序模型和時序圖,實際生成的電路圖之後,除了要滿足Th的要求外,資料路徑和捕獲時鐘路徑肯定不太可能一定擁有相同的延遲,舉個極端的例子,如果clkb延遲非常大,那麼current data valid必須增加延遲才能保證被clkb捕獲到。

一般而言,在綜合之後,我們需要特別關注的是建立時間的時序違例,因為可以通過增加布線長度來保證保持時間。大多數保持時間違例在實現之後自然會被優化掉。

4. 案例分析

以下是在實際工程(VIVADO平臺)中的時序分析結果:

如上圖所示,綜合後給出的時序報告,可以看到ADC的時鐘出現了hold時序違例,clk_out1_1出現了setup違例。然後進行實現,實現完成後hold違例消失(正如上面所述,保持時間往往可以修改佈線長度來保證),如下圖所示為實現後的結果,目前只存在3條路徑出現setup違例,即建立時間裕量為負。

以path201為例:選中path201,按F4(或右鍵schematic),開啟路徑的原理圖,如下圖所示,可以看到該路徑經歷多個模組,時序路徑較長。

雙擊path201,會顯示該路徑的具體資訊,點選slack可以彈出相應的需求時間和實際的到達時間,可以清晰的看到實際到達時間是長於需求時間的,所以出現時序違例的情況。

詳細的原時鐘時序、資料路徑時序、目標時鐘時序的各延遲資料如下圖所示。值得注意的是資料路徑資訊,其中包括Tco延遲和佈線延遲,各級累加之後得到總的延遲時間。通過觀察各中間過程,分析其中延遲較大的環節,可以做相應的優化約束或程式碼有效。

一般而已,少量的時序違例(如本工程,只有3條路徑違例),是可以通過實現策略(strategy)的修改達到要求。如果時序違例較嚴重,那麼就需要詳細的分析各時鐘之間的關係(同步or非同步)、是否分析該路徑等各方面進行深刻的分析,然後修改時序約束檔案,更嚴重的可能要手動佈局及修改佈線,我對這方面還理解的不是很透,所以等弄明白了再總結。

參考文獻:

1.《VIVADO從此開始》——高亞軍著(強烈推薦此書!!!!)