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