2010-09-16 84 views
3

我正在尋找一種內存測試算法,這將有助於我的團隊在生產過程中驗證設計和測試(壞焊接,交叉連接的地址/數據線,不匹配的阻抗,鏡像等)。3月內存測試算法的實現

我讀過例如3月C或類似的是我們祈禱的答案,但我還沒有找到一個這樣的算法的實現,我們可以借。

+1

詳細僞這裏:http://www.datasheetarchive.com/Indexer/Datasheet-075/DSAE004445.html – 2010-09-16 18:50:05

+0

@belisarius:這正是我所需要的,它的寫作和組織很好。不幸的是,許可協議中規定「僅用於MicrochipdsPIC®」,所以它不能與我的i.MX25合法使用... – 2010-09-16 19:47:16

+0

對不起。沒有檢查:( – 2010-09-16 22:08:47

回答

9

我一直在測試板超過20年,今晚是第一次聽到這個3月測試或算法。看着它,讓我感到困惑的是,看到一個名字適用於常識,就好像這個人或小組發明了常識一樣。

無論如何,想想你說你想測試的東西。理想的電路板級測試是測試焊料和印刷電路板,製造項目,而不是設計驗證,而不是芯片驗證。該芯片應該由供應商進行測試,並且理想情況下您只需要做一個快速功能。對於存儲器來說,雖然無論如何測試每個位單元是很常見的,但是時間允許,sram你可能有時間,進入千兆字節的dram,並且如果你嘗試測試每個位,則每個電路板需要幾個小時到幾天的時間。

所以你想擺動每個引腳的理想,基本的功能測試,如用所有的0xFFF ...填充所有地址,填充零,用0x5填充0xAs填充。 0x6s和0x9s以及0xC和0x3s,如果你這麼傾向。棋盤格,再次用這些交替圖案填充每個其他地址的0x5s和其他所有與0xAs等,然後串擾行走的人和步行零。 0x00..001,0x00 ... 002,0x00 ... 004等,然後0xff..ffe,0xff..ffd等

這是一切都很好,但假設你有工作地址位。如果說所有的地址線都被破壞了,大部分上述測試都會通過。如果只有最不重要的地址位工作,那麼所有上述測試都會通過,並且取決於存儲器的大小以及如何驅動可能浪費幾個小時的測試。

你需要知道的另一件事是你的數據總線的大小。如果這是一個32位處理器,但是使用16位數據總線,並且您正在進行32位步進測試,則您花費了兩次太多時間,只需要走16位而不是32位。或者,64位數據總線32位處理器(例如,72位內存的平均32位桌面),您尚未涵蓋所有友好的位組合。如果你所做的只是內存總線寬度的一半或四分之一,寬存儲器接口可能無法使用所有的數據線。

一個常見的快速地址測試是用其地址填充內存。你必須在每個地址位置放置一個獨特的模式。

以上內容涵蓋了大部分明顯,不良的焊料,提升的針,浮球問題。 (很多人會明顯地將這些三月測試標記出來)如果內存引腳分支支持不同大小的內存,你可能沒有達到所有的地址位,但是你沒有辦法做到這一點,這可能沒有關係,因爲把最大內存可能涉及焊料,這意味着無論如何都會重新測試電路板。

上面有很多測試,如果您在每個位置編寫並運行它們中的每一個,則可能需要一段時間。假設目標是製造測試,而不是在芯片測試中,一種簡單的方法是使用素數跳過地址。而不是每個內存位置都使用每257個內存位置,並讓您的測試更快完成。除2之外的素數通常會擺動每個地址位。對於步行測試,你只需要測試一個內存位置而不是整個內存,這可以加快速度。棋盤,兩個位置(目標是檢查數據總線上的狀態變化)。

這些低速測試不會覆蓋阻抗,但這是一個棘手的問題。如果可以的話,需要在存儲器總線速度上上下旋鈕,並創建非常低的水平,理想的手動組裝測試,以最大速度推動存儲器總線,只要你能站立,每個時鐘週期都進行讀或寫操作它。如果你的處理器或者處理器中的外設(dma等)不能支持這些速率,那麼無論芯片中最快的事情是什麼......以及最快的你可以去,你需要讓這件事做最長的運行它可以做的最快的爆發。這不一定會覆蓋阻抗,如果不在每個電路板的每個軌跡上放置一個示波器,您可能無法完全測試阻抗。快速發展可能會發現一些更明顯的阻抗問題以及大容量電容等問題。全1到全0的棋盤可以幫助地面反彈和大容量電容。

另外請注意,進行緩慢是非常重要的。高速和高容量測試不包括電路板上的噪聲,電路板或設計不良,並且可以輕鬆通過所有內存測試。您可能想要進行一些特意慢的測試,例如允許寫入閃爍信號,如果您對附近的痕跡執行測試,但對內存痕跡執行測試則更好。填充內存,稍等一會,再讀一遍,看看是否有一些寫入隱藏了。你提到了sram,對於dram來說,慢速測試對於確保刷新正在工作很重要,或許填充了獨特的模式,稍等片刻,回讀一下,用獨特模式的倒數來填充每一位,稍等片刻,回讀一遍。

我大部分時間都放棄了大部分上述測試,並從僞隨機測試中獲得了很多里程。使用一個LFSR創建比我想測試的內存位置數量更多的唯一數字,例如,這個16位的數字應該在重複之前產生兩個到16的電源減去兩個唯一的數字。減二是因爲lfsr不會操作或生成全部爲1或全爲零的數字,請記住這一點。

 
unsigned int fastprand16 (unsigned int prand) 
{ 
    // 16 bit lfsr bits 16,14,13,11 
    if(prand&1) 
    { 
     prand>>=1; 
     prand^=0x0000B400; 
    } 
    else 
    { 
     prand>>=1; 
    } 
    return(prand&0x0000FFFF); 
} 

維基百科已鏈接lfsr位單元抽頭表,在重複各種移位器長度之前產生最大數量的模式。上面的工作但有點無聊,你想要翻轉更多的數據位,而不僅僅是移動它們。

使用自己的隨機數發生器比使用庫中的發生器要好。該庫從計算機到計算機,從操作系統到編譯器到編譯器的操作系統,以及同一系統上的操作系統或編譯器的版本。即使主系統驅動,測試也不會隨着時間的推移而改變其屬性。這就是爲什麼像lfsr這樣的東西很好,它可能不是一個很棒的隨機數發生器,用於在計算機上玩紙牌遊戲,但爲了在數據總線上創建可重複的混沌數據模式並使用一小段快速執行的代碼,它就是大。如果沒有自制程序隨機數發生器,我會一起避免基於隨機數發生器的測試。

例如,如果您需要執行快速BIST,例如您可以填充與prand數字回讀的內存,填入與相同prand數字相反的內容,回讀。或者首先進行一次普查測試,以清除明顯不好的電路板,然後執行三月份測試,也許地址測試例外。或者您可以每次執行數千次/每次更改種子的普遍傳球。瞭解你的lfsr模式的屬性,你可以選擇使用模式中的下一個隨機數作爲下一次內存傳遞的種子。或者如果你想成爲理想的人,你可以使用第二個lfsr產生種子,隨着時間的推移創造出每種可能的種子。

緩存和緩存測試是一場噩夢。在芯片上應該遵循這個規則,這不是芯片驗證測試,也不是設計驗證測試,這是一個製造測試。如果你打開了數據緩存並正在測試另一側的RAM,那麼你可能會自欺欺人,可能需要在讀取通過之前執行寫入通過次數。理想情況下,您希望啓用緩存,以便您的測試運行速度很快,但希望禁用要測試的內存區域的緩存。這讓我想起了一個常見的錯誤是,只對未被執行測試的軟件使用的存儲器執行所有這些測試(假設該板卡具有處理器,sram是處理器執行存儲器),特別是使該軟件運行從零或低內存開始,這意味着大多數程序大部分時間都在運行的內存區域沒有經過測試,而程序空間和堆棧之間的中間區塊,使用較少的是經過最多測試的,並且不會測試所有地址位,因爲你可能會猛擊堆棧。幾乎浪費時間來做這樣的系統的任何內存測試,你不覺得嗎?如果你不信任內存來測試它,你就不能相信在那個內存中運行的測試程序的結果。理想情況下,您希望從ROM或片上暫存內存執行,以便可以全面測試整個內存總線。

ECC內存是另一個噩夢,精心設計的ecc內存和內存控制器將允許您處理所有位,包括ecc標籤,允許您測試ecc系統本身以及單個和多個位錯誤。如果你沒有訪問權,那麼即使對於正面的測試,如果你正在努力測試芯片內的每一個位,那麼對於每一行你都需要確保一組內存測試打開和關閉至少所有ecc位一次以及標籤中的每一位都會在一個時間點關閉所有其他位,然後關閉其他位(不一定在同一時間)。具有分支預測功能的現代處理器完全有權隨意讀取任何內存位置,因此您的測試可能會意外地通過故意植入的單個位錯誤讀取內存位置,導致該位被修復,並且在您的測試獲得時間如果實際系統運行正常,您可能會失敗,因爲您沒有看到預期的單比特錯誤。奇偶校驗與ecc類似,但並不差。

關於電路板測試的另一件事是,如果說你想測試每個芯片的所有位以及所有的PCB走線和焊點和電纜。不需要很長時間來查看外設,或者查看處理器本身的指令集(如果您有一個指令集),並且發現即使在2ghz的情況下,您甚至可能會在數百億年前查看第一個芯片的外部引腳(從內向外工作)。你不能也不會測試所有的東西,選擇低掛的水果,等待用戶(希望在家裏的軟件/ bsp開發者)找到未知的問題,然後爲這些特定的問題創建新的測試。你可能有完美的遊行內存測試,但它仍然不會發現間歇性的硬盤問題。即使在燒傷的情況下,我也看到零件在幾個月後失效。遠遠超過板/部件的預期嬰兒死亡率。底線,沒有一種尺寸適合所有解決方案,你必須調整普通或流行或個人最喜歡的做法與特定的電路板/芯片的功能,並能夠調試和創建新的測試。您還需要主動強制設計工程師設計測試。如果有產品召回,這是你的頭(測試工程師),他們會在他們面前滾動。

很抱歉的長期職位,我希望它是有用的人......

+1

非常感謝分享你的智慧。後期肯定教會了我們很多(儘管我們沒有得到我們希望的實現鏈接)。乾杯。 – 2010-09-17 18:18:06