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

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

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

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

故障模式

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

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

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

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

因此，目標從確保一切都不會出錯（實際上來說）轉變為安排任何遇到故障的系統自然地進入安全狀態。這并不意味著系統會像什么都沒發生一樣繼續工作，但這確實意味著系統不會進入某些可能對周圍或內部人員構成危險的不可預測的狀態。

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

識別和防止故障

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

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

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

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

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

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

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

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

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

審核編輯：郭婷