|
汽車(chē)半導體行業(yè)目前所處的時(shí)代，是試圖利用機電一體化系統替代復雜的機械互聯(lián)的時(shí)代。為了簡(jiǎn)化布線(xiàn)設計，也為了有效處理汽車(chē)各系統之間的通信流程，就設計了LIN(局域互聯(lián)網(wǎng))總線(xiàn)協(xié)議，廣泛應用于門(mén)鎖、車(chē)鏡、雨水傳感器、動(dòng)力總成、中央電子控制單元(ECU)等諸多應用，即使在超高溫條件下也可正常運作。 設計中一個(gè)小小的缺陷都有可能是致命的！因此應適時(shí)進(jìn)行可靠穩定的檢查，驗證系統的正確性和穩健性。有許多實(shí)際場(chǎng)景無(wú)法在SoC上輕松再現。例如，發(fā)動(dòng)機周?chē)鷾囟冗^(guò)高，就可能導致設置或保持時(shí)間不正確，產(chǎn)生錯誤采樣。這會(huì )造成數據損壞，導致故障。同樣，車(chē)內的電磁或環(huán)境噪聲會(huì )觸發(fā)某個(gè)比特的變換，這也可能是致命的。對于進(jìn)行芯片后驗證的工程師，再現這些場(chǎng)景并在在芯上進(jìn)行恰當處理是一項充滿(mǎn)挑戰的工作。 本文介紹了一些LIN設計問(wèn)題，這些問(wèn)題出現在芯片上，設置復雜。本文詳細闡述了多個(gè)由于完整性或架構失誤而出現的系統級問(wèn)題，例如，LIN數據通過(guò)DMA傳輸后，SoC無(wú)法進(jìn)入低功耗模式。本文還重點(diǎn)介紹了LIN的低功耗模式行為，其設計也有望改進(jìn)。 簡(jiǎn)介 LIN作為一個(gè)低成本系統，由汽車(chē)制造商聯(lián)合設計，可以替代傳感器、執行器和開(kāi)關(guān)等應用(在這些應用中速度并不是限制因素)的高速總線(xiàn)，如CAN(控制局域網(wǎng))。 LIN協(xié)議是一種雙線(xiàn)廣播串行網(wǎng)絡(luò )，網(wǎng)絡(luò )中信息由主機進(jìn)行初始化。主機決定何時(shí)將哪個(gè)幀傳輸至總線(xiàn)。LIN幀頭具有以下域： ·同步間隔 ·同步字節 ·ID字節 ·數據字節 ·校驗和字節 模擬錯誤場(chǎng)景 由于溫度變化、干擾等原因，電子系統的噪音噪聲無(wú)法避免。因此，必須在芯片上徹底驗證總線(xiàn)協(xié)議的錯誤處理能力。然而，在實(shí)驗室中可靠地生成所有的錯誤場(chǎng)景是一項棘手的工作。通常，SoC不提供任何生成奇偶錯誤、成幀錯誤等的方法。為了避免這個(gè)限制，我們可以采用函數發(fā)生器(FG)等外部設備強制生成錯誤。通過(guò)FG，我們可以操縱LIN幀頭，并生成包含所需錯誤的錯誤幀。 FG可以用于生成具有以下錯誤的LIN幀： ·同步域錯誤 ·同步間隔符錯誤 ·ID奇偶錯誤 ·校驗和錯誤 ·成幀錯誤 如果同步域不一致，即報告同步域錯誤；如果間隔符域過(guò)短(小于1位時(shí)間)，即出現同步間隔符錯誤；幀頭奇偶錯誤導致ID奇偶錯誤；如果接收的校驗和與預期校驗和不符，表示出現校驗和錯誤；無(wú)效的結束位會(huì )導致成幀錯誤。多數錯誤的報告是由于其中一個(gè)域中的一個(gè)或多個(gè)比特變換，如LIN幀的間隔、同步、ID、數據或校驗和。 圖1是利用FG生成的沒(méi)有錯誤的LIN幀。該幀清楚地顯示了間隔域、同步域、ID域、數據域及校驗和域。ID域的正確解碼為0x01，數據域為0x55，校驗和為 0xE8。 圖1：利用函數發(fā)生器生成的LIN幀 由于LIN是一個(gè)慢速協(xié)議(最大運行速度為20kbps)，而且生成錯誤只涉及到1個(gè)位域變換，因此我們可以利用FG輕松復制此類(lèi)錯誤場(chǎng)景。 系統級問(wèn)題——在SoC中最為常見(jiàn) 當今，半導體行業(yè)正在生成一個(gè)十分復雜的系統，芯片后活動(dòng)也成為了及其復雜的工作。我們無(wú)法想象LIN作為一個(gè)獨立IP存在于這個(gè)系統中�？梢酝ㄟ^(guò)多個(gè)IP時(shí)鐘源進(jìn)行計時(shí)，并產(chǎn)生大量的波特。在SoC中，LIN可以與DMA、INTC、低功耗子系統等其他多個(gè)控制器進(jìn)行連接，完成特定工作。因此，問(wèn)題會(huì )在任何地方隨機出現。 圖2：利用函數發(fā)生器生成的具有奇偶錯誤的LIN幀 圖2顯示的LIN幀含有FG帶來(lái)的ID奇偶錯誤。我們可以清晰地看到，盡管檢測到的數據正確，為0x55，但由于接收的ID和奇偶不符，因此對ID報錯。該錯誤是由于ID中的一個(gè)比特域或兩個(gè)奇偶域的任意一個(gè)域發(fā)生了交換。此處是由于改變了正確幀中的一個(gè)奇偶位。同樣，我們可以通過(guò)函數發(fā)生器生成包含其他錯誤的幀。 圖3：SoC上的LIN 在芯片前模擬環(huán)境中，一些實(shí)際場(chǎng)景無(wú)法在軟件模式中復制，許多極端案例可能會(huì )被遺漏。例如，電路局部溫度升高會(huì )導致不必要的鎖存器延遲，從而造成整個(gè)系統癱瘓。芯片上常出現以下系統級問(wèn)題： A.低功耗子系統故障 系統中會(huì )有多個(gè)LIN實(shí)例。其中一個(gè)場(chǎng)景是整個(gè)SoC都處于省電模式，LIN計時(shí)仍在繼續，因此它可以接收外界的數據包，并在幀接收后中斷時(shí)喚醒系統。其中一個(gè)LIN實(shí)例就是無(wú)法在這種情況下喚醒系統。 計時(shí)控制中也出現了問(wèn)題。系統進(jìn)入低功耗模式時(shí)，無(wú)法正確啟動(dòng)LIN計時(shí)來(lái)在低功耗狀態(tài)下接收數據包。 B.LIN-DMA握手問(wèn)題 如果一些數據要從存儲器傳輸至另一個(gè)存儲器，或者從外圍設備傳輸至存儲器，或者從存儲器傳輸至外圍設備，此時(shí)DMA在系統中用于分流內核。 低功耗子系統需要在進(jìn)入低功耗模式之前解除信號。在DMA傳輸完成后，信號不會(huì )解除，這樣系統就不會(huì )進(jìn)入低功耗模式。 這個(gè)問(wèn)題的根本原因在芯片上，在芯片上我們發(fā)現DMA傳輸完成后FIFO標志信號為空，表明LIN需要更多數據，因而阻止整個(gè)系統進(jìn)入低功耗模式。 C.車(chē)載LIN物理層問(wèn)題 LIN是單線(xiàn)協(xié)議，它檢測“傳輸開(kāi)始”，作為其數據線(xiàn)上1至0的切換點(diǎn)。 圖4：收發(fā)器前后的LIN幀探測 車(chē)載LIN物理層收發(fā)器之后的總線(xiàn)上未檢測出數據，但在接收器之前的范圍內數據正常顯示。 在這個(gè)問(wèn)題上，車(chē)載LIN物理層采用了強大的下拉電阻器，保持數據線(xiàn)的低壓狀態(tài)。因此LIN無(wú)法檢測“傳輸開(kāi)始”，從而造成無(wú)通信。為了克服這個(gè)問(wèn)題，建議在車(chē)上使用上拉電阻。 隨機化——找出極端案例 隨機化是在芯片后驗證工程師中非常流行的術(shù)語(yǔ)。隨著(zhù)技術(shù)從90nm發(fā)展至60nm、45nm、28nm直到20nm等，設計的復雜性也在成倍增長(cháng)。因此，設計缺陷會(huì )出現在各個(gè)地方，可能是邏輯數字錯誤、集成問(wèn)題甚至是由于操作環(huán)境的變化而造成的問(wèn)題，如流程(P)、電壓(V)、溫度(T)或者頻率(F)的變化。因此，在這個(gè)充滿(mǎn)挑戰的環(huán)境中，利用定向測試用例解決設計問(wèn)題并不是一個(gè)聰明的解決方案。 那么，解決方案是什么？解決方案在于隨機化的過(guò)程中。盡可能多的地實(shí)現隨機化，并讓測試用例運行多個(gè)小時(shí)，給系統增壓。如果系統崩潰，就將問(wèn)題縮小到根本原因的層面上；如果系統安然無(wú)恙，說(shuō)明設計相對穩定！ 圖5：隨機化的基本流程 對于LIN而言，隨機化可以在各個(gè)層面實(shí)現： ·輸入時(shí)鐘源選擇隨機化 ·輸入時(shí)鐘頻率隨機化 ·輸出波特隨機化 ·LIN參數隨機化 ·LIN實(shí)例隨機化 ·IO pad mux隨機化 所有這些隨機測試的主要意圖就是，在參數范圍內給系統增壓，直至其掛機或崩潰。 菊花鏈檢查 SoC中會(huì )有許多LIN的實(shí)例，多達20例甚至更多。驗證眾多實(shí)例的所有功能是一項繁瑣而費時(shí)的工作。為了驗證眾多實(shí)例，LIN協(xié)議可以以菊花鏈的方式運行，不僅可以節省驗證工程師的時(shí)間，還可以在LIN幀遍歷眾多實(shí)例之時(shí)檢查數據完整性。 圖3介紹了不同LIN實(shí)例的菊花鏈檢查。由于LIN是一個(gè)單線(xiàn)協(xié)議，所有的LIN收發(fā)板都可以連接至一個(gè)公共線(xiàn)上。第一對實(shí)例可以配置為主從對。第二個(gè)實(shí)例完成數據接收后，可以配置為將接收的數據傳輸給第三個(gè)實(shí)例，也是主從對配置。不斷重復這個(gè)程序，直至數據被最后一個(gè)用例接收。這時(shí)，數據就可以與初始數據進(jìn)行比較。 圖6：隨機化的基本流程 LIN/UART應用代碼要考慮的問(wèn)題 LIN/UART不能在超過(guò)9600bps的特定設置下運行。 其中一個(gè)UART用例是接收來(lái)自個(gè)人電腦(CP)COM端口的數據。有文本文件從PC端通過(guò)超級終端發(fā)送。UART按字符接收文本，并再按字符將其發(fā)回至PC的COM端口。發(fā)送的整個(gè)文本文件在超級終端打印出來(lái)。超級終端波特率和UART波特率均被設置為同樣的值。 如果我們使用的波特率高于192000，就會(huì )打印正確的文本。然而，如果波特率低于或等于19200，文本文件的一些字符就被遺漏。隨著(zhù)我們進(jìn)一步降低波特率，接收的文本就會(huì )嚴重混亂。 黃色波形是從PC中接收(在控制板的Rx引腳取樣)。綠色波形是從UART發(fā)回至PC(在控制板的Tx引腳取樣)。 通過(guò)場(chǎng)景： 圖7：38.4Kbps時(shí)的正確數據 我們認真觀(guān)察可以發(fā)現，傳入流中的停止位比1位寬稍寬一些。 現在，我們可以看到9600bps的波形。 故障場(chǎng)景： 圖8：9.6Kbps時(shí)丟失的數據 就PC一方而言，如黃色波形所示，文本文件包括正確接收的“This”。然而，Tx引腳取樣的數據表明，遺漏了字符“h”，而其他字符(“T”、“i”、“s”)均傳輸成功。 在應用代碼方面，比特寫(xiě)操作的狀態(tài)位會(huì )被清除，同時(shí)也會(huì )在無(wú)意間清除其他狀態(tài)位。速度較高時(shí)，在軟件清除狀態(tài)位時(shí)已經(jīng)從控制板上傳輸了數據，因此沒(méi)有發(fā)現問(wèn)題，但速度較低時(shí)，狀態(tài)位在數據傳輸前就被清除，因此出現了這個(gè)問(wèn)題。 結論與未來(lái)工作 上述分析及案例研究表明，除了正常的芯片上獨立LIN IP驗證之外，錯誤場(chǎng)景及系統級驗證也至關(guān)重要，可以幫助我們生成沒(méi)有設計缺陷的SoC。我們無(wú)法否認我們需要付出極大的努力，生成錯誤場(chǎng)景條件并捕獲系統級設計問(wèn)題，但這可以大大幫助半導體行業(yè)提供更健康的芯片，從而降低成本。 我們的進(jìn)一步建議是以最高溫度、最低電壓進(jìn)行芯片驗證，利用較慢的矩陣槽捕捉設置/保持問(wèn)題。另一建議是同時(shí)通過(guò)不同的內核運行不同的LIN實(shí)例，更好地給系統增壓。 |
