作為設計師，我們都希望我們的設計能夠正常工作。我們以擁有者為榮。因此，我們瘋狂地驗證以確保我們做得很好。但是驗證需要時間，而且項目有截止日期，否則他們就不會賺錢。所以，我們盡我們所能，用良好的驗證工具提供幫助，總的來說，我們做得很好。

但對于所有設計，失敗的后果并不相同。如果您的筆記本電腦或游戲機無法工作，可能會令人沮喪，甚至可能會花費您一些錢，但不會威脅到生命。另一方面，如果系統(tǒng)故障會使人員或重大財產面臨風險，那么我們就進入了功能安全領域。

這曾經是軍用或民用飛機小批量、高成本項目的唯一領域。你上次旅行時乘坐的飛機上的所有電子設備？他們必須工作；失敗不是一種選擇。你的生活取決于它。

但時代在變：安全至上的不再只是坦克、導彈和飛機。所有的電子產品都被設計到汽車中，包括驅動的和無人駕駛的。這將功能安全從稀有的軍事/航空航天領域帶入了為消費者制造的汽車的喧囂。安全關鍵芯片的數量應該會飆升。

故障模式

從廣義上講，有兩類失敗：

系統(tǒng)性故障：這些是由于原始設計規(guī)范或規(guī)范實施中的錯誤而引起的問題。這就是傳統(tǒng)驗證的解決方案。

隨機故障：這些是由不可控制的力量引起的任何其他類型的故障。這包括電磁影響、所謂的“單粒子擾動”（如 α 粒子）以及任何其他此類影響。這些事件可以改變至少一個觸發(fā)器（任何觸發(fā)器）的狀態(tài)，并且隨著電路尺寸的縮小，單個事件甚至可能影響多個觸發(fā)器，因為它們非常靠近。

隨機故障域是設計中更難解釋的域。有些技術多年來一直用于小容量系統(tǒng)——比如三模塊冗余。但對于面向消費者的汽車來說，它們太貴了。

因此，目標從確保一切都不會出錯（實際上來說）轉變?yōu)榘才湃魏斡龅焦收系南到y(tǒng)自然地進入安全狀態(tài)。這并不意味著系統(tǒng)會像什么都沒發(fā)生一樣繼續(xù)工作，但這確實意味著系統(tǒng)不會進入某些可能對周圍或內部人員構成危險的不可預測的狀態(tài)。

作為設計師，您的任務就是盡量減少可能的故障數量，然后防止那些仍然存在的故障。未檢測到的故障——那些沒有傳播到系統(tǒng)，因此對任何輸出都沒有明顯影響或沒有導致非法內部狀態(tài)的故障——不是問題，也不需要保護設計。另一方面，確實傳播到系統(tǒng)的可檢測故障依賴于額外的電路進行保護。目前，一旦您知道關鍵故障在哪里，這些電路都是手動設計的。

識別和防止故障

那么如何發(fā)現這些故障呢？這是一項工作……我們將使用廣義上的“模擬”一詞，盡管正如我們將看到的，EDA 模擬器無法勝任這項任務。這個想法是在注入故障的同時模擬系統(tǒng)，以了解哪些故障會導致不希望的狀態(tài)。并且有很多可能的故障——理論上，每個觸發(fā)器有多個故障。ISO 26262 建議在門級進行故障注入，與基于 RTL 的設計相比，驗證系統(tǒng)的潛在故障活動成為一項更大的任務。

這里有幾個挑戰(zhàn)使這項任務比看起來更加困難。首先，有幾種故障需要測試。最常用的模型是固定故障、瞬態(tài)故障和橋接故障。并且此類故障通常一次注入和測試一個，因為這降低了測試的復雜性。

此外，完成設計的故障活動所需的故障列表可能非常大。例如，單獨測試一個微處理器可能需要一個包含 100，000 個故障的列表，因此完整的 SoC 故障活動將擴展某些技術的限制，例如模擬。

所謂的故障修剪可以幫助減少故障列表的長度，這是 Mentor 積極參與的一個積極研究領域。但是，說實話，即使在修剪之后，你仍然會有很長的清單。

如果您使用傳統(tǒng)的 EDA 模擬器來完成這項工作，這將是一個巨大的項目。僅 100，000 門處理器就可能需要 11 天的時間，使完整的 SoC 遙不可及。這使得這成為一項仿真工作，Mentor 為 Veloce 仿真器系列提供了一個故障應用程序。

您首先提供必須注入的故障列表，Veloce Fault App 系統(tǒng)地處理該列表，記錄所有結果。這仍然需要時間，但是在任何給定的運行中，一旦檢測到意外狀態(tài)，該特定運行就會停止并被記錄下來（換句話說，最慢的故障是不會提前結束的不可觀察的故障）。

您不必絕對列出設備中的每個網絡，因為很可能有些區(qū)域顯然不會引起關注。但其他一切都應該被代表

完成后，您將獲得一份故障輸出列表、未檢測到的故障以及設計的整體故障覆蓋率——所有這些都有助于您強化設備以滿足功能安全要求。

毫無疑問，提供功能安全需要額外的工作。但這比召回部件或車輛后的重新設計要少得多——而且成本要低得多！配備 Veloce Fault App 的 Veloce 仿真器可以處理任務中繁瑣的部分，為您的設計技能留下更有趣的保護設計。

審核編輯：郭婷