麻雀雖小，五臟俱全。CPLD規模雖小，其原理和設計方法和FPGA確是一樣的。輕視在CPLD上的投入，就有可能存在設計隱患，導致客戶使用產品時出現故障，從而給公司帶來不可挽回的信譽損失。

近一段時間，我遇到了兩個CPLD設計故障，這兩個故障的根因(root cause)是一樣的。其中的一個故障發生在實驗室測試階段，另一個發生在運營商的網絡上，造成了非常不好的負面影響，因此引起了高度重視，必須徹底找出原因并消除。雖然可以很容易讓故障不復現，但是要想找到根因，并給相關人員解釋清楚, 卻并不是一件容易的事情。

問題代碼

圖 1. 問題代碼截圖

這段代碼的功能是統計 輸入信號’status_in’ 的高電平持續時間。CPU寫相應的寄存器產生’clr_cnt’把”cnt”清零。同時,也會把”cnt”的值給回讀到CPU。實際上就是一個讀清操作。

很明顯，這里有一個問題，就是異步時鐘域處理的問題。’clr_cnt’的時鐘為’clk_sys’，而”cnt”的時鐘為’clk_io’， ‘clk_sys’和’clk_io’是異步的，沒有確定的相位關系。

測試方法

測試中，CPU循環執行以下四步：

1. 清零: CPU通過Local Bus寫寄存器，產生’clr_cnt’脈沖，把”cnt”清零；
2. 計數: CPU等待一段時間。“cnt” 開始對外部輸入 ‘status_in’ 計數；
3. 回讀: CPU通過Local Bus讀取 ”cnt” 值；
4. 循環: goto 1.

實際實現可能略有不同，CPLD邏輯在執行清零1.的同時會把”cnt”的值鎖存下來,供CPU回讀，也就是1.和3.也可以是一個步驟。這樣表述是為了突出問題代碼。

問題描述

如果’status_in’ 恒為低電平’0’輸入, 那么”cnt”應該恒為零值。可是，客戶發現一個非常奇怪的現象。測試中，讓 ‘status_in’ 恒為低電平’0’輸入時，客戶發現CPU會低概率的回讀到非零的”cnt”值。朋友們，你們能解釋這種現象嗎？

初步分析

‘status_in’恒為零，不可能引起”cnt”變化。

‘clr_cnt’在測試中是翻轉變化的。’clr_cnt’是從’clk_sys’時鐘域來的信號。而時鐘’clk_sys’和時鐘’clk_io’是異步關系，沒有固定的相位關系。也就是說’clr_cnt’是可能違反觸發器”cnt”的建立/保持時間要求的，進而出現亞穩態。

但是有人認為, “cnt”的值原來是零，“clr_cnt”只是把”cnt”的值清零, 這樣來說觸發器“cnt”的輸入根本沒有發生過變化，怎么可能有亞穩態事件? 而且故障出現的概率很高，遠比亞穩態的概率高，好像也不能用亞穩態來解釋。

問題根因

解釋問題的真正原因，必須要知道 ”cnt” 對應的電路網表是什么樣的。”cnt”電路網表由綜合工具(synthesis)生成,可以在綜合工具中查看電路圖, 圖2是網表的局部放大。

*** 圖 2. “cnt”的Technology View電路***

圖2中調用了進位鏈模塊，看起來很亂，整理一下, 手工簡化一下如圖3。

圖 3. 手工簡化的“cnt”的電路圖

圖3中,可以看到，’clr_cnt’和’status_in’相或的結果控制觸發器的使能端(‘CE’)。另外，’clr_cnt’還決定了觸發器輸入(‘D’)是”cnt+1”還是”0”。真值表如下。

也許和你想象中的不一樣，電路使用了觸發器的兩個輸入端’D’和’CE’，而不是單單一個’D’端。于是，’clr_cnt’的跳變引起了’D’/’CE’的跳變。

為了說明問題方便，定義 ‘clr_cnt’ 跳變的時刻為t0，這個跳變事件傳播到觸發器’CE’端的時刻為t1, 傳播到觸發器’D’端的時刻為t2。見圖4。

圖4. “cnt”觸發器時序違反的演示

圖4中的場景， t2>t1>t0。 最初的時候，”cnt”的值為hex”0000”，”cnt+1”的值為hex”0001”。 由于’clk_io’的上升沿落在t1和t2之間， 因此”cnt”錯誤地跳變為hex”0001”。

一個布局布線后的設計，一般情況下CE的傳播延時(t1-t0)不會等于D的傳播延時(t2-t0)。由于’clk_io’和’clk_sys’之間的相位關系是隨機的, 肯定會出現’clk_io’的上升沿剛好位于t1和t2之間的情況。這種情況下，觸發器CNT[15:0]就會錯誤的采樣到”cnt+1”，而不是期望的hex”0000”值。

忽略次要參數和亞穩態事件，故障出現的概率可以被估算為 (t2-t1)/TCLK_IO 。(t2-t1)越大，故障概率越高。這就是為什么故障出現的概率這么高的原因。

對于t2=t1的情況(應該沒有可能)，只有當’clk_io’采樣到’D’/’CE’的邊沿附近時，引起亞穩態事件，CNT才會出錯，當然這種故障的概率會低的多。

*** 圖5. “cnt”觸發器的后仿真時序違反演示***

解決措施

通過以上的分析，問題是由于信號跨異步時鐘域而產生了模糊的時序關系，布局布線工具無法也不可能分析出這種時序要求，只能從代碼上加以處理。

1. 同步化

一個很成熟的異步信號同步化方法就是多拍處理。見圖6。

*** 圖6. 優化過后的代碼***

‘clr_cnt’經過同步化后，’clr_cnt_sync’會在’clk_io’上升沿之后很短的時間內穩定下來。布局布線工具通過利用’clk_io’的時鐘周期，去約束’clr_cnt_sync’到’D’和’CE’的路徑。從而不會出現”cnt”非零的錯誤。

如果’status_in’也是異步的信號，原理是一樣的，會引起計數的不準確，只是故障更隱蔽，同樣需要同步化。如果’status_in’是同步的引腳輸入，必須通過時序約束告知布局布線工具，’status_in’相對于’clk_io’的建立時間和保持時間。

2. 禁止CE

有人提出過一種偽方案，我們來討論一下。就是約束綜合工具,禁止使用觸發器的’CE’功能。這樣，觸發器只有D端口, 且D = ( clr_cnt ) ? “0000” : ( status_in ) ? cnt+1 : cnt 。

當’status_in’==0且”cnt”=”0000”時，D = ( clr_cnt ) ? “0000” : cnt = ”0000”，此時，’clr_cnt’的跳變不會引起D端口上出現跳變，也就不會出現錯誤的采樣。

這樣做局限性很大，首先限制了”cnt”=”0000”的狀態才適用， 如果”cnt”的當前狀態非零，一樣會有問題，只是錯誤會更隱蔽。再者，使用CE端口可以降低邏輯級數，改善時序，節省面積，實際上可能的情況下應該盡量使用。

因此禁止CE的手段是不能作為解決措施的。