中 華 大 學

中 華 大 學 碩 士 論 文

題目：SystemC 設計平台所開發的 SoC 層級錯誤 注入方法

SoC-Level Fault Injection Methodology in SystemC Design Platform

系 所 別：資訊工程學系碩士班 學號姓名：M09602013 汪宜強 指導教授：陳永源 博 士

中 華 民 國 九十八 年 八 月

中文摘要

現今的智慧型系統用途非常廣範諸如自動的車輛駕駛系統或是智慧型機器 人，也因此智慧型系統在某些方面的應用可能會跟使用者生命的安全有著很大的 關連性，當這種系統在運作時其可靠的程度需要被非常嚴謹的審視。而目前系統 晶片 (System on chip：SoC) 普遍的在智慧型系統的設計上使用到，也因此系統 晶片在安全性的議題上也逐漸受人重視，尤其是現在製程的技術已經進入到深次 微米的時代，晶片所會受到外在的影響也將是以往的好幾倍。因此我們有必要去 進行故障模式的分析 (Failure mode and Effects Analysis) 來找出系統中最脆弱的 部份，再透過容錯技術的加入來提升系統整體的可靠度。

不過將故障模式分析和容錯設計一併加入到系統晶片的設計流程是會大幅 提升設計時的複雜度，為了解決這個問題我們將採用更高抽象化的設計階層來進 行模組的設計，在這篇論文中我們所使用的是名為SystemC的高抽象化系統設計 語言。在本篇論文中我們以SystemC為設計平台開發出一種系統階層的錯誤注入 方法，此錯誤注入方法可以透過單一事件或是組合事件作為錯誤注入的啟動條 件。我們提供使用者一種具有彈性的啟動條件設定方式，使用者可以對應不同系 統平台的特性加以修改啟動條件的組合，此方法有助於使用者在系統晶片設計流 程中進行故障模式的分析。在實驗的部分我們將突顯出在進行故障模式分析時事 件驅動會比時間驅動更加有效，以及利用此錯誤注入方法進行故障模式分析的應 用展示。

Abstract

Intelligent systems, such as intelligent car driving system or intelligent robot, require a stringent reliability while the systems are in operation. As system-on-chip (SoC) becomes prevalent in the intelligent system applications, the reliability issue of SoC is getting more attention in the design industry while the SoC fabrication enters the very deep submicron technology. Thus, it is essential to perform the Failure and Effect Analysis (FMEA) procedure to locate the weaknesses of the system and provide the practical fault-tolerant strategies to improve the reliability.

But, incorporation of the FMEA and fault-tolerant into the SoC design procedure will further raise the design complexity. Therefore, we need to adopt the higher level of abstraction to design the module, such like SystemC. In this thesis, we present a new approach of SoC level fault injection methodology in SystemC design platform, which is triggering by the single event or combination events. We present a flexible design that user could choose the triggering condition by themselves, it is useful to assist user in performing the failure mode and effects analysis (FMEA) procedure during the SoC design phase. At the experiments we will show the event driven fault injection is more efficient than timing driven when proceeding the FMEA, then we will demonstrate the FMEA application by using event driven fault injection methodology.

致謝

在這兩年的研究所生涯裡，感謝有許多位的師長、學長、同學以及朋友的陪 伴與支持，使我在這兩年的碩士生活中不只是增加了許多重要的專業知識，更得 到了許多的寶貴經驗。本篇碩士論文的完成特別感謝指導教授陳永源教授的教 導，在課業及研究上都給予了我最大的協助。此外也特別感謝我的父母全力支持 我，使我能專心完成這個學業。

在求學期間感謝師長顏金泰老師與張欽智老師的指導與幫助，以及實驗室的 學長-呂坤龍、陳志偉、張坤均、石孟儒、陳信宇、周義翔、汪碩彥、許書豪、

彭建閔等人的指教，以及同學和朋友宋東彥、呂凱平、許仲賢、柯祥霖在研究生 活中的討論與鼓勵，最後僅將此篇論文獻給家人、師長、同學以及朋友，共同分 享這份得之不易的榮耀。

目錄

中文摘要... I Abstract... II 致謝...III 目錄...IV 圖表目錄...V 表格目錄...VI

第一章 簡介...1

1-1 背景介紹...2

1-1.1 錯誤種類介紹 ...2

1-1.2 錯誤注入介紹 ...4

第二章 相關研究、研究動機及問題定義...8

2-1 相關研究...8

2-2 研究動機...13

2-3 研究問題定義...14

第三章 SystemC 簡介 ...17

3-1 SystemC 概念及設計架構介紹 ...20

3-2 SystemC 設計階層介紹 ...23

3-3 SystemC 混合階層的設計方式 ...29

第四章 錯誤注入方法開發...32

4.1 錯誤注入流程 ...35

4.2 事件驅動錯誤注入方法 ...38

4.3 事件驅動與時間驅動錯誤注入方法的比較 ...41

第五章 實驗環境介紹...43

第六章 實驗設定及實驗結果分析...46

6.1 單一事件及組合事件錯誤注入模擬驗證 ...46

6.2 事件驅動與時間驅動的比較分析 ...50

6.3 透過事件驅動錯誤注入方進行故障模式分析模擬 ...51

第七章 結論與未來展望...55

7.1 結論 ...55

7.2 未來展望 ...55

參考文獻...56

圖表目錄

圖 1-1 錯誤之間的關係圖...3

圖 1-2 有效性錯誤示意圖...3

圖 1-3 有效性及無效性錯誤示意圖...4

圖 2-1 錯誤注入方法示意圖...8

圖 2-2 錯誤注入架構圖...10

圖 3-1 SystemC 架構圖 ...18

圖 3-2 系統設計流程圖...19

圖 3-3 SystemC 的基本設計架構圖 ...20

圖 3-4 SystemC 零件間溝通示意圖 ...22

圖 3-5 晶片設計各階層示意圖...24

圖 3-6 不同設計語言所包含的設計階層比較圖...25

圖 3-7 SystemC 分層架構圖 ...28

圖 3-8 交易器連接示意圖...30

圖 3-9 混合階層式系統設計架構...30

圖 4-1 錯誤注入流程圖...35

圖 4-2 錯誤注入模組及其架構圖...36

圖 4-3 資料收集模組的虛擬程式碼...36

圖 4-4 錯誤注入模組虛擬程式碼...38

圖 4-5 事件樹架構圖….………..40

圖 5-1 Platform Creator 工具展示圖 ...43

圖 5-2 記憶體配置圖...44

圖 5-3 Code Warrior 工具展示圖 ...45

圖 5-4 AXD Debugger 工具展示圖 ...45

圖 6-1 簡單的 IDCT 測試實驗平台架構圖 ...47

圖 6-2 主人端錯誤注入實驗結果...47

圖 6-3 實驗用系統平台架構圖...48

圖 6-4 僕人端單一事件驅動的實驗結果...49

圖 6-5 組合事件驅動的實驗結果...50

表格目錄

表 1-1 軟體和硬體錯誤注入方法比較表...7

表 3-1 Process 啟動比較表 ...21

表 3-2 原始通道種類列表...23

表 3-3 暫存器傳輸層與傳輸層的比較表...27

表 4-1 系統階層的錯誤模型列表...33

表 4-2 事件項目表...37

表 6-1 記憶體配置表...48

表 6-2 事件驅動與時間驅動分析比較表...51

表 6-3 測試程式為 50 乘 50 矩陣相乘之故障模式分析的模擬結果...52

表 6-4 測試程式為快速排序數量為 99 之故障模式分析的模擬結果 ...52

表 6-5 測試程式為快速排序數量為 500 之故障模式分析的模擬結果 ...53

表 6-6 測試程式為快速排序數量為 3000 之故障模式分析的模擬結果...53

表 6-7 不同測試程式之故障模式分析模擬結果...53

第一章 簡介

隨著科技與製程的進步，在晶片設計這領域中已經是到了系統晶片的時代 ( System-On-Chip )。目前製程的技術也已經進入深次微米的時代 ( very deep submicron )[1]-[3]，透過這種技術的產生使晶片電晶體的體積變小，耗電量下降，

速度提升，因而產生出所謂的嵌入式系統 (Embedded system) 和系統晶片。不過 這類型技術的出現卻也衍生出了新的問題，甚至將以往不被列入考慮的問題如今 也變成設計時的一項重要參數。舉例來說如同晶片體積的縮小導致電晶體之間線 與線的距離更加靠近，內部互相之間產生的干擾，以及受到如輻射線、電磁波、

電壓突波等外部干擾。以上這些情況在以往的設計上所會造成的影響都不大，但 如今卻因為提升到深次微米和系統晶片設計的技術，導致這些影響對於晶片造成 暫時性錯誤或永久性錯誤的機率都比以往大幅增加。由於現在嵌入式系統和系統 晶片的運用範圍非常廣泛，這些技術目前也被廣為應用在汽車、飛機等這些高安 全需求的應用方面，因此我們必須在晶片設計時加入容錯設計的概念，以此提昇 晶片的可靠度。

系統晶片主要是由軟體和硬體整合方式所設計出來，其複雜度比以往的晶片 設計高出許多。在進行系統晶片設計時若是仍然使用 VHDL 或 Verilog 等傳統硬 體描述語言時設計者將會遇到以下問題：由於 VHDL 和 Verilog 皆屬於 RTL (Register Transfer Level) 的設計階層，進行系統設計時不僅是過於複雜，程式碼 也會過於龐大導致隱藏在程式中錯誤的機率提高。再來就是由於系統晶片必須是 軟硬體整合的，但是以 VHDL 和 Verilog 和而言，如何和軟體溝通就是一件非常 麻煩且困難的事。為解決以上的問題，因此新一代的描述語言 SystemC 也就產 生了。當此一新式的設計語言產生並逐漸趨於完整時，許多電子設計自動化 (Electronic design automation：EDA) 工具的設計公司也開始對這語言有興趣並且 開始研發和設計對應此設計語言的工具或是發展環境。諸如 Synopsys 和 CoWare

等公司都相繼開發出 SystemC 相關工具，並且和目前嵌入式系統的龍頭 ARM (Advanced RISC Machine) 公司購買旗下的 ARM 系列處理器和對應此類型處理 器專用的匯流排 AMBA (Advanced Microcontroller Bus Architecture) 。這些電子 設計自動化工具透過提供與 ARM 公司購買的現成零件稱之為矽智產

(Intellectual Property：IP) 的使用許可，並將之加入到系統設計時的零件庫中，

系統設計者可以透過這些矽智產的組合和重複利用大幅提升系統設計的效率，並 且大幅降低設計時所需的時間和複雜度。

在進行容錯設計之前我們會先進行故障模式分析(Failure Mode and Effective Analysis：FMEA)，這主要是考慮到成本和效能等問題。在成本和效能兼顧的前 提下，我們必須會先進行故障模式分析以得知此系統最為脆弱或是敏感的部份，

再將此部份進行容錯機制的設計給予保護[4]-[5]。而在進行故障模式分析之前我 們必須先提出一套有效的錯誤注入方法，當加上容錯保護機制後我們仍然需要透 過此方法來確認容錯機制的有效性。因此在此篇論文中我們提出一套在 SystemC 平台設計環境下的系統階層錯誤注入方法。此方法不只是將設計階層提升至 SystemC 更提供一種以事件驅動來進行錯誤注入的概念，此概念有能有效提升故 障模式分析時的精確度，進而提升容錯設計的效率。

1-1 背景介紹

在介紹完錯誤注入的重要性之後，我們將介紹錯誤的種類以及各種錯誤注入 的方式。當我們要提出一套新的錯誤注入方法時就必須對其背景有深入的了解，

才能得知各方法之間的差異和限制。

1-1.1 錯誤種類介紹

對於整個系統的錯誤定義，在不同情況下會有不同的意義。可分成圖 1-1 三 種類型。

元件損壞 資料錯誤 系統失敗 錯誤

(fault)

錯誤 (error)

失敗 (failure) 圖 1-1 錯誤之間的關係圖

無論是要進行 FMEA 或是容錯設計，我們都必須先要了解有哪些類型的錯 誤以及哪些錯誤我們會遇到。依照上圖 1-1 我們可以看到系統上的錯誤主要有三 類，而這三類之間存在著順序關係。在整個系統中擁有許多的元件，而此元件發 生的錯誤 (fault) 會導致運算時的錯誤 (error) ，而此錯誤 (error) 就有可能導致 整個系統最後的結果失敗 (failure)。

三種錯誤類型的簡介：

1. 元件損壞 (fault)：元件可視為是系統中最基本的存在，而元件產生錯誤 (fault) 的原因有可能是物理性上的缺點，如電路在製造時容易發生的開 路或是短路，或是受到外部的干擾如電壓跳動 (Power jitter)及電磁波 (Electro-magnetic interface)干擾所造成。

2. 資料錯誤 (error)：這類型的錯誤主要是由元件出錯所造成，這此主要是 產生在元件與元件資料之間的傳輸所發生的。然而並不是每一種錯誤 (fault) 都會造成錯誤 (error)。關於此點我們會在之後進行探討。

3. 失敗 (failure)：此型態代表最後所得的結果與預期的不同，主要是由於 錯誤 (error) 所導致。

在介紹完三種類型的錯誤之後仍然存在著一個問題，那就是上述各類型中所 提到的錯誤有效性的問題。我們將透過圖 1-2 和圖 1-3 來做介紹。

圖 1-2 有效性錯誤示意圖

圖 1-2 為一或閘 (OR Gate) ，當輸入的某一端發生錯誤 (fault) 時會導致運 算結果出現錯誤 (error)，而此錯誤 (error) 就有可能造成系統失敗。

圖 1-3 有效性及無效性錯誤示意圖

但是並非每一個錯誤 (fault) 都會產生錯誤 (error) ，如圖 1-3。當及閘 (AND Gate) 輸入的某一端產生錯誤 (fault)，此錯誤 (fault) 屬於永久性的高電壓 (stuck-at one) 時，若是另一端的輸入是低電位在此情況下最後的結果仍然是低電 位，因為及閘 (AND Gate) 需要輸入的兩端都是高電位的情況下輸出才會是高電 位。在此種情況雖然輸入端發生錯誤 (fault) ，但仍可得到正確答案，這樣的情 況稱之為非有效性錯誤 (non-effective fault) 。反之若是產生錯誤 (fault) 前正確 的輸入應該是低電位，卻因為錯誤 (fault) 而變成高電位的話會就會有錯誤 (error) 的發生，而此種類型的錯誤 (fault) 就可稱之為有效性錯誤 (effective fault)。

1-1.2 錯誤注入介紹

不論是在進行 FMEA 之前或是加入容錯設計之後都需要透過錯誤注入的方 法加以檢驗。FMEA 需要透過錯誤的注入來觀察系統會產生何種反應，並透過這 些反應加以分析出系統中最為敏感或是脆弱的部份。而加入容錯設計之後更加需 要經過錯誤注入方法的檢驗來確保容錯設計的有效性。因此錯誤注入的方法在這 整套的容錯設計流程中扮演了一個非常重要的角色，接下來我們將介紹幾種錯誤 注入的方法以及對其優缺點進行分析。

1、實體錯誤注入 (Physical fault injection)

實體錯誤注入是在錯誤注入實驗中最為直接且準確的方法，不過使用此方法 所需付出的成本和風險也是最大。一般的實體錯誤注入實驗皆是以功能設計完成

且製程後的晶片，或是透過將設計的功能燒錄在可規劃邏輯陣列 (Field

Programmable Gate Array：FPGA) 後的晶片直接拿去做錯誤的注入，再來觀察錯 誤的注入會對晶片造成何種影響。這樣的錯誤注入方法是最直接且真實的，但是 卻也有很大的風險，舉例來說晶片製程完後進行錯誤注入實驗時才發現原本的設 計有所缺失，就必須重新回頭去修改硬體的設計，這樣的結果無論是成本或是上 市時間都有著很大的影響及損失。實體錯誤注入的方法中主要分為以下三種：

(1) 晶片腳位層級錯誤注入方法 (IC Pin level fault injection)

此方法是當晶片設計及製程完後，以電壓突波或是持續性的高電位的方 式從腳位將錯誤注入，借此方法來觀察晶片會產生何種影響。

(2) 輻射照射錯誤注入方法 (Radiation fault injection)

此方法與前者一樣是當晶片已經設計且製程完成才會進行，並且需要一 個完善的實驗環境。透過輻射線和雜訊等來將錯誤射向晶片，借此觀察 晶片在正常運作中遇到這些錯誤的注入會產生何種影響。以目前的系統 晶片設計技術來看，由於體積的縮小及複雜度的增加導致這類型錯誤的 影響程度和以往相較之下高出許多。

(3) 硬體基礎錯誤注入方法 (Hardware-based fault injection)

此種方法主要是透過硬體在開發設計時常用到的可規劃邏輯陣列，透過 將設計好的功能燒錄到可規劃邏輯陣列，在對可規劃邏輯陣列進行錯誤 的注入，此作法比較能夠有效的掌控錯誤注入時的精確度及各項相關參 數。

實體階層的錯誤注入方法所需負擔的風險和成本都過於龐大，尤其是晶片腳 位層級錯誤注入方法和輻射照射錯誤注入方法。此兩種方法並非只需要承擔晶片 因為錯誤的注入而損壞的成本問題，仍存在著建立幅射錯誤注入實驗環境的困難 度等問題存在。相較於前兩者硬體基礎錯誤注入方法較能節省成本，透過可規劃 邏輯陣列的輔助，此方法不需等晶片製程完成就可進行錯誤注入實驗。但是以上 這三類我們所能觀察的就只有錯誤注入後的直接反應，我們錯誤針對的目標也是

晶片整體，無法特別針對某些部份的元件或是觀察因為元件錯誤 (fault) 所造成 的影響。

有別於實體階層錯誤注入的方法，軟體實現的錯誤注入方法和模擬基礎的錯 誤注入方法都不需等到硬體設計完成。這兩種方法主要是透過軟體或是利用模擬 錯誤注入的方式，這種方法可以大幅縮減實體錯誤注入時所需耗費的硬體成本。

這是因為這兩種方式在進行晶片腳位層級錯誤注入方法時不需等到晶片製程完 成，輻射線照射錯誤注入方法時更不需要建立輻射射線所需要的實驗環境。尤其 是在可觀察性和可控制性這兩部分都遠比實體階層錯誤注入中所提及的幾種方 式更為有效。

2 軟體實現錯誤注入 (Software-implement fault injection)

此種方式主要是在程式撰寫時，多去增加一個子程式。這個程式所負責的動 作是當主程式執行時開始執行，其主要的功能就是去修改處裡器或是週邊零件的 暫存器資料或是記憶體的內容，導致硬體在實際執行時遭遇錯誤。

3 模擬基礎錯誤注入 (Simulation-based fault injection)

模擬基礎錯誤注入的方法主要是透過模擬器在執行電路模擬時進行錯誤的 注入，此方法保有軟體錯誤注入不需等到晶片製造完成就可進行實驗的優點。此 方法主要是透過在進行電路設計時就先將用來進行錯誤注入的零件加入到整個 電路中這種錯誤注入方法主要是提出一種對應所使用的硬體描述語言

(Hardware Description Language) 所適用的錯誤注入方法。然而以現今的硬體描 述語言來看設計階層主要被分為：邏輯閘階層 (Gate Level)、暫存器傳輸階層 (Register Transfer Level)、甚至是 SystemC 中所提及的交易層級中 (Transaction Layer Modeling) 所定義的多個階層。以上這些都可以利用相對應的硬體描述語 言來進行錯誤注入方法的設計，藉此達到能在設計時就提前進行 FMEA 和容錯 技術的設計。另一種則是透過模擬器所提供的內建指令 (Build-in command) 在 我們所決定的時間點注入我們所選定的錯誤。此作法的靈活性取決於模擬器所提 供的功能，較為完整的模擬器甚至能使我們觀察到晶片甚至是元件內部所產生的

影響。

在介紹完以上三大類型的錯誤注入方法後我們將對其優缺點進行比較如下 面的表 1-1。在這份論文中我們主要是使用模擬基礎錯誤注入的方式，其考量的 因素在於成本、可觀察性和可控制性。在此篇論文中我們將進行 SystemC 所對 應的錯誤注入方法的探討，並且提出一個更為具體的事件驅動錯誤注入方法，最 後透過一個簡單的嵌入式系統來進行 FMEA 展示。

實體錯誤注入 錯誤注入

技術 比較

項目

晶片腳位 錯誤注入

輻射照射 錯誤注入

硬體基礎 錯誤注入

軟體實現 錯誤注入

模擬基礎 錯誤注入

可觀察性 低 低 中等 中等 高

可控制性 低 低 中等 中等 高

電路相似性 高 高 高 中等 中等

成本需求 高 高 中等 低 低

模擬速度 快 快 快 慢 慢

表 1-1 軟體和硬體錯誤注入方法比較表

第二章 相關研究、研究動機及問題定義

2-1 相關研究

從 SystemC 此系統描述語言發展以來，以 SystemC 進行錯誤注入方法[6]-[10]

相關的研究也有逐漸增加的趨勢。在這部份我們將對以往發表的相關研究進行探 討，並將各種方法進行優缺點的比較。我們將從他們優點的部份取出精華，而缺 點的部份加以修改並加以實踐在這份論文之上。

在以 SystemC 為主的錯誤注入研究中，與智慧卡相關的兩篇[6]-[7]可以算是 較為早期的相關研究。其所採用的方式如圖 2-1。其主要分成兩部份，一種是從 特定零件進行錯誤注入，另外一種則是進行記憶體的錯誤注入。前者是透過將錯 誤注入模組 (Fault Injection Module：FIM) 擺放在要進行錯誤注入零件的連線 上，後者則是將記憶體的零件進行修改所增加的錯誤注入埠 (port) 來進行錯誤 注入。而錯誤注入控制單元 (Fault Injection Control Unit) 則是判斷並啟動錯誤注 入的控制所用，無論是對零件或是對記憶體進行錯誤注入的是由它所決定，錯誤 控制單元主要是用來判斷並決定在那個特定時間進行錯誤注入以及是對那顆零 件進行錯誤注入。

圖 2-1 錯誤注入方法示意圖

接下來我們將對這個錯誤注入方法的結構進行優缺點的分析。首先在於優點 部份由於此方法是建立在零件和零件之間的連線上，所以不需去對原始的零件進 行修改，並且可以保有零件原本的功能，此優點對於目前透過矽智產重複使用來 提升設計速度的概念而言是很重要的。由於我們所能取得的矽智產並非每項都能 提供詳細的原始碼，反而大多數都是被包裝且加密過後的存在，因此我們也無法 對其內部進行任何動作。另外一項優點則是進行錯誤注入的核心都是透過錯誤注 入控制單元，簡而言之就是中央控制的架構，這種架構無論是進行啟動條件修改 或是重新編譯都只需對錯誤注入控制單元此零件進行就好。缺點部分則是作者在 文中提及此方法適用於交易層級 (Transaction Layer Modeling) 中的一至三階 層，但卻並未詳細描述在此混合階層中錯誤注入控制單元該如何修改以及其複雜 度是否會增加，並且由於適用不同階層錯誤注入控制單元的錯誤注入條件又該以 何為依據才能啟動，這些部分都是此論文中未提及且需要加以改進的部份。在來 就是對記憶體進行錯誤注入時需要自行將記憶體零件修改並增加額外的 port 才 能達成，這點反而跟第上述的第一項優點互相矛盾。

接續上述兩篇關於 SystemC 錯誤注入方法的文章之後我們實驗室也以和 [6]-[7]相似的概念提出來另外一種新的想法[8]。這套錯誤注入方法不同於前者較 為簡單的智慧卡系統，此方法是實踐在一個超長指令集處理器上。錯誤注入方法 流程如下，首先會先決定錯誤注入的目標，再來會將所決定之目標的輸出部分加 上一個多工器 (Multiplexer) ，此方法進行前需要將目標零件在輸出部分的資料 皆以全域變數宣告。在此架構中仍然會透過一個控制單元將我們所開發的錯誤注 入工具所產生的相關資料讀入，接下來會開始正常執行並開始進行錯誤時間點的 比對，當時間一致便會送出錯誤注入啟動訊號以及錯誤注入的值。之所以需要將 進行錯誤注入的零件在輸出部分的直接設為全域變數的原因在於我們都是產生 單一位元的錯 (single bit fault) ，因此需要先得知原來的值才能進行。最後當多 工器接收到錯誤注入訊號時就會將輸出的訊號選擇成是從控制單元所接收到的 錯誤的值，以此達到錯誤注入的目的。錯誤注入架構如圖 2-2。

ALU

IN_1

IN_2

MUX

OUT

Control Signal

Error Out

Error Value

圖 2-2 錯誤注入架構圖

使用這種方法優點部份與[6]-[7]相同都是採用中央集權的控制單元來進行 錯誤注入的判斷和設定，所以每次實驗只需對其進行編譯或是修改。缺點部分第 一項如同前兩篇一樣是在錯誤注入控制單元的問題，再來就是此篇論文中提出的 方法確實只能使用在最低階層的暫存器傳輸階層 (Register Transfer Level：

RTL) 。最後一項就是此方法需要將零件的輸出部份資料全部修改全域變數，此 舉會對系統的模擬產生不小的影響。

接下來我們實驗室更提出一篇對應三種不同設計階層的錯誤注入方法[9]，

此三階層為匯流排精確週期設計階層 (Bus Cycle Accurate) 、無時間設計階層 (Untimed Functional level) 和交易層級 (Transaction Layer Modeling) 三項。此篇 論文最主要的目的是為了解決 SystemC 在進行系統設計時可能會混合多種不同 的設計階層，而對應這多樣化的設計階層所採用的錯誤注入的方法是否又會有所 差異。以當時所參考過的論文中尚未有人提出並解決這問題，所以此篇論文的作 者提出三種不同階層的錯誤注入方法，讓設計者可以自行選擇對應其系統的方法 來進行錯誤注入的實驗和分析。在此篇論文中提出了幾項重要的觀念，而這些觀 念也對我們在進行往後的研究有著重要的影響。其中之ㄧ就是在對應交易層級時 錯誤注入的方法，而此項問題又牽涉到當我們在進行系統設計時同常會以 ARM 公司的處理器 (ARM 926EJS) 和 ARM 匯流排 (AMBA) 為主要架構，而這種設 計方式對應到 SystemC 的設計階層時便是屬於交易層級，此篇論文中提到了在 交易層級時針對 AMBA 所使用的錯誤注入方法。再來就是事件驅動的觀念，將

SystemC 設計階層提升到較高的階層的時候時間這參數不在精確，在此情況下該 以何為依據來進行錯誤注入的啟動條件，為了解決這個問題作者提出了事件驅動 這項觀念。最後就是分散式錯誤注入的概念，這項概念跟[8]有些相似，只在要 進行錯誤注入的目標點擺放錯誤注入模組。然而這些概念的確有其用途，但是此 篇論文中所提出的概念和所實踐的方法卻都有著不少的問題，好比說事件驅動由 於啟動條件僅止於傳輸次數和特定的值。對於較為完整的系統進行 FMEA 而言 卻過於不實際且用處不大，難以跟實際系統所發生的錯誤做連結。再來就是在交 易層級對應 AMBA 所提出的錯誤注入方法和無時間設計階層卻需要加入額外的 資源，前者需額外加入 AMBA 後者需要增加額外通道 (First In First Out：

FIFO) ，這項舉動當然都會對原本的系統造成影響。其中又以增加 AMBA 影響 最大，會造成整個系統的週期出現問題並且會讓讀寫的週期都造成延遲。

在相關研究[10]中提出一個對應嵌入式系統中系統匯流排所使用的錯誤注 入方法，此方法主要是透過一個監控模組 (monitor) 放置在主人端 (Master) 到 系統匯流排 (AMBA) 的連結上，其連接方式如圖 2-3。錯誤注入的流程主要分 成兩大部分，第一步會先進行資料收集，在這次的模擬中並不會進行任何的錯誤 注入，這次的模擬主要是將系統實際執行時所出現的任何事件進行收集，而這些 事件主要包含位址、資料和控制訊號等。收集的辦法就是透過連接在資料傳輸線 上面的監控模組，一旦有資料經過便能進行收集，收集這些資訊主要是為了第二 步驟進行錯誤注入的啟動條件。第二步驟是實際進行錯誤的注入，原本做為監控 並收集資料的監控模組在這步驟中會被替換成錯誤注入用的模組。此錯誤注入模 組是參考原本監控模組的概念所設計，因此可以如同監控模組一般接在連接線上 而並非是兩個零件的連接線之間，此方法為解決[9]所遇到的需要額外增加 AMBA 所提出的方法。透過第一步驟所收集到的所有資訊，使用者可以選擇出 他們所需要的啟動事件並以此來啟動錯誤的注入。舉例來說，使用者可設定特定 的位址出現時進行錯誤注入，或是特定主人端動作時進行錯誤的注入。從這篇論 文中我們學到了如何將事件啟動的條件更為明確定義，並且能更為符合真實系

統。再來就是事件組合的這項概念，然而這部份仍屬於簡單的敘述還無法更為詳 細且具體的說明事件組合這概念，以及所能夠注入的錯誤種類僅屬於資料部份。

接下來在相關研究[4]中提出了一種針對對應 ARM 高效能匯流排的錯誤注 入和分析的方法。分析方法的部分成為了我們對系統匯流排進行失敗模式分析的 參考，不過在錯誤注入的部分仍是採用時間的方式進行錯誤注入，而設計的階層 似乎也只是在最低的暫存器傳輸階層。在相關研究[11]中作者提出一種有效並且 簡單可以提升錯誤注入效率的方法，不過此方法在錯誤注入的方法上採用的是侵 入式的方法。雖然在題目上就有清楚強調出是採用最少侵入的方法，但是對於目 前透過矽智產重複利用加快系統建置效率為主的設計方法論中仍然不太適用。最 後的相關研究[12]中提出了適用在 SystemC 平台上所使用的錯誤模型以及不同的 錯誤注入方法，在這篇論文的錯誤注入方法部分主要是透過所使用的工具提供的 相對應指令來達到錯誤注入的功能，在這部份其實就已經被所使用的工具所限制 住。在錯誤模型的部份只有分成永久性和暫時性錯誤，此外在本文中雖然有提及 到事件驅動的概念，但實際上仍然是採用時間驅動來進行錯誤的注入，在設計層 級的部分都是屬於暫存器傳輸的階層。

在看完以上的相關研究之後，雖然[6]、[7]和[9]有提出較高階層的錯誤注入 方法，但是對應 PV(Programmers View)此 SystemC 最高抽象化階層設計階層的錯 誤注入方法卻是毫無提及。此外上述相關作品[6-12]的作品中除了相關研究[9]中 有提出簡單的事件驅動的錯誤注入概念外，其餘皆是採用時間驅動的方式來進行 錯誤注入。因此這些欠缺的部份便是本篇論文的重點，為了能夠在高抽象化的設 計階層進行錯誤的注入，我們將提出一種與系統運作行為相符的事件驅動錯誤注 入方法。在本篇論文中的第四章錯誤注入方法開發中我們將會提出對應系統晶片 平台可使用的錯誤模型、錯誤注入流程和錯誤注入模組。此外我們也會對事件驅 動和事件組合的概念作出更為明確的定義，並且透過實驗的部份進行時間驅動和 事件驅動錯誤注入方法的比較，透過這實驗來突顯出事件驅動錯誤注入方法的優 勢。

2-2 研究動機

由於 SoC 的設計越見複雜，因此產生出如 SystemC 這樣的高抽象化和高階 層的設計語言。但這只能降低其複雜度，但是對於 SoC 所衍生出的安全性問題 卻仍然存在，我們所需要的不只是模擬速度的提升更需要一套完整的驗證流程和 精確的風險分析方法，以此來確保能達到一定的可靠度。為了解決這些需求，在 本篇論文中所提出的方法便是為了達到以下幾點訴求：

動機一：提升系統的設計階層及模擬速度

設計者為了提升系統建構的速度因而產生出矽智產重複使用的概念，因此有 些公司也以設計並販賣這些矽智產為主。為了提升模擬速度，晶片設計的階層也 不斷向上提升，從最底層的版面配置圖 (Layout) 到電晶體電路設計再到硬體設 計語言的 VHDL 和 Verilog，如今更出現了 SystemC 這種系統描述語言。這所代 表的無非是想提昇晶片設計及系統晶片設計的整體效率，因此這也引導出我們第 一個動機，為了呼應這個概念本篇論文我們以 SystemC 此高抽象化設計階層進 行系統設計以達到整體效率的提升。

動機二：提出一種事件驅動的錯誤注入方法來解決高抽象階層無時間概念的問題 為了提升系統的模擬效率，我們將會透過高抽象化的設計方式來提升模擬速 度。不過在這種高抽象化的設計階層之下卻無法具備明確的時間，在這種情況之 下我們將採用事件驅動概念的錯誤注入方法在高抽象化無時間概念的階層中達 到錯誤注入的目的。

動機三：提供一套更為完整的容錯設計流程

容錯設計是為了提昇晶片的安全度所提出的，然而若是沒有完善的錯誤注入 方法和更為精確的錯誤敏感度分析，任意對某些零件或是整個系統都進行容錯設

計給予保護，這樣的舉動不只是成本問題甚至連系統效能都有可能受到很大的影 響。因此我們希望能提出一套更為有效率且完整的容錯設計方法，透過它來達到 有效提升可靠度並且減少時間和成本的消耗。

動機四：更為符合實際可能發生的錯誤模型

在以上的相關研究中所能做到的都只是將原本的資料進行改變以達到錯誤 的產生，但是對於目前系統設計時所會產生的錯誤形態來說似乎太為單調且不 足。尤其是現今的系統設計都會有處理器和匯流排的存在，如目前最廣為運用在 系統設計上的 ARM 系列處理器和專用的匯流排 (AMBA) 都是現今系統設計不 可欠缺的零件。在這樣的環境下如何能產生較為多樣的錯誤種類以及如何將這些 錯誤與實際系統的出錯情況互相對應將是一件很重要的事。

動機五：增加錯誤注入的效率來提昇錯誤注入模擬分析的效率和正確性

為了提升容錯設計整體效率錯誤敏感度分析便是其中最重要的一個環節，尤 其是進行錯誤敏感度分析時會需要大量的實驗，此時便會產生出一個有效性實驗 的問題。尤其在進行錯誤敏感度分析時我們可能是針對系統中的某個部份，但大 量實驗中又有多少次是在該部分運作時所進行的有效性實驗。這將會嚴重考驗到 錯誤敏感度分析的效率和正確性。

2-3 研究問題定義

在介紹完上述的相關研究和研究動機後，我們在此先對將方法論加以實踐時 會遇到的問題提出並加以探討：

1. 如何將系統設計階層和效率加以提升？

在 OSCI (Open SystemC Initiative) 所訂立的 SystemC 設計階層可以簡 單分成三大階層，我們在進行系統設計時主要使用的是 CoWare 所提供的

Platform Architect 這套對應 SystemC 的系統設計工具，而這套工具中提供矽 智產函式庫 (IP Library) 中存在著 PV (Programmer View) 和 PV+T

(Programmer View With Time) 這兩種最高階層設計階層的矽智產，以此提升 系統設計的效率。因此我們在進行系統設計時會將現有的矽智產加以整合，

更進一步採用混合 OSCI 中所定義的 SystemC 最高抽象化的 PV 和 PV+T 兩 階層以達到系統設計時最佳的建構速度和效率。

2. 如何改進相關研究中增加額外匯流排所造成的問題？

在之前相關研究中[10]所提出的系統匯流排的錯誤注入方法中需要加 入額外匯流排，在我們實際試驗過後發現增加額外匯流排不只是會造成模擬 時間的增加更會產生嚴重的時脈問題。在此篇論文中我們所採取的 PV 和 PV+T 混合階層設計方法主要有兩個目的，一個是為了提升效率，另外一個 便是要解決額外匯流排才能進行錯誤注入的問題。

3. 將我們所提出的錯誤注入模型實踐在現有的自動化設計工具時有何限制？

在我們所提出的錯誤注入模型套用到 CoWare Platform Architect 就會受 到該工具的限制，影響較大的部分就屬可進行錯誤注入的訊號此部份，諸如 ARM 高效能匯流排中最為重要的控制訊號 HREADY 卻因為矽智產函式庫 是經過包裝並隱藏的關係無法使用，另外就是回應訊號中的 Retry 和 Split 皆因為 CoWare Platform Architect 設計的不完整而無法使用。

4. 如何將系統的錯誤行為進行分類來提供給錯誤敏感度分析？

這部份我們是參考[4]文章中所做的分類為基礎再加以改進甚至更為細 分，再透過工具模擬時所呈現的反應相互比對加以驗證。在系統設計中擺放 監控模組或是驗證模組，透過此方法能直接將系統模擬時的反應在該硬體內 部進行處理，最後再將此資訊透過檔案輸出的方式使我們提升錯誤敏感度分 析的效率。

5. 如何增進實驗的效率？

進行錯誤敏感度分析時需要大量的實驗才能確保實驗數據的可信度，因

此如何提升模擬的速度和自動化的模擬以及資料收集相當重要。我們透過 share script 程式撰寫的方式來達到重複呼叫並執行模擬的功能，使系統在模 擬結束時會再自動的進行下一次模擬。除此之外我們也另外撰寫 ARM 處理 器專用的.ini 檔將處理器在進行模擬時執行程式的檔案路徑和初始動作都寫 在此檔案中，透過這兩項技巧使系統模擬得以自動化並且達到大幅提升大量 實驗效率的目標。

第三章SystemC 簡介

由於製程技術不斷的演進，單晶片設計時的複雜度也是不斷的提升。單晶片 的功能從簡單的計算或是控制發展到複雜的超大型積體電路 (Very Large Scale Integration)，就目前的技術而言晶片也不再只有單一性的功能，反而是將整個系 統都整合進一顆晶片此晶片稱之為系統晶片 (System-on-chip：SoC)。在晶片製 程與設計的複雜度不斷提升的過程中設計者所使用的晶片設計工具 (Electronic Design Automation) 也必須跟著一同提升。在這領域之中，製程技術一直是跑在 最前端，但若是無法將設計的技術或是方法一同提升便無法將製程技術提升的優 勢發揮出來。而選用的晶片設計工具以及晶片描述方式更會對設計者在進行晶片 設計時有著很大的影響。在晶片描述的部分，從最早期的晶片佈局 (Layout) 發 展到透過邏輯閘來進行電路設計，不過這兩種描述方式已經無法應付目前越趨複 雜的晶片功能設計。隨後產生的硬體描述語言 (Hardware Description Language：

HDL) 如 VHDL 和 Verilog，透過如軟體設計般的語言方式進行描述來提升設計 上的抽象化階層並且降低設計時的複雜度，此設計階層被稱之為暫存器傳輸階層 (Register Transfer Level：RTL)。不過對於目前的系統晶片而言，以上的晶片描述 方式都已經過於複雜，並且在模擬時間上也過長。因此便由多家晶片設計相關的 公司組成了一個名為 OSCI (Open SystemC Initiative) 的組織訂定出了 SystemC 這 項新一代的描述語言。而為了推動系統晶片設計這項議題 SystemC 便產生兩派 不同的使用方式，其中之ㄧ OSCI 是以軟體功能開發為主，而 OCP-IP (Open Core Protocol – International Partnership) 則是著重在系統平台設計時硬體零件的整 合。不過兩者都是以交易階層模組 (Transaction Level Modeling：TLM) 為其主 要的設計階層和方法核心。

SystemC 是由 C++為基礎再加上硬體描述專用的函式庫後所發展出來的系 統描述語言，其主要架構圖如下圖 3.1[13]。

圖 3-1 SystemC 架構圖

從上圖中我們可以看到 SystemC 從原本的 C++為基礎，由下而上增加了硬 體使用的特殊資料型態、硬體描述時必須的模組和埠等基本宣告的核心語法、傳 輸資料所使用的通道、特殊方法論用的函式庫以及負責驗證和確認用的函式庫，

關於 SystemC 更為詳細的設計概念會在下一個小章節加以介紹。SystemC 兼具軟 體和硬體的設計及模擬能力，在以往進行系統設計時得先等到硬體平台實際成品 出來後才能進行軟體部分的開發，卻因為 SystemC 的出現使軟體和硬體可以更 方便進行協同設計和協同模擬，以至於能夠提升系統設計時的效率。系統設計流 程圖如圖 3.2[13]。

SystemC

Software algorithm System

specification Requisite specifications/standards Division of

hardware/software Performance

evaluation C/C++

Hardware specifications

Untimed

Timed

RTL

Gate level, layout &

wiring , physical verification

Software specifications

Software refinement

Object code Hardware /software

Co-Verification

圖 3-2 系統設計流程圖

從上圖中就可看到現在的系統設計流程，軟體部分還算比較單純，可是硬體 部分卻擁有許多不同的階層。透過 SystemC 我們能在系統設計的流程中較為早 期的階段進行模擬驗證，避免等到最後的邏輯閘階層或是晶片佈置階層才發現和 軟體部分的溝通或是功能的設計上有所問題，又得將硬體設計的流程重新再進行 一遍，這樣不只是大幅降低設計效率以及增加設計成本消耗，更會影響到產品上 市的時間等許多嚴重的問題。現在的嵌入式系統設計與以往差異最大的地方在於 設計時會進行軟硬體切割的動作，透過 SystemC 此系統設計語言便能替系統設 計者減輕不少軟硬體協同模擬或整合上的負擔，更能增進設計上的效率。

3-1 SystemC 概念及設計架構介紹

SystemC 是由 C++此軟體設計語言加上硬體專用的函式庫所組成，在整體上 跟原始的 C++的設計概念有許多相似的地方。圖 3.3 所顯示的就是在透過 SystemC 進行零件的設計時的基本架構[13]。

sc_module

process variable

sc_thread

sc_cthread sc_method

sc_port

channel sc_interface

0..* 0..*

0..*

1

圖 3-3 SystemC 的基本設計架構圖

由上圖可看到 SystemC 主要是由以下幾大項目所組成，整個 SystemC 零件 的主體就是 sc_module 等同於 C++中的物件，在硬體設計時一顆大型的零件可能 是由多顆小型零件組合而成，此概念正好就跟 C++中的物件導向設計概念非常相 似。如同 C++的物件設計概念一般，一顆物件會擁有自己所需要的參數 (variable) 和相關的成員函式 (member function) ，不過在成員函式的部分和硬體設計時卻 有一個差異較大的設計概念。硬體設計時所用的是程序 (process) 的概念，而且 這些程序之間是可同時並行運作的，這便是在進行 SystemC 設計時較為需要注 意的一點。另外一點就是 SystemC 的程序啟動主要有三種不同的方式：

sc_method、sc_thread、sc_cthread 三種。三者之間的差異如表 3-1。

Process Type sc_method sc_thread sc_cthread 啟動方式 Signal events Signal events Clock edge

是否採用無限迴圈 NO YES YES

中止及重新開始透 過

無 wait() wait()

動態驅動方式 Netx_trigger(event); wait(event) wait(event) 應用在何種設計階

層

RTL 行為層描述 有限狀態機設

計 表 3-1 Process 啟動比較表

透過上述三種不同類型的程序啟動方式，就可進行不同用途或階層的零件設 計。而另外一項 C++所沒有的便是埠 (port) 的概念，以硬體設計概念來說一顆 零件設計時必須要考量到有哪些輸出或是輸入的埠，不過在 SystemC 上的埠的 概念卻遠比以往硬體描述語言中所使用的埠更為複雜且多功能。如圖 3.3 所示埠 也是整顆零件中很重要的一部分，在 SystemC 的埠除了需要宣告是輸出或是輸 入外，更要明確宣告其所使用的是何種介面 (sc_interface) ，選定介面會關係到 資料傳輸時所能使用的通道 (channel) 類型和其通道所提供的功能 (method) 。 其概念我將透過圖 3.4 來進行說明[14]。

pA－＞write(v) ; v = pB

read() ; modA mA

A_thread

port pA

modB mB

B_thread

port pB sc_fifo<int> c;

write () … read () … sc_interface

sc_port

channel

process process

module module

圖 3-4 SystemC 零件間溝通示意圖

如上圖所示模組 A 要將資料寫進模組 B，首先模組 A 透過動態驅動的方式 啟動了某個程序，該程序是屬於寫出資料的功能，接下來資料會透過埠所使用的 通道所提供的功能將資料寫入到模組 B，而模組 B 要接收此資料也需要透過埠搭 配通道所提供的功能將資料讀入。

由上面的敘述便可得知通道是 SystemC 中很重要的概念，而通道主要是用 來連接元件並且進行資料傳輸的存在。在 SystemC 中元件所可連接的通道分成 兩大類，分別是原始通道 (Primitive Channel) 和多層次通道 (Hierarchical Channel)。原始通道架構的內部不會包含多個結構或程序，並且也不能直接去連 接到其它的通道。反之多層次通道內部就可以包含多種程序和結構，甚至是能直 接連接到其它不同的通道上。在 SystemC 中原始的通道主要有下列幾項如表 3.2[15]。

Channel Interface Port Method sc_in<T> read() sc_out<T> write() sc_signal<T> sc_signal_inout_if

sc_inout<T> read()，write() sc_in<T> read() sc_out<T> write() sc_buffer<T> sc_signal_inout_if

sc_inout<T> read()，write() sc_fifo_in_if sc_fifo_in<T> read()，nb_read() sc_fifo<T>

sc_fifo_out_if sc_fifo_out<T> write()，nb_write() sc_mutex sc_mutex_if sc_port< sc_mutex_if > lock()，trylock()，

unlock() sc_semaphore sc_semaphore_if sc_port<

sc_semaphore_if>

wait()，trywait()，

postit() 表 3-2 原始通道種類列表

SystemC 元件和元件之間連線的通道會取決於設計者所使用的埠上宣告的 介面而有所差異，不同的通道得透過不同的介面才能進行存取，而介面的使用也 會跟埠的宣告相關，最後元件和元件間資料存取所提供的方法就是看該通道所能 提供的方法，這部份就跟軟體設計中的使用者介面的概念是相同的。至於多層次 通道部分最廣為人知的就屬 ARM 公司的系統匯流排 (AMBA) 中的高效能匯流 排和周邊匯流排，另外一個則是時脈專用的 sc_clock。

3-2 SystemC 設計階層介紹

由於晶片設計越趨複雜化，甚至得將系統整合進單一系統晶片，這也導致設 計者在進行晶片設計時不能在沿用以往的較低階層的設計語言或技術，得將設計 的抽象階層向上提升。圖 3.5 為晶片設計各階層的示意圖。

Specification Level

Behavior Level

RTL

Logical Level

Transistor Level

Physical Level

Abstraction Level

圖 3-5 晶片設計各階層示意圖

在以往的晶片設計中較廣為使用的是硬體描述語言，此語言的設計階層是屬 於暫存器傳輸階層，會使用到這種設計方式也主要是因為晶片設計的複雜化，以 及功能的多樣化所致。設計者在進行晶片設計時透過用語言描述般的抽象化設計 方式來進行設計，不過這種設計方式卻已經不足以應付目前系統晶片的設計，因 此便有了 SystemC 的產生並且將設計的階層再度向上提升。下圖為不同設計語 言所包含的設計階層的比較圖[14]。

圖 3-6 不同設計語言所包含的設計階層比較圖

Verilog 和 VHDL 為以往在進行超大型積體電路設計時廣為被人所使用的設 計語言，不過面對現在系統晶片和嵌入式系統這種高複雜度的設計時，使用上述 兩種設計語言進行系統設計的複雜度已經高出設計者所能接受的範圍。因而產生 出 System Verilog 和 SystemC 兩種系統設計語言，不過 System Verilog 的設計方 式仍較偏向以往的硬體描述語言的方法，然而 SystemC 卻能夠達到軟硬體整合 式的設計能力並且透過交易階層 (Transaction Layer Modeling) 的高抽象化設計 概念降低設計上的複雜度，因此在下一個世代的設計語言競爭中 SystemC 仍是 比 System Verilog 更能被系統設計者接受以及使用。

由於 SystemC 是用來進行系統設計所使用，因此在 SystemC 的使用上和設 計階層的定義上也出現兩種不同的組織。其中之ㄧ的 Open SystemC Initiative (OSCI) 主要是將 SystemC 運用在嵌入式軟體的開發上。由於嵌入式軟體的開發 會和所使用的硬體效能和記憶體容量等硬體平台所擁有的資源有著很大的關連 性，因此在進行嵌入式軟體設計時大多都將開發版為依據再進行設計。OSCI 此 組織將 SystemC 的交易階層分成以下三大層[16-21]：

Programmers View (PV)：

這階層所採用的設計方式為單純的程式呼叫 (function call) 並且夾帶少許 的時間資訊，此設計階層可被視為是無時間 (Untimed functional：UTF) 概念的 行為層描述。由於不需要具備精確的時間以及其它的相關資訊，因此這個階層可 以算是 SystemC 所擁有的階層中模擬速度最快，並且也算是唯一可以支援作業 系統與 SystemC 所設計出的硬體平台進行協同模擬的設計階層。

Programmers View with Time (PV+T)：

這階層所設計出的模組會同時擁有高階層的 PV 和其它較低階層的存在，因 此這種模組可以隨時切換是否需要具備明確的時間。在 PV 的部份仍然會是以事 件等行為化的方式作為驅動條件，而較為低階且需要精確時間的部份則是由內部 的狀態變化驅動。這種階層的設計目的是在於不需要去改變其模組行為部分的功 能描述，便可以被精確時間或是高抽象化兩種不同階層所用。

Cycle Callable (CC)：

在這階層的設計方式就需要有包含較為精確的時間資訊，在模組行為部分的 描述時就會是屬於精確週期計算 (cycle-count-accurate) 的時間概念 (Timed Function：TF) 或是完全的精確週期 (cycle-accurate) 兩種中的其中一種。而這個 CC 階層仍然是屬於交易階層中的一部分，和暫存器傳輸階層最大的差異是在暫 存器傳輸階層仍是透過精確針腳訊號 (pin-accurate) 為主的方法，但是 CC 階層 的描述方法卻是使用更為高階層的埠來當作其介面。再來就是 CC 階層可以容許 多組訊號同時一起啟動在同一次的跳動 (clock edge)，這種技巧在 SystemC 是屬 於一種將多組訊號綑綁在一起並再同一時間運作，這種傳輸方式被稱之為傳輸 (transfers)，因為有這些技術上的提升所以 SystemC 在模擬執行效率上遠勝於以 往硬體描述語言所使用的暫存器傳輸階層。

另一個組織 Open Core Protocol – International Partnership (OCP-IP) 則是將 SystemC 著重在系統平台中硬體整合的部分。與 OSCI 一樣 OCP-IP 在 SystemC 的設計上也擁有自己對於各階層的切割和定義，其主要目的是在於讓電子設計自 動化的設計廠商能在 SystemC 這種多層次的系統設計語言中有個明確的切入

點，讓設計廠商能在晶片設計和結構設計上能提供一種更為方便的設計工具。其 主要分成四種階層：資訊層 (Message Layer)、交易階層 (Transaction Layer)、傳 輸階層 (Transfer Layer) 和暫存器傳輸階層 (Register Transfer Level)。

資訊層(L-3)：

此設計階層是在模組設計時的最高抽象化階層，主要是用於驗證所架構出的 系統在概念上是否正確，並且提供一個系統設計架構讓設計者可進行得和失 (trade-offs) 之間尋平衡點探討的系統平台。此階層主要是透過事件驅動並且無時 間概念。

交易階層(L-2)：

此階層的模組設計主要是給系統晶片架構所用，它會夾帶一些硬體的詳細資 訊，可用作於軟硬體切割和協同模擬的分析所用。此階層可連接一些較低階層的 硬體模組，甚至可以整合作業系統來進行模擬 (emulate)。

傳輸階層(L-1)：

此階層主要是被設計者用來執行較為詳細的模組運作，更可以用於模組的程 序測試，以提供一個具備精確週期的測試模擬。

暫存器傳輸階層(L-0)：

此階層在 OCP-IP 定義的交易階層中屬於第零階層，如同以往硬體描述語言 中的 VHDL 和 Verilog 一般建模技巧主要是透過針腳 (pin) 和位元 (bit) 驅動，

和交階層第一層的傳輸層差異比較如下表 3.3

設計階層 暫存器傳輸層(L0) 傳輸層(L1)

模組之間的溝通方法 訊號線 完整的傳輸介面

模組的啟動方式 訊號驅動 事件，變數和函式

模組與連接線交換訊息 的方法

與訊號線的介面上的資 訊交換

透過通道的函式呼叫 (function calls) 表 3-3 暫存器傳輸層與傳輸層的比較表

從上表便可看出傳輸階層的設計方式比以往的暫存器傳輸階層的設計方式 更為抽象化，也因此能大幅降低設計上的複雜度和提升模擬的效率。

OCP-IP 所定義的各階層之間是有所關連性的，從上面的介紹我們可以看出 一筆資訊的傳輸會是由多筆交易所組成，而一筆交易又是由多次傳輸所完成，最 後每筆傳輸更是由多次的暫存器傳輸所達成，由此就可看出 OCP-IP 所定義 SystemC 各階層時是透過硬體運作和傳輸概念所設計出的。經過上述將 SystemC 用於軟體設計和硬體整合各自對於 SystemC 階層的切割和定義後，下圖便是 SystemC 真正的分層架構圖如下圖 3.7。

圖 3-7 SystemC 分層架構圖

上面所介紹的是屬於 SystemC 所擁有的不同的設計階層，而在實際運做上 是透過所謂的應用程式介面 (Application programmer interface：API) 來進行動 作，而 SystemC 的應用程式介面主要是由使用者應用層 (Application/User Layer)、協定層 (Protocol Layer) 和傳送層 (Transport Layer) 三大階層所組成。

其主要功能和目的如下：

使用者應用層：

主要為提供設計者在進行資料存取設計時有現成可使用的函式，如表 3.2 中 的功能部分 (Method)，有如網路架構中七層協定中最高的應用層，此部份只會

提供現成可使用的函式，但是卻不會描述到該函式是如何運作。

協定層：

這階層主要是用來定義在進行 SystemC 設計時所使用的埠的設計階層和介 面 (interface) 的定義，不同的協定層所使用到的介面和設計階層也會不同。

傳送層：

此部份為實際在進行傳輸時的實作部分，如同網路架構中的傳送層一般，主 要用途就是為使用者應用層提供現成可使用的函式。

3-3 SystemC 混合階層的設計方式

在經過以上 SystemC 的介紹後，便能得知透過 SystemC 來進行系統設計時 可以利用不同的設計階層來對應不同的設計方式，是一種極具彈性的設計語言。

雖然有許多不同設計階層但 SystemC 也並非只能在同一階層進行設計，甚至能 達到混合階層的設計方式。舉例來說若是我們想載入作業系統進行嵌入式系統的 模擬測試，在進行這種類型的模擬就必須將設計階層都提升到 PV 的等級才足以 應付，不然在模擬時間部分必定會非常之久。此系統硬體部份會以 ARM 公司的 高效能匯流排和處理器為主要核心，此兩部分在 SystemC 的設計階層中是屬於 PV+T 的設計階層，雖然 PV+T 階層可轉換成 PV 來使用但是我們所開發的 PV 階層的周邊零件卻會因為協定 (protocol) 的不同導致無法直接與 ARM 匯流排進 行連接。此時就會需要透過某種零件作為橋接器 (bridge) 來連接兩邊不同的設 計階層或是協定，交易器 (Transactor)就是這種用途的零件。在 CoWare 公司所 開發的 SystemC 系統整合開發工具 Platform Architect 也將 ARM 匯流排及 OCP 匯流排用的交易器一併加入他們的工具之中。就如它本身的名稱一樣交易器的功 能就是用於不同協定或是設計階層之間的轉換工具，例如將原本是以高效能匯流 排 (AHB) 協定程序運作的一方轉換到 PV 所適用的協定，此種概念當然也適用 於周邊匯流排 (APB)。此交易器的使用方法當然也非常靈活，可以用於連接單 一零件的一對一方式，或是先連接到 PV 專用匯流排後再透過匯流排去連接零

件，如圖 3.8。將兩種方式整合的連接方法如圖 3.9，在這篇論文中我們的實驗平 台也將以圖 3.9 此種架構方式來進行設計。而此交易器甚至會在下個章節的錯誤 注入方法中扮演著最為關鍵的角色。

ARM CPU

AHB

IP Transactor

IP

ARM CPU

AHB

IP Transactor

IP Transactor PV

ARM CPU

AHB

IP Transactor

IP PV

APB ARM

CPU AHB

IP Transactor

APB

IP Transactor

(a) (b)

(c) (d)

圖 3-8 交易器連接示意圖

圖 3-9 混合階層式系統設計架構

經過上述的介紹後就可了解 SystemC 是一個可以提供最為方便的軟硬體系 統設計時的溝通橋樑，進而提升系統設計上的效率。雖然越高階層的設計越能降 低複雜度和提升模擬效率，但卻會和實際製程出來的結果產生越大的差異，這部 份就需要有自動化設計工具的廠商提供更為完整的合成器讓設計者在進行高階 層的設計時也能隨時掌控在低階層時所會呈現的結果，為了解決系統晶片或嵌入

式系統等高複雜度的問題不只是在設計上的技術要提升，自動化設計的輔助工具 也需要一併提升才能夠足以應付這些複雜的問題。

第四章 錯誤注入方法開發

由於晶片設計的複雜度大幅提升，因此我們採用了 SystemC 這種高抽象化 的系統設計語言來進行設計，但這只能降低設計時的複雜度。在進入到深次微米 製程技術的這個時代，在受到輻射線或是電磁波干擾等外來環境的影響時晶片的 抵抗力都大幅下降，因此我們必須要能夠提出一種策略來提昇晶片的強韌度，而 這也就是所謂的容錯設計。不過現今的系統晶片是屬於將軟體和硬體整合到單一 晶片的高複雜度系統設計方法，因此我們在進行容錯設計時面對到的不只是單一 的零件，而是一個完整的系統。假使我們想對整顆系統晶片都進行容錯機制保 護，其影響不單只是效能的下降和體積增加，背後更伴隨著大幅的成本提升，上 述這幾項缺點都是不符合系統晶片的特性和設計目的。因此在進行容錯設計之前 我們會先對此系統進行故障模式分析 (FMEA)，找出該系統中脆弱的部份後再依 照其敏感度和危險性排出名次，最後我們會將成本和效能以及嚴重性代入進行考 量後找出影響最嚴重的部分並加入容錯功能的設計。為了能進行故障模式分析，

首先我們必須提出一種有效的錯誤注入方法，並且進行大量的錯誤注入實驗才能 確保故障模式分析的可靠度。在這篇論文中我們提出了一種適用於 SystemC 高 抽象化階層使用的錯誤注入方法，此錯誤注入方法採用的啟動條件不同於以往的 時間驅動方式，此錯誤注入方法採用的是事件驅動方法。此事件驅動的錯誤注入 方法更是能夠在進行故障模式分析時達到最佳的效率，這部分我們會透過實驗加 以證明。

Fault Injection Module injected faults Emulated Faults Transmission information

access

Operational process modify Short to supply / gnd ˇ

Transient single bit flip ˇ Storage module data

variation

ˇ

Module operation disorder

ˇ 表 4-1 系統階層的錯誤模型列表

上面的表 4-1 是我們錯誤注入模組所用的錯誤模型，由於我們開發出此錯誤 注入方法主要是針對整個系統平台為目標，所以在選擇錯誤注入模組所適用的錯 誤注入模型時也必須以系統的角度切入來進行考量。現在的系統平台多數是透過 矽智產的零件加以整合來進行架構，在錯誤注入方法部分我們不能再像以往去修 改到零件內部的功能，此種侵入式修改的作法對目前以矽智產架構出系統平台的 系統設計方法而言以不再適用。因此我們所提出的錯誤注入方法所採取的是屬於 非侵入式的方法，我們將採用替換在零件間連線的模組或是連線的方法，這種作 法將不會影響到原本的系統運作並可達到錯誤注入的功能。由於我們採取的是替 換或是改變連接的作法，所以我們的錯誤模型主要針對的就是零件之間的訊號傳 輸或是運作程序等部分。以下我們將對表 4-1 的四種錯誤模型分別進行說明：

1. 短路 (Short to supply / gnd)：

由於製程的進步晶片體積大幅縮小，這也倒致元件之間的連線也變的更加細 小，因此很容易就會產生接地或是接到來源端等短路問題。

2. 暫時性的單一位元翻轉 (Transient single bit flip)：

此類型主要是因為外來的輻射線或是電磁波等非本身的能源照射所產生的

結果，受到外來能源的照射更會導致元件中的暫存器或是運算部分產生短暫性的 位元翻轉。

3. 儲存資料模組的資料出錯 (Storage module data variation)：

此種類型與前者相似，都是受到輻射線等自身以外的能源所造成的干擾，不 過此種錯誤類型主要是針對儲存用的零件，其主要會發生在隨機存取記憶體 (Random Access Memory：RAM)之上，此類零件在嵌入式系統中也算是不可或缺 的重要零件，更是因為製程進步體積縮小而造成錯誤發生敏感度提升的主要零件 之ㄧ。

4. 運作混亂 (Module operation disorder)：

此種錯誤類型主要是當元件內部的有限狀態機或是流程控制程序出錯而導 致的運作混亂，例如讀寫程序的顛倒或是透過匯流排溝通時的溝通協定順序錯 亂。

表 4-1 中的前三項：訊號短路、單一位元翻轉和儲存資料模組的資料出錯，

上述三者都是屬於修改零件之間傳輸的資料為目的的錯誤類型。而最後一類的模 組運作混亂則是建立在替換交易器 (Transactor) 模組的條件下達成，因為交易器 是用於連結兩種不同匯流排或是兩種不同協定的零件，所以其內部必然有著兩種 不同協定之間的轉換，也就是所謂的運作程序。我們只需要替換上我們自己所設 計的錯誤注入專用的交易器模組，在透過擷取並修改傳輸時操作資訊的動作便可 達到表 4-1 所記載的四種錯誤模型，由於交易器都是屬於同樣規格及運作方式的 模型，因此我們的錯誤注入模型是直接將此交易器的功能移植，之後再加上我們 所提出的錯誤注入模型便能夠達到我們所預期的結果。上述我們的錯誤注入方法 和錯誤注入模型將應用在 CoWare 的 Platform Architect 之上，並且透過 ARM 處 理器及 ARM 匯流排為主的系統架構加以實踐。會這樣做主要是因為我們是以系 統晶片層級為設計平台，在這種平台的架構中匯流排將是不可會缺的零件之ㄧ，

在這份研究中我們將以 AMBA 做為我們主要的系統匯流排，因此我們會將我們 的錯誤注入方法論應用在 ARM 為基礎的系統平台之上。

4.1 錯誤注入流程

由於我們現在所面對的是一個系統平台，而不是單一的硬體平台，並且我們 主要採用的是事件驅動的錯誤注入方法，因此在正式進行錯誤注入的模擬之前我 們會對此系統平台進行一次完整性或是條件式的資料收集。所謂的條件式資料收 集主要是針對已經確定啟動條件組合的使用者而用，透過這種方式我們只需要收 集其事件相關的資訊以精簡資料收集時的資料量和時間。之所以會進行此動作主 要是將收集的資訊作為錯誤注入時的啟動條件，其流程圖如下圖 4-1。

圖 4-1 錯誤注入流程圖

如上圖所示，第一步驟會先進行資料的收集稱之為 Operational Profile，收集 完的事件會被步驟二作為錯誤注入的啟動條件。在判別是否啟動錯誤注入的運作 中首先會進行核對來確認是否該啟動錯誤注入程序，假使目前的條件就是錯誤注 入的啟動條件的話，錯誤注入模組便會進行錯誤的注入。當錯誤注入結束後會交 由下一個程序來判斷此錯誤是否屬於持續性的錯誤類型，是的話便會再下一次此 零件運作時進行錯誤注入，否的話則會是再次進行判斷是否有啟動錯誤注入的事 件，若是沒有的話則會交由最後的一項程序判斷此次模擬是否結束，結束後資料 收集零件便會將結果進行收集並做為分析時的依據。以下我們將各別對步驟一與

步驟二的方法進行講解：

步驟一：

步驟一主要是進行資料的收集，此步驟主要是透過一顆資料收集模組 Operational Profile Module (OPM) 來進行資料收集，此模組主要是將交易器為主 體加上資料收集功能後衍生出的零件其架構如圖 4.2(b)。此零件在交易器原有的 協定轉換之上加入了一些事件以及資料收集的程序，後面的錯誤注入模組也都是 以交易器為基礎所衍生出來的特殊用途零件，以便我們能進行完整的錯誤注入實 驗，圖 4.3 為此方法的虛擬程式碼 (pseudo code)。

圖 4-2 錯誤注入模組及其架構圖

由左到右分別是 4.2 (a)Transactor、4.2(b)OPM、4.2(c)FIM

while(1) {

int Master_ID; //所需資訊

fstream Operational_profiler_1(“Data1.txt”,ios::app); //將資料寫到對應檔案 fstream Operational_profiler_2(“Data2.txt”,ios::app); //將資料寫到對應檔案 port.getReadDataTrf(); //判斷是否有Read Data的Transfer 進行

Master_ID =port.getMasterId(); //取得目前使用bus的Master ID if(Master_ID == 1){

Operational_profiler_1<< port.getAddress()<<endl; //得到Address的資料

} //並寫入檔案

if(Master_ID == 2){

Operational_profiler_2<< port.getAddress()<<endl;

}

Protocol transform(); //將AHB slave端的protocol 轉成 PV send Transfer(); //呼叫set/get Read data的function Operational_profiler_1.close();

Operational_profiler_2.close();

wait();

}

圖 4-3 資料收集模組的虛擬程式碼

上圖所示的虛擬程式碼主要功能是將系統運作時不同主人端元件的位址資

訊分別儲存，透過不同的 Master_ID 我們能夠得知此次傳輸時的位址資訊是屬於 哪個主人端的。由於一個系統會有多顆零件而同一顆零件也可能擁有多種不同的 埠 (port)，其中更是包含主人端或是僕人端，因此我們在進行第一步驟的資料收 集時就直接將資料分類動作也包含在其中，以此來提供錯誤注入啟動條件的設定 者有更明確的啟動條件，更能作為接下來故障模式分析時重要的分析資訊。

步驟二：

此部分主要就是進行錯誤啟動條件的比對及錯誤的注入，其架構圖如圖 4.2(c)，此零件也是以交易器為主所衍生出的錯誤注入專用零件，主要是將原有 的協定轉換再加上了事件核對以及錯誤注入兩大部分。啟動條件中的事件種類主 要有以下幾種表 4.2，這些事件是以 ARM 公司的系統匯流排的運作為基礎提出 的啟動條件。在我們提出的錯誤注入方法中可以透過單一事件啟動錯誤注入，更 能夠透過組合事件來進行錯誤注入，關於事件驅動錯誤注入方式的探討我會在下 一個小節加以說明。

Type Value Address 32 bit value

Type Idle、Write、Read AccessSize 8、16、32、64

Group Single、BurstStart、BurstCont、BurstIdle

BurstLength WRAP4/INCR4、WRAP8/INCR8、WRAP16/INCR16、INCR BurstWrap INCR、WRAP

HPROT Opcode、Data、ProtectionType、Bufferable、Cacheable ReadData Int value

WriteData Int value MasterID Int value

表 4-2 事件項目表

圖 4-4 錯誤注入模組虛擬程式碼

上圖是錯誤注入模組的虛擬程式碼，上面的虛擬程式中錯誤注入的啟動條件 是屬於事件組合的類型，此組合事件是由表 4.2 中的傳輸型態 (Type)、傳輸位址 (Address) 以及主人端編號 (MasterID) 三種類型的事件組合作為錯誤注入的動 條件，當此事件發生時錯誤注入模組就會進行錯誤的注入程序。由於 CoWare 的 Platform Architect 將 Transactor 模組分成兩大類，分別是主人端用和僕人端用，

因此我們也分別將之實踐出資料收集和錯誤注入等功能。由於主人端所能掌控的 資訊較僕人端來的多，因此主人端的錯誤注入模組所能套用的錯誤注入模型相較 於僕人端會有更大的發揮空間，這也是我們往後研究的重點之ㄧ。

4.2 事件驅動錯誤注入方法

在這篇論文中我們提出了一種透過事件驅動來進行錯誤注入的方法，當然在 這之前也有許多研究者提出了事件驅動的概念[9]，但是那些事件驅動的概念應 用在目前的複雜系統上可能不太適用，因此在這篇論文中我們將對我們所提出的 事件驅動方法給個較為明確的解釋和使用方法。透過上面的表 4.2 能夠看到我們 所擁有的事件種類，由於我們此錯誤注入方法是用在嵌入式系統或是系統晶片這 些類型的平台上，而這些平台上都會需要透過系統匯流排來進行資料傳輸。因此 表 4.2 的各項事件定義主要是透過 ARM 系統匯流排在傳輸資料的過程中會出現 的資訊來進行定義，這些資訊中其實就包含著匯流排將進行運作的方式或是類