以下文章來源于西風念，作者zwliu

前幾天測試中心在對伺服電機控制板進行測試中，發(fā)現(xiàn)多次隨機點擊控制屏上控制指令時，會出現(xiàn)正常運行的電機突然就停了。在當前指令還沒有執(zhí)行完，并且確認沒有下發(fā)急停指令的情況下，正常轉(zhuǎn)著的電機突然就停了。

突然停機，，馬上要交付的機器突然暴露還有問題，慌得一批。明明之前都經(jīng)過長時間測試了的，不管了，趕緊查原因。

1、首先查復位信號，對系統(tǒng)發(fā)起復位重啟指令，能恢復，所以我一開始還以為是不是系統(tǒng)誤發(fā)了復位指令，于是繼續(xù)測試，讓現(xiàn)象復現(xiàn)，此時去查看復位信號寄存器，顯示復位信號是正常的;

2、該板子由于沒有引出jtag無法使用在線邏輯分析儀VLA看信號，當時為了方便排查設計問題，將很多關(guān)鍵信號引入到了寄存器，通過寄存器一路排查，發(fā)現(xiàn)問題出在fifo上。Fifo數(shù)據(jù)寫不進，前方發(fā)來的控制指令無法被后方的執(zhí)行端正確接收，也就是說控制指令傳達不下去，信號在這里中斷了。

下圖：fifo接收上位機過來的指令，指令數(shù)據(jù)緩存在同步fifo,下級模塊在fifo讀取相應的指令做執(zhí)行。

2、因為設計中對寫使能信號，寫數(shù)據(jù)，以及fifo數(shù)據(jù)量都做了監(jiān)測，寫使能是單周期脈沖信號，通過計數(shù)器對寫次數(shù)，以及寫數(shù)據(jù)都進行了累加，這些統(tǒng)計信號都放到了寄存器，于是直接把寄存器狀態(tài)值調(diào)出來看，發(fā)現(xiàn)寫次數(shù)一直在累加，寫數(shù)據(jù)也在變化，但是數(shù)據(jù)量卻一直保持為0，也就是這個FIFO在寫時鐘正常，寫數(shù)據(jù)正常的情況下，數(shù)據(jù)卻死活寫不進，讀不出數(shù)據(jù)，數(shù)據(jù)量保持為0不增加。

這種情況一開始確實一點違背我的認知邏輯了，我認為在寫信號正常的情況下，并且fifo數(shù)據(jù)量為0也就是fifo為空的情況下，寫不進數(shù)據(jù)，這很難理解。

于是去網(wǎng)上搜索，看看有沒有人出現(xiàn)過類似的現(xiàn)象，一搜還真有好幾篇文章提到這個問題，都說在工程中遇到了FIFO寫不進的問題，并且解決問題的過程費了很大的功夫，花了很長時間才定位到問題所在，比較典型的是明德?lián)P寫的這篇：

截圖如下：

限于篇幅，只截了一部分，如果有遇到了類似的問題可以搜索這篇文章看全篇，他們最后是查閱官方FIFO手冊，提示fifo的復位信號必須是和寫時鐘同步，也就是異步復位存在亞穩(wěn)態(tài)，會導致低概率的錯誤使FIFO無法工作，就是說不能使用異步復位。

于是把異步復位同步化，問題得到解決。

問題是他們的測試過程都是反復開機，這種情況可能發(fā)生在上電的時候，一上電由于復位信號異常沒有正確復位，是有可能導致系統(tǒng)不能正常工作。

可是我這里的情景并不相同，不是上電之初，而是工作中突然死機，感覺和復位信號關(guān)系不太大，但是我又沒有好的辦法，還是按同樣的方法對復位信號同步處理。測試結(jié)果還是會死機，也就是說確實和這個復位信號無關(guān)。

這下有點一籌莫展了。。。

思考良久，我在想是不是vivado的IP核還有哪里有需要注意又沒有注意到的方，但是黑盒子我又沒辦法查細節(jié)原因。于是索性不用官方提供的fifo，自己動手寫了個同步fifo，自己寫的fifo當然所有的細節(jié)原理自己是很清楚的，即使出現(xiàn)問題，也是很容易查的。

結(jié)果是把自己寫的同步fifo掛上去，電機還是照死不誤，只是這樣一來，我就清楚了應該不是fifo的用法問題了，應該是設計邏輯哪里還有隱藏的問題;

fifo是做過基礎的仿真的，邏輯是沒有大問題的。開始把寫的fifo拿出來仿照實際工作環(huán)境進行更細致地仿真，我們的使用條件是，上位機每隔一段時間發(fā)一次數(shù)據(jù)，比如10毫秒，FPGA把時間起點錯開，然后在FIFO后端邏輯每隔10毫秒取一次數(shù)據(jù)，并且這個間隔時間是相對很穩(wěn)定的。上位機和FPGA都做了嚴格的控制，確保5毫秒的精確度，上位機的5毫秒精度可能因為系統(tǒng)原因不能很準確，允許左右偏移1-8ms都可以，但是不能出現(xiàn)累計誤差。

Fifo的讀機制是自動根據(jù)數(shù)據(jù)量判斷非空，非空就立即啟動讀動作。

現(xiàn)在仿照實際環(huán)境進行測試，固定間隔寫，等間隔固定讀，可以看到同時開啟讀寫，數(shù)據(jù)量是保持0,1平衡的;

本來想錯開一點，提前寫入兩個數(shù)據(jù)，讓fifo數(shù)據(jù)量保持在2,3之間，結(jié)果手誤寫使能沒有拉低，一直在寫數(shù)據(jù)，直接把fifo干滿了。這下看到的情景令所有問題豁然開朗。

1、fifo滿了以后的數(shù)據(jù)個數(shù)不是最大值，而是溢出清零后變成最小值0;

2、之前以為fifo數(shù)據(jù)量等于0就以為fifo是空的，這里卻恰恰相反，fifo數(shù)據(jù)量為0的時候可能是fifo剛滿溢出了導致清零。

3、寫滿導致fifo一直寫不進數(shù)據(jù)，數(shù)據(jù)量保持為0;

4、數(shù)據(jù)量為0，導致系統(tǒng)認為fifo一直是空狀態(tài)，無法自動發(fā)起讀信號;

5、這次上位機控時測試機制有點問題，導致寫快于讀，原以為不會出現(xiàn)寫滿的情景，如果操作不當還是會出現(xiàn)寫滿，寫滿就會卡死停機。

于是很快確定原因，當前測試的上位機時間控制設置不夠嚴謹，導致雙方同步時間產(chǎn)生累計誤差，這個誤差累計長了就會把fifo填滿，而我們的設計本意是得有機制保證不會出現(xiàn)寫滿才行。這個后面把fifo深度加大，長時間測試后出現(xiàn)數(shù)據(jù)滯后的原因是一致的。

下面在vivado用官方的IP復現(xiàn)這一現(xiàn)象：

fifo深度設置為16，連續(xù)寫，發(fā)現(xiàn)數(shù)據(jù)寫入16個數(shù)后，full信號拉高，此時數(shù)據(jù)量并不是保持在f，而是會在此刻清零。最開始以為的數(shù)據(jù)量是0，做出fifo是空的判斷是錯誤的。

Fifo的用法是芯片/FPGA設計的基礎，早些年也寫過一系列的測試筆記只為全方位理解fifo的工作邏輯和用法，包括：

1、standard fifo模式和first fall-through模式的區(qū)別

2、fifo復位的機制，復位時間復位時長

3、讀寫信號自動關(guān)聯(lián)empty和full的關(guān)系

4、wr_rst_busy信號的使用邏輯

5、fifo用來打包傳輸控制信號和數(shù)據(jù)信號的方法

6、同步異步fifo數(shù)據(jù)量和Fifo模式以及讀寫信號之間的對齊關(guān)系

等等...

這些機制對于正確設計fifo邏輯，對于系統(tǒng)穩(wěn)定性都很重要，今天也算是發(fā)現(xiàn)一個以過去的經(jīng)驗可能會忽略導致出錯的地方，覺得還有點意思，于是整理分享出來。

很多時候我們的知識的獲取來源于網(wǎng)絡，來源于眾多網(wǎng)友的經(jīng)驗總結(jié)，時常懷著一顆感恩的心,也想著回饋于網(wǎng)絡，于是也會分享一些小經(jīng)驗，若能使人有益，也覺得挺有意思。

另外也是自己的一種學習手段，凡是問題，總是覺得凡是問題，能清晰地表達和總結(jié)出來就是真的理解了。

保持輸出就是持續(xù)學習的動力。

所以經(jīng)常和身邊的家長或小朋友說學習也是這樣的，只有用輸出倒逼輸入，二者構(gòu)成反饋閉環(huán)，學習才是有效的，才會學以致用正向促進。通過不斷地輸出和反思，我們可以不斷完善自己的知識結(jié)構(gòu)。