一個亞穩(wěn)態(tài)設計案例分析

一個亞穩(wěn)態(tài)設計案例分析麻雀雖小，五臟俱全。CPLD規(guī)模雖小，其原理和設計方法和FPGA確是一樣的。輕視在CPLD上的投入，就有可能存在設計隱患，導致客戶使用產品時出現(xiàn)故障，從而給公司帶來不可挽回的信譽損失。近一段時間，我遇到了兩個CPLD設計故障，這兩個故障的根因(rootcause)是一樣的。其中的一個故障發(fā)生在實驗室測試階段，另一個發(fā)生在運營商的網絡上，造成了非常不好的負面影響，因此引起了高度重視，必須徹底找出原因并消除。雖然可以很容易讓故障不復現(xiàn)，但是要想找到根因，并給相關人員解釋清楚,卻并不是一件容易的事情。問題代碼圖1.問題代碼截圖這段代碼的功能是統(tǒng)計輸入信號’status_in’的高電平持續(xù)時間。CPU寫相應的寄存器產生’clr_cnt’把”cnt”清零。同時,也會把”cnt”的值給回讀到CPU。實際上就是一個讀清操作。很明顯，這里有一個問題，就是異步時鐘域處理的問題。’clr_cnt’的時鐘為’clk_sys’，而”cnt”的時鐘為’clk_io’，‘clk_sys’和’clk_io’是異步的，沒有確定的相位關系。測試方法測試中，CPU循環(huán)執(zhí)行以下四步：清零:CPU通過LocalBus寫寄存器，產生’clr_cnt’脈沖，把”cnt”清零；計數(shù):CPU等待一段時間?！癱nt”開始對外部輸入‘status_in’計數(shù)；回讀:CPU通過LocalBus讀取”cnt”值；循環(huán):goto1.實際實現(xiàn)可能略有不同，CPLD邏輯在執(zhí)行清零1.的同時會把”cnt”的值鎖存下來,供CPU回讀，也就是1.和3.也可以是一個步驟。這樣表述是為了突出問題代碼。問題描述如果’status_in’恒為低電平’0’輸入,那么”cnt”應該恒為零值?？墒牵蛻舭l(fā)現(xiàn)一個非常奇怪的現(xiàn)象。測試中，讓‘status_in’恒為低電平’0’輸入時，客戶發(fā)現(xiàn)CPU會低概率的回讀到非零的”cnt”值。朋友們，你們能解釋這種現(xiàn)象嗎？初步分析‘status_in’恒為零，不可能引起”cnt”變化?！甤lr_cnt’在測試中是翻轉變化的?！痗lr_cnt’是從’clk_sys’時鐘域來的信號。而時鐘’clk_sys’和時鐘’clk_io’是異步關系，沒有固定的相位關系。也就是說’clr_cnt’是可能違反觸發(fā)器”cnt”的建立/保持時間要求的，進而出現(xiàn)亞穩(wěn)態(tài)。但是有人認為,“cnt”的值原來是零，“clr_cnt”只是把”cnt”的值清零,這樣來說觸發(fā)器“cnt”的輸入根本沒有發(fā)生過變化，怎么可能有亞穩(wěn)態(tài)事件?而且故障出現(xiàn)的概率很高，遠比亞穩(wěn)態(tài)的概率高，好像也不能用亞穩(wěn)態(tài)來解釋。問題根因解釋問題的真正原因，必須要知道”cnt”對應的電路網表是什么樣的?！眂nt”電路網表由綜合工具(synthesis)生成,可以在綜合工具中查看電路圖,圖2是網表的局部放大。***圖2.“cnt”的TechnologyView電路***圖2中調用了進位鏈模塊，看起來很亂，整理一下,手工簡化一下如圖3。圖3.手工簡化的“cnt”的電路圖圖3中,可以看到，’clr_cnt’和’status_in’相或的結果控制觸發(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”。一個布局布線后的設計，一般情況下CE的傳播延時(t1-t0)不會等于D的傳播延時(t2-t0)。由于’clk_io’和’clk_sys’之間的相位關系是隨機的,肯定會出現(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的情況(應該沒有可能)，只有當’clk_io’采樣到’D’/’CE’的邊沿附近時，引起亞穩(wěn)態(tài)事件，CNT才會出錯，當然這種故障的概率會低的多。***圖5.“cnt”觸發(fā)器的后仿真時序違反演示***解決措施通過以上的分析，問題是由于信號跨異步時鐘域而產生了模糊的時序關系，布局布線工具無法也不可能分析出這種時序要求，只能從代碼上加以處理。同步化一個很成熟的異步信號同步化方法就是多拍處理。見圖6。***圖6.優(yōu)化過后的代碼***‘clr_cnt’經過同步化后，’clr_cnt_sync’會在’clk_io’上升沿之后很短的時間內穩(wěn)定下來。布局布線工具通過利用’clk_io’的時鐘周期，去約束’clr_cnt_sync’到’D’和’CE’的路徑。從而不會出現(xiàn)”cnt”非零的錯誤。如果’status_in’也是異步的信號，原理是一樣的，會引起計數(shù)的不準確，只是故障更隱蔽，同樣需要同步化。如果’status_in’是同步的引腳輸入，必須通過時序約束告知布局布線工具，’status_in’相對于’clk_io’的建立時間和保持時間。禁止CE有人提出過一種偽方案，我們來討論一下。就是約束綜合工具,禁止使用觸發(fā)器的’CE’功能。這樣，觸發(fā)器只有D端口,且D=(clr_cnt)?“0000”:(status_in)?cnt+1:cnt。當’status_in’==0且”cnt”=”0000”時，D=(clr_cnt)?“0000”:cnt=”0000”，此時，’clr_cnt’的跳變不會引起D端口上出現(xiàn)跳變，也就