[轉]TimeQuest之delay_fall clock_fall傻傻分不清楚

這篇我想分享一個以前在用TimeQuest約束雙邊沿模塊的input delay時犯得一個錯誤，有人看了可能會以爲傻傻的，什麼眼神，falling delay和 falling clk怎麼會分不清呢，字面意思好區分，可要深究在約束裏的具體含義，還得花點功夫，下面以ddio接收模塊爲例說明它們的含義以及碰到的一些問題。

ddio接收模塊爲雙邊沿工做模式，如圖一所示，ddio_in接入DFFH和DFFL，時鐘降低沿DFFL鎖存DL，但不馬上輸出，直到時鐘上升沿高電平使能latch時輸出，同時DFFH在上升沿鎖存輸出DH，和DL拼接成輸出數據，這樣就實現了對雙邊沿輸入數據的採樣輸出。

圖一

其時序特性是，上升沿發送的數據降低沿採樣，降低沿發送的上升沿採樣，工做波形如圖二所示，須要施加約束才能正確的雙邊沿採樣。

圖二

首先用create_clock建立輸入時鐘頻率爲100MHz的ddio_clk_s，而後用set input delay關聯輸入數據ddio_in和輸入時鐘ddio_clk_s，設置延遲爲2ns，查看IO Timing，發現TimeQuest分析了兩條路徑如圖三所示，一條是上升沿到降低沿，這是咱們想要的，另外一條是上升沿到上升沿，這不是咱們須要的，並且尚未降低沿到上升沿的路徑，看來這種簡單的約束方式明顯存在問題。

圖三

set input delay默認是基於時鐘上升沿設置，TimeQuest不清楚用戶的真實使用狀況：上升沿發出的ddio_in數據究竟是被DFFH採樣仍是被DFFL採樣呢，因此默認源端上升沿發出的數據會同時被這兩個D觸發器採樣，這就出現了上述rise to fall和rise to rise兩條路徑，第二條無關路徑設置爲僞路徑後能夠被去除。

降低沿到上升沿的路徑如何設置呢？ 打開set input delay看看可否找到一些新的線索。

圖四

如圖四，首先映入我眼簾就是醒目的rise和fall的選項，既然set input delay默認是基於rise上升沿的，那勾選fall，應該就是基於降低沿了吧，這是我當時的第一反應。但是分析結果裏仍是沒有降低沿到上升沿的路徑，又注意到這個fall選項是被劃在input delay options裏，按理fall應該是用來修辭input delay的，可是怎麼個修辭法，當時並無細究，出於對曾今過了英語六級的那份自信，我仍然認爲，fall表示數據是基於時鐘降低沿輸入的。當時也查了些前輩的博客，其中特權同窗很早以前的一篇 深刻剖析I/O 裏也有對fall和rise的翻譯如圖五：

圖五

特權同窗認爲fall是時鐘的降低沿延時，可是fall是用來修辭input delay的而不是clock，因此我並不承認這種翻譯，此時我注意到表格裏還有一個參數是-clock_fall，這個好像和我想找的意思相符，爲了驗證參數的具體含義，又繼續搜索找到了altera關於set input delay的中參數的官方解釋以下：

-clock_fall     Specifies that input delay is relative to the falling edge of the clock
-fall               Specifies the falling input delay at the port

此時我才大悟，-clock_fall纔是我一直尋找的，它纔是基於時鐘降低沿的意思。勾選using falling clock edge後，降低沿到上升沿的路徑終於千呼萬喚始出來，不過同前述，也會多一條降低沿到降低沿到的路徑，用僞路徑能夠輕鬆去之。

雙邊沿約束的問題解決了，但是官方對fall的解釋 the falling input delay 是神馬意思呢？都是四級的詞彙，湊在一塊兒，就不是很明瞭了，數據降低延遲？聽起來總感受怪彆扭的，跑去和同事一塊兒討論這個問題。一組輸入數據變化時，哪有上升和降低之說？(數據從0010變爲1001，你說是上升仍是降低呢?)，上升降低應該是針對某一根數據線的變化而言的(數據從0010變爲1001，你能夠說第0位上升了，第1位降低了)，可是TimeQuest真的想知道你每根數據線的上升降低延遲嗎？no no no，回想下set input delay的本質是告訴Timequest最大輸入延遲讓其約束創建時間，和最小延遲約束保持時間，TimeQuest只想知道輸入的最大最小延遲就能夠了。源端發送數據的每一位的上升延遲和降低延遲可能會不同，也有一個大小之分，好比第0位上升延遲爲0.4ns，降低延遲爲0.8ns，第1位的上升延遲爲0.5ns，降低延遲爲0.9ns，TimeQuest會用其中相對較大的0.9ns去分析創建時間，相對小的0.4ns去分析保持時間，而不會去關心數據具體某位是如何變化的。既然TimeQuest只關心延遲的大小，那隻要在set input delay裏設置max min delay不就能夠了嗎，何須設置rise和fall呢？

測試後發現，若是不設置rise和fall，會致使約束不精準。舉個例子：源端發出數據的輸入上升延遲Tdelay_rise爲0.5ns，降低延遲爲Tdelay_fall爲0.8ns，路徑最大延遲爲2ns，最小延遲爲1ns，只設置set input delay的 max delay爲2.8ns，min delay 爲1.5ns，其中ddio_in[1]的路徑延遲報告如圖六所示。

圖六

注意紅色線標記，data path爲2.129ns。

若是加上rise 和fall選項，設置 max  fall 爲2.8ns，max rise 爲2.5ns，min fall 爲1.8ns，min rise 爲1.5ns，ddio_in[1]的延遲報告如圖七所示。

圖七

看紅色線標記處，data path爲1.998ns，比前者少了0.131ns，這兩種約束的最大和最小延遲相同，但結果卻不一樣，緣由在於FPGA的內部邏輯針對輸入數據的上升Trise和降低Tfall的延遲也是不同的，假設Trise > Tfall，第一種約束方式的最大路徑延遲是Trise + 2.8+ Tother，第二種方式指定了fall和rise後，TimeQuset知道了指定的最大輸入延遲發生在數據降低時刻，因此分析的總體最大路徑延遲會變爲Tfall + 2.8 + Tother，這種約束方式更符合實際的應用，也更加精確。雖然兩種約束方式的結果相差甚微，不會對普通應用形成影響，但對一些高速苛刻的應用，可就不能小視了。

set output delay同樣也有rise  和 fall的選項，和set input delay做用相似，這裏就再也不復述了。