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