麻雀雖小，五臟俱全。CPLD規(guī)模雖小，其原理和設(shè)計(jì)方法和FPGA確是一樣的。輕視在CPLD上的投入，就有可能存在設(shè)計(jì)隱患，導(dǎo)致客戶使用產(chǎn)品時出現(xiàn)故障，從而給公司帶來不可挽回的信譽(yù)損失。

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

問題代碼

圖 1. 問題代碼截圖

這段代碼的功能是統(tǒng)計(jì) 輸入信號’status_in’ 的高電平持續(xù)時間。CPU寫相應(yīng)的寄存器產(chǎn)生’clr_cnt’把”cnt”清零。同時,也會把”cnt”的值給回讀到CPU。實(shí)際上就是一個讀清操作。

很明顯，這里有一個問題，就是異步時鐘域處理的問題?！痗lr_cnt’的時鐘為’clk_sys’，而”cnt”的時鐘為’clk_io’， ‘clk_sys’和’clk_io’是異步的，沒有確定的相位關(guān)系。

測試方法

測試中，CPU循環(huán)執(zhí)行以下四步：

1. 清零: CPU通過Local Bus寫寄存器，產(chǎn)生’clr_cnt’脈沖，把”cnt”清零；
2. 計(jì)數(shù): CPU等待一段時間?！癱nt” 開始對外部輸入 ‘status_in’ 計(jì)數(shù)；
3. 回讀: CPU通過Local Bus讀取 ”cnt” 值；
4. 循環(huán): goto 1.

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

問題描述

如果’status_in’ 恒為低電平’0’輸入, 那么”cnt”應(yīng)該恒為零值?？墒牵蛻舭l(fā)現(xiàn)一個非常奇怪的現(xiàn)象。測試中，讓 ‘status_in’ 恒為低電平’0’輸入時，客戶發(fā)現(xiàn)CPU會低概率的回讀到非零的”cnt”值。朋友們，你們能解釋這種現(xiàn)象嗎？

初步分析

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

‘clr_cnt’在測試中是翻轉(zhuǎn)變化的?！痗lr_cnt’是從’clk_sys’時鐘域來的信號。而時鐘’clk_sys’和時鐘’clk_io’是異步關(guān)系，沒有固定的相位關(guān)系。也就是說’clr_cnt’是可能違反觸發(fā)器”cnt”的建立/保持時間要求的，進(jìn)而出現(xiàn)亞穩(wěn)態(tài)。

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

問題根因

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

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

圖2中調(diào)用了進(jìn)位鏈模塊，看起來很亂，整理一下, 手工簡化一下如圖3。

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

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

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

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

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

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

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

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

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

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

解決措施

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

1. 同步化

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

*** 圖6. 優(yōu)化過后的代碼***

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

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

2. 禁止CE

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

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

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

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