中 華 大 學

中 華 大 學 碩 士 論 文

題目：在SystemC設計平台上開發多層級的 錯誤注入工具及系統驗證流程

Multiple-Level Fault Injection Tool Development and Verification Flow in SystemC Design Platform

系 所 別：資訊工程學系碩士班 學號姓名：M09502045 彭建閔 指導教授：陳永源 博 士

中 華 民 國 九十七 年 八 月

中文摘要

隨著製程技術進展至深次微米時代，晶片內可放置的電晶體數目越來越多，

因此可以整合越來越多的功能至單一顆晶片中，形成目前最流行的系統晶片 (System On Chip)設計概念。但是晶片密度上升的同時，卻可能會因為電磁波或 輻射線的干擾而造成系統發生可靠度的問題。為了保護系統晶片不會因為這些干 擾而造成嚴重的損害，需要在設計的過程中加入容錯設計(Fault Tolerant Design) 的考量，藉此提升系統晶片的可靠度。但是加入容錯設計後會造成系統設計及驗 證複雜度提昇的問題，為了解決複雜度的問題我們採用了更高抽象層級的語言去 描述系統像是 SystemC。在加入容錯設計之前，設計者必須要先藉由錯誤注入 (Fault Injection)的方法以了解原始系統中對於干擾與雜訊較敏感的部分，避免增 加過多的冗餘。然而進行錯誤注入為一複雜且繁瑣的過程，此時就需要有自動化 的工具幫助我們進行大量的錯誤注入模擬實驗，來驗證最後的結論是否正確。

本篇論文針對 SystemC 的設計平台開發了一個多層級的錯誤注入工具及系 統驗證流程。使用者可以對錯誤注入模組(FIM)內的參數快速地進行設定並收集 模擬實驗的結果。除此之外，將事件驅動錯誤注入的概念整合至工具設計流程 中，讓使用者在錯誤驅動方式上能有更多樣性的選擇，並可以利用本論文所提出 的事件樹，分析特定的事件對系統可能造成之影響。透過 CoWare Platform Architect 所提供的 commands，成功地建立起錯誤注入工具與 CoWare Platform Architect 之間的自動化流程。將錯誤注入工具應用在 FMEA 的分析上，輔助 FMEA 執行時的資料收集並減少收集資料要花費的時間。使用這套自動化工具可 以減少錯誤注入模組的設計複雜度、時間、以及增加設計的正確性。

在本篇論文，會說明錯誤注入工具針對不同的設計層級所使用的錯誤注入方 法、以及工具的設計、操作流程。並設計了三種實驗，分別是：驗證工具產生出 來的錯誤注入模組其功能的正確性、比較時間驅動錯誤注入與事件驅動錯誤注入 方法的有效性以及將錯誤注入工具應用在FMEA 之分析。

Abstract

As the chip fabrication enters the very deep submicron technology, system-on-chip (SoC) can contain a large number of transistors and integrate more and more functions into a chip. SoC could encounter the reliability problem due to the increased likelihood of faults or radiation-induced soft errors. Thus, it is essential to employ the fault-tolerant techniques in the design of SoC to protect SoC from faults and guarantee the operational reliability. The utilization of fault-tolerant techniques could lead to the increased complexity in design and verification. Thus, we need to adopt the behavioral level or higher level of abstraction to describe/model the SoC, such as SystemC. We need to utilize the fault injection approach to locate the weakness of system before insert fault-tolerant techniques into the system, avoiding the addition of redundant circuits.

In this thesis, we develop a multiple-level fault injection tool and verification flow in SystemC design platform. The user can set the parameters of the fault injection module (FIM), and collect the result of simulation rapidly. In addition, we integrate the event-driven fault injection concept into the design flow for supplying the various methods of fault injection, and utilize the event tree proposed in this thesis to analyze the effect of the specific event in the systems. We build an automatic design flow by employing the commands provided by CoWare Platform Architect.

The fault injection tool can assist designer in collecting information for FMEA procedure, and decrease the complexity and time of design, and increase the accuracy of validation.

In this thesis, we propose a fault injection methodology, and develop a fault injection tool for various modeling levels of SystemC, and conduct three kinds of experiments to verify the accuracy of FIM, compare time-driven with event-driven in

effectiveness of fault injection, and apply to FMEA to demonstrate the power of the tool.

誌謝

本篇論文能夠順利完成，特別感謝指導教授陳永源老師的指導，在課業、研 究及生活上遇到的困難，都能給予我最大的協助。另外也特別感謝父母、家人及 女友林瑩姿的全力支持，讓我能無後顧之憂的完成學業。

這兩年的研究生活，感謝多位學長、同學、朋友及家人一路上的陪伴與支持。

讓我在求學過程中，學習到了很多寶貴的經驗，也幫助我在迷惘、困惑時能迅速 回到研究的道路上。

最後，感謝實驗室的學長-呂昆龍、陳志偉、張坤鈞、石孟儒、吳耿偉、黃詩 芩、吳名原等人的指導，及同學汪碩彥、許書豪、陳信宇、周義翔、胡淳皓還有 學弟呂凱平、宋東彥、許仲賢、汪宜強、柯祥霖在實驗上的討論與鼓勵。謹將本 篇論文獻給師長、家人、女友、同學及朋友們，共同分享這份得來不易的榮耀。

彭建閔 謹致 中華民國九十七年八月於新竹

目錄

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

第一章 簡介 ...1

1-1 背景介紹 ...2

1-1-1 錯誤注入簡介...2

1-1-2 SystemC簡介 ...7

第二章 相關研究、研究動機及問題描述 ...13

2-1 相關研究 ...13

2-2 研究動機 ...21

2-3 問題描述 ...22

第三章 不同層級的錯誤注入方法 ...25

3-1 Bus Cycle Accurate Level...25

3-2 Untimed Functional level...27

3-3 Timed Functional Level：Transactor的錯誤注入方法 ...30

第四章 錯誤注入工具開發流程 ...33

4-1 CoWare Platform Architect名詞及命令(Commands)介紹...33

4-2 錯誤注入工具設計流程簡介...38

第五章 整合不同環境下的工具操作流程 ...45

第六章 實驗環境設定及實驗結果 ...51

6-1 單一事件以及組合事件驅動錯誤注入之模擬實驗...52

6-2 時間驅動及事件驅動錯誤注入命中率之比較...54

6-3 透過錯誤注入工具輔助FMEA進行時的資料收集 ...55

第七章 結論與未來工作 ...58

參考文獻...59

圖表目錄

圖1- 1 Weibull失敗率函式分佈圖...6

圖1- 2 SystemC架構圖...8

圖1- 3 SystemC模組示意圖...9

圖1- 4 埠、介面及通道之連接架構圖 ...10

圖1- 5 SystemC分層架構示意圖...11

圖2- 1 System-Bus錯誤注入模組架構示意圖...16

圖2- 2 錯誤注入工具架構圖 ...18

圖3- 1 BCA層級的錯誤注入模組示意圖 ...26

圖3- 2 TLM Untimed Functional Level的錯誤注入模組示意圖...27

圖3- 3 Event Check內部架構示意圖...28

圖3- 4 Transactor錯誤注入模組架構示意圖 ...31

圖4- 1 錯誤注入工具之設計流程示意圖 ...39

圖4- 2 事件組合一覽表 ...44

圖5- 1 工具操作流程圖 ...45

圖5- 2 Script Generator操作介面...46

圖5- 3 驗證及錯誤注入工具操作介面 ...47

圖5- 4 事件驅動輸入介面 ...48

圖5- 5 Script產生器操作步驟...49

圖5- 6 錯誤注入工具之事件驅動操作步驟 ...50

圖6- 1 實驗平台架構圖 ...51

圖6- 2 單一事件驅動錯誤注入之實驗結果 ...53

圖6- 3 組合事件驅動錯誤注入之實驗結果 ...54

表格目錄

表1- 1 硬體錯誤注入與軟體錯誤注入比較表 ...4

表1- 2 三種不同程序比較一覽表 ...10

表1- 3 SystemC六種描述階層比較表...12

表2- 1 失效模式與效應分析表 ...19

表3- 1 Event Check的輸出狀態選擇表...29

表3- 2 AMBA Bus訊號總表 ...32

表4- 1 名詞解釋表 ...33

表4- 2 命令彙整表 ...38

表6- 1 元件記憶體對照表 ...52

表6- 2 時間驅動和事件驅動錯誤注入命中率之比較表 ...55

表6- 3 50x50 矩陣相乘之FMEA分析結果 ...56

表6- 4 快速排序法之FMEA分析結果 ...57

表6- 5 不同測試程式之FE、SDC、CD/IT、DL及NE機率...57

第一章 簡介

隨著現在的科技越來越進步，很多產品都要求面積要越做越小，速度要越來 越快。以前的產品是利用許多單晶片透過 FPGA 互相連接溝通，這樣的作法不 但會造成產品面積過大且速度也會因為晶片之間的溝通而降低。但隨著製程技術 進展至深次微米時代，一顆晶片中可放入的電晶體數目越來越多，因此可將越來 越多的功能整合到單一顆晶片中，形成目前最流行的系統晶片(System On Chip) 設計概念。但晶片密度上升的同時也帶了許多額外的效應，像是發生外部輻射線 的干擾、電壓突波、漏話干擾(crosstalk)…等的機率也跟著上升。當這些機率提 高至不可忽視的程度時，就可能會造成系統晶片(System On Chip)發生暫時性的 錯誤。為了保護系統晶片不會因為這些錯誤而造成嚴重的損害，需在設計過程中 加入所謂容錯設計(Fault Tolerant Design)的考量，其意謂著在系統晶片中增加容 忍錯誤的機制，藉此提升晶片的可靠度。

另一方面，在晶片的設計平台演進上，一般熟悉用於晶片設計的硬體描述語 言(Hardware Description Language)以 VHDL(Very High Speed Integrated Circuit HDL)與 Verilog HDL 為兩大主流。但因為其主要的設計層級皆以暫存器轉換階 層(Register Transfer Level, RTL)為主，因此隨著系統晶片的快速發展，晶片內部 的硬體架構越來越複雜，這兩種設計語言已逐漸無法應付如此複雜的系統晶片架 構。因此更高階層的描述語言－SystemC－被提出且逐年愈加受到重視。透過 SystemC 所擁有的矽智產(Intellectual Property)整合以及模組重複再利用(Module Reuse)的特性，讓設計者可以快速的完成系統晶片的初步設計。但其系統本身的 驗證仍然需要花費許多的時間，再加上與容錯設計的整合，使得系統晶片的驗證 變得越來越複雜與耗時。因此，一套完善的驗證流程勢必將成為系統晶片設計中 不可或缺的一環。

在將容錯設計加入至原始系統前，設計者必須要先了解原始系統中對於干擾 與雜訊較為敏感的部分，因此需藉由錯誤注入(Fault Injection)的方式來達成此目

的。如此一來可以避免在系統中因加入容忍錯誤的機制而增加過多的冗餘，藉此 降低系統開發的成本。然而執行錯誤注入為一複雜且繁瑣的過程，需要進行大量 的錯誤注入模擬實驗。因此，我們希望能夠開發出一套自動化的錯誤注入工具，

幫助設計者加速錯誤注入實驗的完成，且蒐集實驗的結果讓設計者可以利用這些 資料進行後續的相關分析，進而輔助設計者判斷最佳的系統容錯設計方式。

1-1 背景介紹

以下將針對各種不同的錯誤注入方法作介紹，因為本篇論文提出的錯誤注入 工具是以 SystemC 的設計平台為基礎作開發，因此也會對 SystemC 的架構、溝 通介面及溝通方式作一簡單的介紹。

1-1-1 錯誤注入簡介

當系統要加入容錯系統設計時，若沒有先經過錯誤注入，判斷系統中真正需 要加入容錯機制的地方，有可能會將成本投入在對提昇系統的可靠度沒有太大幫 助的地方。另一方面，當容錯系統設計完成時也需要藉由錯誤注入實驗幫助我們 了解容錯機制是否有發揮功用及其有效性，並檢查是否還有需要增加容錯機制的 地方。因此不管是容錯機制還是驗證流程裡，錯誤注入都扮演著非常重要的角色。

接下來，我們將介紹目前的錯誤注入方法主要分類方式，且各自又有何優缺 點：

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

將已經設計好的系統，以晶片或是可規劃邏輯陣列(FPGA)實做出來 後，再直接進行錯誤注入。利用實際硬體實驗出來的結果，也代表著真實系 統的反應。若發現系統的可靠度不如預期且必須修改原始設計時，將會是一 個非常耗時且大幅增加製造成本的過程。其主要的實踐方法如下所列：

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

將製造出來的晶片，透過測試平台對晶片的pin 腳注入錯誤，

藉此觀察當錯誤發生時，晶片會有何種反應[1]。

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

將設計好的晶片，放置在一個特殊的平台上。此平台是事先設 計好可以產生雜訊或是輻射線的環境。測試當晶片受到雜訊或輻射 線影響時，會產生何種反應[2]。

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

利用在開發系統雛型(system prototype)時，常會使用到的硬體 輔助設備可規劃邏輯陣列(FPGA)，使用這個平台可以讓系統設計 者在上面直接進行錯誤注入。

在這三種硬體注入錯誤的技術中，晶片腳位層級錯誤注入以及輻射線照射錯 誤注入這兩種技術，除了要將晶片設計出來，還需要建置專業的錯誤注入環境，

因此需要較高的硬體成本。再加上這兩種錯誤注入技術，只能在pin 腳或是外部 環境干擾，其錯誤注入的可控制性(Controllability)相對較低，而且因為錯誤是發 生在晶片的內部，其可觀察性(Observablility)也相對較低。而硬體基礎錯誤注入 技術，因為使用可規劃邏輯陣列(FPGA)，不需經過實體晶片的製造過程，所以 其硬體成本並不像前兩項技術一樣高，而且其可控制性及可觀察性也比之前兩項 技術高。

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

此種技術是利用程式在編譯或執行的時候，執行設計好的錯誤注入軟體 程式，去修改硬體中記憶體或是暫存器內部的值，藉此讓硬體在執行時發生 錯誤。

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

在模擬基礎錯誤注入技術中，因為不像硬體錯誤注入技術一樣，需要將 晶片製造出來，也不需要建置錯誤注入環境，只需要使用硬體描述語言 (Hardware Description Language)將對應設計層級的錯誤注入方法描述出 來，所以模擬基礎錯誤注入技術在成本上是比較節省的。除此之外，模擬 基礎錯誤注入技術還可以應用在各個不同的設計層級上，像是：邏輯閘層

級（gate level）、暫存器傳輸層級（register transfer level）、甚至是更高的系 統層級（system level）及抽象層級（abstraction level）…等，只需要針對不 同設計層級去設計錯誤注入的方法。使用模擬基礎錯誤注入技術還有一個 優點是，可以在系統設計的前期就對系統的容錯能力進行測試，如此一來 就可以在最短的時間內判斷系統的容錯能力，並針對不足的部份進行修改。

此種技術是模擬器在進行電路模擬時，利用模擬器內建的指令(build-in commands)，或是在電路內加入錯誤注入的電路，在系統內實現錯誤注入的 目的。

在軟體實現錯誤注入技術、模擬基礎錯誤注入、及硬體錯誤注入技術的 比較中，模擬基礎錯誤注入擁有較高的可控制性及可觀察性，開發成本上 也比較節省，三種不同錯誤注入技術之間的比較如表1-1。在本篇論文中，

將使用模擬基礎錯誤注入技術(simulation-based fault injection)，除了此種技 術擁有較高的可控制性及可觀察性外，主要是因為 SystemC 必須執行在模 擬基礎錯誤注入上。

硬體錯誤注入 錯誤注入

技術 項目

晶 片 腳 位 注入錯誤

輻射線照射 錯誤注入

硬 體 基 礎 錯誤注入

軟 體 實 現 錯誤注入

模 擬 基 礎 錯誤注入

可控制性 低 低 中 中 高

可觀察性 低 低 中 中 高

付出成本 高 高 中 低 低

電路相似度 高 高 高 中 中

表1- 1 硬體錯誤注入與軟體錯誤注入比較表

在執行錯誤注入時，還有一個相當重要的條件，那就是錯誤類型(fault type)，

從[3]的研究中，可以了解到晶片設計在不同層級中，其注入的目標及錯誤類型 都不盡相同，因此在使用這些錯誤注入方法時，我們一定要了解其限制及應用。

以下說明幾個特別重要的參數，包括：

(1) 錯誤注入目標(fault targets)

要執行錯誤注入實驗時，首先要先決定在哪些目標點進行錯誤注入。以 本篇論文為例，因為系統是使用 IP 建置而成，我們不能對 IP 的內部進 行修改，所以錯誤注入的地點只能選在IP 之間的連線(connection)。

(2) 錯誤類型(fault type)

錯誤類型主要是用來決定錯誤注入的值，目前錯誤類型所包含的範圍相 當的廣泛，像是：Stuck-at 錯誤模組、高阻抗(High-impedance)錯誤模組、

未知值(Unknow)錯誤模組、位元翻轉(bit-flip)錯誤模組…等。在本篇論 文中是採用bit-flip 錯誤模組，利用抓取到的值隨機選取其中之一的位元 進行翻轉，藉此模擬晶片在受到輻射線照射、漏話干擾(crosstalk)、溫度 的變化…等，可能會發生的錯誤情形。

(3) 錯誤注入時間分佈模組(fault instant time distribution model)

錯誤分佈模組主要是用來決定錯誤注入的時間點，為了要模擬實際電子 產品的生命週期，在這篇論文中採用 Weibull 錯誤分佈模組[4][5]以及 Uniform 錯誤分佈模組。使用 Weibull 錯誤分佈模組可以準確的模擬出，

電子產品在生命週期中每一個點會發生錯誤的機率，主要可以分為三個 階段：burn-in、useful life and wear-out，如圖 1-1 所示。電子產品剛開發 出來的時候，經過burn-in 的階段，利用高溫、高壓先將不穩定的電子產 品淘汰；在 useful-life 階段，電子產品已經趨於穩定，因此發生錯誤的 機率較低；最後，在wear-out 階段，電子產品經過一段時間的使用後，

其內部零件以及連線逐漸老化，導致發生錯誤的機率又逐漸提高。

t1 Time t2 λ

Useful-life Wear-out Burn-in

Failur e r ate fun ction

圖1- 1 Weibull 失敗率函式分佈圖 (4) 錯誤持續時間(fault duration)

錯誤持續時間指的是錯誤從發生到消失的這段時間。因此，設定這個參 數可以決定錯誤要存在多久的時間，若錯誤存在時間大於模擬時間，則 視為永久性錯誤。

依據錯誤存在的時間長短可分為：1.暫時性錯誤(transient fault) 2.永久性 錯誤(permanent fault) 3.週期性錯誤(intermittent fault)三類。所謂的暫時性 錯誤是指經過一段時間後錯誤就會自己消失；永久性錯誤是指不論經過 多久的時間錯誤都會一直存在；週期性錯誤是每隔一段時間錯誤就會出 現。在這篇論文中，所使用的錯誤型態有暫時性錯誤以及永久性錯誤兩 種。

(5) 錯誤注入總數(numbers of total fault )

這個參數所代表的意思是在整個模擬實驗中要注入的錯誤總數，也就是 會發生的錯誤總數。

錯誤注入與FMEA(Failure Mode and Effect Analysis)之間的關係：

所謂失效模式與效應分析(FMEA)是一種預防性的可靠度設計分析技術 [6,7]，它是使用結構化的系統程序方法，及早發現產生潛在的失效模式，探討其 失效原因，及失效發生後該失效對上一層分系統、次系統和系統所造成的影響，

並採取適當的預防措施和改進方案。

進行失效模式與效應分析前，必須要先對分析目標進行大量的錯誤注入實 驗，藉此了解系統遭遇到錯誤時的反應，並收集實驗後的結果。根據大量的實驗 數據，將錯誤對系統造成的影響加以分類，分析系統遭遇不同錯誤類型時，會造 成何種影響。

錯誤注入工具在驗證流程中，所扮演著的角色：

要驗證容錯系統的可靠度，在驗證流程裡的第一步就是錯誤注入。此篇論文 中，我們開發了一個錯誤注入的工具，可以應用在所有SystemC 的設計平台上。

並 可 支 援 多 種 錯 誤 類 型(fault type) ， 像 是 ： bit-flip 、 Stuck-at 、 高 阻 抗 (high-impedance)、Unknow…等。

利用此錯誤注入工具可以幫助我們完成容錯系統驗證流程中，前半段的步 驟，也就是從容錯系統原始資料的收集、錯誤類型的設定、對 FMEA 要分析的 事件選擇其錯誤注入驅動的條件、到執行錯誤注入模擬、錯誤注入模擬後的資料 收集，這些工作皆可以藉由錯誤注入工具自動完成。在驗證流程的後半段，就可 以利用錯誤注入模組所收集到的資料，進行詳細的分析。

1-1-2 SystemC 簡介

近年來，晶片越來越往系統晶片(system-on-chip)以及嵌入式系統 (embedded system)發展，導致晶片的設計複雜度也越來越高。為了降低設 計複雜度以及提昇驗證模擬速度，由多家EDA 廠商、ARM、ST、NEC、

Motorola 等共同組成了一個組織名為 Open SystemC Initiative(OSCI)[8]，

提出了SystemC 這個系統層級的硬體描述語言。

在SystemC 的高階描述語言中，其語言架構如圖 1-2 所示：

圖1- 2 SystemC 架構圖 其核心語言的內容可分為：

(1) 模組(module)

在SystemC 的設計平台上，模組是組成一個系統最基本的元件，

模組跟模組之間使用通道彼此互相溝通(參考(2))，藉此達成系統所要 求 的 功 能 。 每 一 個 模 組 內 可 以 有 多 個 輸 入 埠 、 輸 出 埠 以 及 程 序 (Process)，其模組架構圖如圖 1-3 所示。

圖1- 3 SystemC 模組示意圖 (2) 埠(port)、介面(interface)、通道(channel)

在SystemC 的設計平台上，提供了下列幾種溝通方式，讓模組跟 模組之間能夠彼此傳遞訊息，其連接架構圖如圖1-4 所示。

(i) 埠：模組之間的溝通，最主要是透過連接埠，將模組的輸出傳送 給另外一個模組。埠可為分輸入埠、輸出埠以及輸出入埠，

再利用介面所提供的存取方法，完成資料的傳送或接收。

(ii) 介面：是用來定義通道的存取方法，舉例來說，sc_fifo 通道有兩種 使用的介面：

(a) 讀 取 用 sc_fifo_in_if() 介 面 有 read(), nb_read(), num_available(),及 data_written_event()四種方法。

(b) 寫 入 用 sc_fifo_out_if() 介 面 有 write(), nb_write(), num_free, 及 data_read_event()四種方法。

(iii)通道：是為了實現介面所定義的方法，並負責模組和程序之間的交 互運作。在SystemC 裡，通道可分為兩種，一種是原始通道 (Primitive channel) ； 另 一 種 是 階 層 式 通 道 (Hierarchical channel)。

前者像是傳統硬體描述語言裡面的連接線(wire)，能將兩個 埠直接連起來。通道內已經定義好讀取跟寫入的方法，不能

去存取其他的原始通道；後者大部分為使用者自行定義，用 來實現特定的匯流排功能，像AMBA Bus 就是現在最常見的 階層式通道。

圖1- 4 埠、介面及通道之連接架構圖 (3) 程序(process)

SystemC 的程序是被用來描述模組要進行的動作。每一個程序都 是一個獨立的單元，並且都有自己的驅動表(sensitive list)，當驅動表 內設定的變數或訊號改變了，程序才會進行動作。程序有三種不同的 型 別 ： 方 法(SC_METHOD) 、 線 程 (SC_THREAD) 以 及 時 間 線 程 (SC_CTHREAD)，表 1-2 為三種不同程序之間的比較。

程序種類 SC_METHOD SC_THREAD SC_CTHREAD 驅動方式 signal events signal events clock edge

動態驅動 next_trigger(args) wait(event) wait(event)

暫停執行 No Yes Yes

暫停後回覆 N.A. wait(event)

wait(event) wait_untill(event)

無限迴圈 No Yes Yes

表1- 2 三種不同程序比較一覽表

SystemC 為 了 因 應 越 來 越 高 的 設 計 複 雜 度 ， 根 據 其 溝 通 時 間

(communication time) 、 計 算 時 間 (computation time) 、 溝 通 方 式 (communication scheme)以及模組介面(module interface)，將描述層級概略 分為：Register Transfer Level、Clock Cycle Accurate Level、Bus Cycle Accurate Level、Timed Functional Level、Untimed Functional level 以及 Specification Level 這六種不同的層級[9,10]，其分層架構示意圖，如圖 1-5 所示。

Ac cu ra cy

T ransaction Level Mod el

Si mu lat io n Sp ee d

圖1- 5 SystemC 分層架構示意圖

隨著描述層級的提高，其描述精確度會越來越低，但是模擬的速度 會變得越來越快。接下來，我們在表1-3 彙整這六種不同階層的描述方式，

並比較各種階層的溝通時間、計算時間、溝通方式以及模組介面。

參數

描述層級 溝通時間 計算時間 溝通方式 模組介面

Register Transfer Level

Cycle Accurate

Cycle Accurate

Wire Pin-Accurate

Clock Cycle

Accurate Level Approximate Cycle Accurate

Abstract Bus

Channel Pin-Accurate Bus Cycle

Accurate Level

Time /Cycle

accurate Approximate Abstract Bus

Channel Abstract Timed

Functional Level Approximate Approximate

Abstract Bus

Channel Abstract Untimed

Functional Level

No Approximate Message-passing Abstract

Specification

Level No No Channel /

Variable No 表1- 3 SystemC 六種描述階層比較表

第二章 相關研究、研究動機及問題描述

2-1 相關研究

從SystemC推出以來，已經有越來越多的研究提出在SystemC設計平台上的 錯誤注入方法[11-17]。在此我們將針對幾篇相關的研究，探討這些研究在SystemC 的設計平台上，所開發出來的錯誤注入方法有何優缺點，並從過去的相關研究中 萃取其優點，轉而實踐在本篇論文所開發的錯誤注入及驗證工具上。

相關研究[12-14]中，設計一個錯誤注入模組(Fault Injection Module)，並擺放 在要執行錯誤注入的目標連線(interconnections)上，在不改變原始連線上的資料 型態、埠及介面連接方式下，實行錯誤注入。除了錯誤注入模組外，此篇論文還 增加了一個錯誤注入控制單元(Fault Injection Control Unit)，其主要功能是決定錯 誤注入的時間點、位置、及錯誤的值。因此，每一個錯誤注入模組都必須與錯誤 注入控制單元連接，並依循其控制訊號執行錯誤注入實驗。在[13]中已經將此方 法實踐在SystemC的不同設計層級，包括Transaction Level Model的layer1及 layer3，其連接示意圖如圖2-1所示。

圖2- 1 錯誤注入模組與錯誤控制單元連接示意圖 此篇論文中所提出的方法，其優點有：

1. 不需要修改原始目標點的模組結構。

2. 若要進行新的錯誤注入實驗，只需要修改錯誤注入控制單元。

此篇論文雖然有上述幾項優點，但仍有其不足之處：

1. 此方法的相關研究只有使用在smart card的系統上，其設計複雜度較低。

若移植至SystemC中較複雜的系統，錯誤注入控制單元也將變得更複雜。

2. 沒有提出混合多個不同SystemC的設計層級，其錯誤注入模擬實驗要如 何進行。

相關研究[15]中，提出三種不同溝通方式，分別是Bus Cycle Accurate使用的 基 本 通 道(channel) ： sc_signal ； Transaction level Models(TLM) 中 的 untimed functional level使用的sc_fifo以及timed functional level使用的階層式通道。其中階 層式通道是使用目前最常見的AMBA bus來實現階層式通道的錯誤注入方法。

[15]的作者在bus cycle accurate level、untimed functional level以及timed functional level這三種不同的設計層級上，各設計了一個錯誤注入模組(FIM)。利 用此模組，設計者可以在單一階層或是混合階層中注入錯誤，藉此驗證系統的可 靠度。

此篇論文提出了幾項新的觀念，像是：

1. 提出了三種不同的設計層級的錯誤注入方法。

2. 提出了事件驅動的觀念。對 SystemC 這種語言來說，其採用的設計層級大 多比以往還高，因此有很多設計層級沒有精確的時間週期。在此情況下，

無法利用時間準確的將錯誤注入錯誤目標點，但是事件驅動是根據事件的 發生而激發錯誤的注入，不會受到時間精確度的影響，在此種設計層級就 變的很重要了。

3. 提出了分散式錯誤注入模組的觀念。只在錯誤注入的目標點上放置錯誤注 入模組。即使是很複雜的系統，也不會因為系統的複雜度提高導致錯誤注

4. 提出了混合多個設計層級(mixed-level)的錯誤注入方法並且每一個設計層 級都可以執行多重錯誤(multiple faults)的注入。

5. 使用此篇論文提出的錯誤注入方法可以不需要修改系統模組的原始程式 碼。

此篇論文雖然提出許多創新的觀念，但仍有其不足之處：

1. 每一次的實驗都必須要針對注入錯誤的地點、錯誤的值以及錯誤的持續時 間進行修改，如果要進行大量的模擬實驗，必定會花費許多時間在設定錯 誤注入模組上。

2. 在事件驅動的部份，此篇論文只將特定的傳輸值與傳輸數作為其事件驅動 的條件，也缺乏將這兩種事件連結到真實系統的錯誤發生情形。

3. 為了實現作者提出的錯誤注入方法，在untimed functional level 需要增加一 個額外的FIFO；timed functional level 需要增加一條額外的 Bus。這些新增 加的元件會造成模擬時間的負擔，也可能造成在模擬時序上的誤差，因而 使得模擬的真實性受到影響。

相關研究[16]的研究中，針對 system bus 提出了新的錯誤注入方法，並開發 了新的錯誤注入模組(FIM)，此方法是在監控模組(Monitor) 內加入了錯誤注入的 功能。整套錯誤注入流程分為以下兩個步驟：

第一步：先執行一次沒有錯誤注入的模擬(fault free simulation)。利用監控模 組原本的監控的功能，對AMBA Bus 內部的訊號傳輸進行資料收集的動作。這 些訊號像是位址、資料或是控制訊號，而收集這些資料是為了之後要進行的錯誤 注入模擬實驗提供依據。

第二步：執行錯誤注入模擬實驗，利用第一步所收集到的資料，選擇要在哪 些特定的傳輸次數或是傳輸型態下進行錯誤注入，並根據選擇的錯誤激發條件，

在錯誤注入模組內進行相關的參數設定。舉例來說：如果要在AMBA Bus 上，

進行特定位址傳輸的錯誤注入實驗，錯誤注入模組就必須要檢查每一次 AMBA Bus 進行位址傳輸時的值，若傳輸的值等於錯誤激發的條件值，就會進行錯誤的 注入。

此方法的系統架構圖如圖2-1 所示。從圖中我們可以看到錯誤注入模組是掛 在TLM master 跟 AHB 的連線上，其連接埠(port)跟一般的模組不同，是屬於監 控連接埠(Monitor port)。作者利用這個特色，在一顆模組內同時進行資料收集以 及錯誤注入這兩種功能。

圖2- 2 System-Bus 錯誤注入模組架構示意圖

作者在這篇論文所提出的錯誤注入方法中，實踐了以下幾個值得學習的觀 念：

1. 將監控模組結合錯誤注入的功能。

2. 將 System-Bus 上的多種傳輸訊號當作錯誤注入驅動的事件。

3. 提出事件組合的觀念：可以將傳輸訊號互相結合，藉此驗證系統在某些特定 情況下的強韌度。以AMBA Bus 上的 Burst 傳輸訊號為例，當 Bus 傳輸第二 筆Burst 訊號，且 HTRANS 為 SEQ 的狀況下，才對資料進行錯誤注入。

4. 不用增加冗餘的通道。

雖然這個方法有上述幾項的優點，但仍有可改進之處：

1. 與[15]相同，花費許多的時間在設定錯誤注入模組上。

2. 在[16]中，作者雖然提出了事件組合的觀念，但卻沒有對事件之間的組合以 及實際系統上發生的情形提出相關的探討。

在相關研究[17]的研究中，作者為了驗證在系統晶片(SoC)上所作的 FMEA 是 否正確，將RTL 所描述的數位電路中作者認為較容易發生錯誤的區域標示出來，

稱為”錯誤敏感區域”(sensible zone)，並當作 SoC 內部基本的失敗點(failure point)。並利用觀察點(observation point) 去量測錯誤敏感區域上不同失敗類型 (failure mode)所造成的影響。為了讓錯誤敏感區域的失敗類型跟硬體錯誤一致，

作者將實體錯誤分成三類：區域實體錯誤、廣域實體錯誤、以及全域實體錯誤。

區域實體錯誤：多個實體的硬體錯誤影響到一個或多個邏輯閘，造成單一錯誤敏 感區域產生失敗。

廣域實體錯誤：一個實體的硬體錯誤影響到一個或多個邏輯閘，造成多個錯誤敏 感區域產生失敗。

全域實體錯誤：多個實體的硬體錯誤影響到一個或多個邏輯閘，造成多個錯誤敏 感區域產生失敗。

另外作者提出了一套有系統的驗證流程，並根據此開發流程所需的開發錯 誤注入及分析工具。其架構如圖2-2 所示。

Result Analyzer Golden DUT

Monitors for SENs

Monitors for OBSE

Faulty DUT Workload

(Testbench)

Coverage Collection

Monitors for DIAG

GUI List of Sensible

Zones

Environment builder Operational

profiler Collapser

Randomizer Fault injection

Manager

Fault list

OP Fault

Case of random fault injection Candidate

fault list

圖2- 3 錯誤注入工具架構圖 此工具主要可分成幾個重要的區塊：

1. 環境建立器(Environment builder)

主要功能為萃取跟錯誤注入活動有關的所有資料，並且建立環境中所有 需要用到的設置檔案(configuration files)以利於之後的 FMEA 執行。

2. Operational profiler(OP), Collapser and Randomizer

operational profiler 利用 environment builder 所建立的環境，收集當系統 進行無錯誤注入(fault-free)模擬時的所有相關資料。其目的在於確保當錯 誤清單產生(fault list)時，一次只會有一個錯誤被選擇。

3. Fault injection manager

其主要功能為執行所有錯誤清單內的錯誤注入活動，並收集執行結果。

4. Result analyzer

負責收集所有錯誤注入活動中所產生的結果，並自動填入進行FMEA 時 所需的分析表，如表 2-1 所示。若實驗結果所萃取出來的百分比與預估 值一致，則代表驗證成功。

失效造成的影響 編

號

零組 件名 稱

功 能

失效 模式

失效 原因

作業

模式 對零組 件本身

對其它 零件

對整個 系統

失效 偵測 裝置

補救 措施

嚴重 性分 類

備 註

表2- 1 失效模式與效應分析表 5. Monitors 與 Coverage Collection

主要用來產生並收集所有在建立coverage 測量中要使用到的相關資料，

coverage 測量是為了之後要進行的錯誤注入活動完成度的分析。

另外，在此提出的FMEA 驗證流程說明如下：

第一步：對每一個錯誤敏感區域的失敗類型進行足夠數量的錯誤注入，並在 分析的末段，使用FMEA 將 coverage 跟實驗的結果再次確認。

第二步：同時，測量測試程式(workload)在邏輯閘層(gate level)的硬體閘錯誤 覆蓋率(Fault Coverage)之效率。若錯誤覆蓋率大於 99%，則代表此步驟驗證成功。

第三步：在分析比較困難的區域或是特殊的硬體實做時，利用錯誤注入產生 器所產生的區域性錯誤進行錯誤注入。使用這種方式注入錯誤的結果，若能符合 錯誤敏感區域注入錯誤後的失敗類型，那就代表驗證成功；否則，要在 FMEA 內增加一些新近被偵測到的失敗類型。

第四步：針對廣域性以及全域性的硬體錯誤，執行選擇性的錯誤注入。使用 這種方式注入錯誤的結果，若能符合錯誤敏感區域注入錯誤後的失敗類型，那就 代表驗證成功，否則，要在FMEA 內增加一些新近被偵測到的失敗類型。

從這篇論文中，我們統整出了下列幾項優點：

1. 作者提出了一個有系統且能在系統晶片(SoC)層級執行 FMEA 分析的方法。

2. 開發了一套錯誤注入及分析工具。

在這篇論文中，作者開發了一個錯誤注入及分析工具，讓使用者可以利 用這些工具進行錯誤注入及分析錯誤注入後的結果，藉此了解系統中需要 保護的地方。

3. 提出了一個有系統的驗證流程：

在這篇論文中，作者使用他們自己開發的錯誤注入工具，在系統中注入 錯誤。並針對系統分析結果加入一些偵查錯誤(fault detection)或是容忍錯誤 (fault-tolerance)的機制，提昇整個系統可靠度。作者也將這樣的驗證流程應 用在記憶體的例子上，展示如何使用他們所提出來的方法，降低記憶體內 部資料損毀的機率。

在這篇論文中所提出的方法以及開發出的錯誤注入工具，雖然可以在正確的 目標點注入錯誤抓取實驗的結果並分析，但其方法卻有某些限制，如下所列：

1. 在本篇論文中，所標示的最嚴重的”錯誤敏感區域”是在 RTL(Register Transfer Level)上所撰寫的。一旦將這個方法移植到更高層級上，像是系統層級，”錯 誤敏感區域”的切割精細度(granularity)將會有所降低。

2. 產生的錯誤清單(fault list)只適用於 RTL 層級，一旦設計層級提高，產生出來 的錯誤清單將不再有用。

3. 利用一個系統中的 memory 元件為例來展示驗證流程及工具使用。若是將這 個的方法使用在比較複雜的系統上，在整個分析驗證以及工具的操作上也會 變得比較複雜。

從上述提出的相關研究中，我們整理歸納出一些針對SystemC 的設計平台所

有其先天不足與受到限制的地方。因此在本篇論文中，我們將設計出一套以 SystemC 為開發平台的驗證流程及開發相對應的錯誤注入工具。其目標在破除上 述研究的限制，並將其原有的優點結合到本篇論文提出的方法中。

2-2 研究動機

隨著現在 SoC 的設計越來越複雜，為了減少開發的時間及成本，必須要將 設計層級提高並使用更高層級的設計語言，像是SystemC。雖然提高設計層級可 以使系統設計複雜度降低，但是在系統驗證的部份卻沒有一套有系統且有效率的 工具能夠幫助使用者。導致在系統驗證上所花的時間，往往超出原來系統的設計 時間許多。除此之外，人工驗證還有正確性的風險，有可能會因為人為的疏失，

造成驗證的結果有誤。

為了解決這樣的問題，本篇論文中所開發出來的工具，將以達到下列幾項要 求為主要訴求：

動機ㄧ: 藉由電子設計自動化工具(EDA tool)自動產生錯誤注入模組。

從上述相關研究可知錯誤注入模組的設定步驟是非常繁瑣的。而且每一個要 進行錯誤注入的目標點，要設定的錯誤值、錯誤持續時間及觸發錯誤注入的事件 都不完全相同。因此導引出我們第一個動機：開發一套自動化的錯誤注入模組產 生器，並且提供人性化的介面讓使用者使用，期望可以降低設計者執行錯誤注入 模擬所花的時間及心力。

動機二: 工具自動產生出來錯誤注入模組，能夠使用在任何一個以 SystemC 為 設計語言所開發的系統。

隨著 SystemC 這個高階描述語言越來越普遍，相信之後會有越來越多的公 司以 SystemC 為設計語言開發出電子自動化開發設計工具(EDA tool)，例如 CoWare 公司目前就針對 SystemC 語言，開發出專屬的開發與驗證平台[18]。因

此我們希望工具所產生出來的模組必須要能夠在任何一個以 SystemC 為設計語 言所開發的系統。

動機三: 開發出一套以 SystemC 為設計語言的容錯系統驗證流程。

從現在的相關研究中，我們並未發現市面上有針對 SystemC 的設計語言所 開發的完整容錯系統驗證流程及錯誤注入工具。因此，此篇論文希望可以提供一 個完整的驗證流程，讓系統設計者可以使用這個驗證流程評估其設計的系統安全 性及可靠度，藉此了解到系統中較易因外部干擾產生錯誤的部份，並可以針對這 些部份進行安全性的強化。

動機四: 加速實驗數據的獲得及輔助 FMEA 進行時的資料收集。

為了要進行系統的 FMEA 分析，必須要執行大量的模擬實驗，並收集大量 的實驗數據，作為之後分析之用途。若是以相關研究中所提到的方法，要對一個 系統進行完整的 FMEA 必定會花費大量的時間，甚至有可能會因為人為的疏失 造成分析的結果有誤，導致設計者在判斷上會有誤差。

2-3 問題描述

以下我們將探討本篇論文在實踐上主要會面臨的幾個問題：

1. 如何擷取系統內部的資訊，並輸出成檔案？

本 篇 論 文 提 出 的 驗 證 及 錯 誤 注 入 工 具 會 與 系 統 模 擬 平 台 CoWare Platform Architect 互相結合。但因為我們提出的驗證及錯誤注入工具是在 windows 平台上開發，而 CoWare Platform Architect 需在 Linux 的系統平台 上執行。因此，我們必須要先從系統模擬平台上取得系統的相關資訊：包 括系統所包含的元件(block)、每一個元件之間的連接(connection)以及每一 個元件有哪些連接埠(port)等。將這些資料另存成檔案，並傳回 windows 系 統中，如此一來，在之後要使用錯誤注入工具產生錯誤注入模組時，才能

夠做為錯誤注入模組的輸入資料。

2. 錯誤注入模組的可移植性。

讓自動化驗證及錯誤注入工具所產生出來的錯誤注入模組，能夠使用 在任何一套以 SystemC 為主的系統模擬平台上。雖然這篇論文是使用 CoWare Platform Architect 當作系統模擬平台，但是基於上述的理由，我們 產生出來的錯誤注入模組，只能使用 SystemC 的標準指令，而避免使用到 CoWare 內部設定的特殊指令，這樣才能確保產生出來的錯誤注入模組能夠 使用在各種不同的系統模擬平台上。

3. 如何將自動化錯誤注入模組產生工具與CoWare Platform Architect 提供的命 令(commands)結合？

由於我們開發的工具，目標是希望可以將產生的標準錯誤注入模組”

自動”加入原始系統中。因此 CoWare Platform Architect 系統模擬平台上提 供的命令(commands)中包括 set_block_port_protocol 可以進行模組上連接埠 的 protocol 設 定 、 load_all_modules 可 以 將 模 組 加 入 系 統 函 式 庫 中 而 get_param_value 可以進行 port name、protocol、data width 等相關資料的抓 取，可以幫助我們達成全自動化的目標。因此，自動化錯誤注入模組產生 工具勢必要跟其命令緊密的結合。

4. 如何驗證工具的正確性？

此篇論文所開發的自動化工具，其功能包含有：

(1) 擷取系統模擬平台中的系統資料。

(2) 產生 BCA、untimed 以及 timed functional level 三種不同設計層級的 operational profile modules 以及 fault injection modules。

(3) 在 BCA 設計層級，有兩種不同的錯誤注入時間分佈模組：Weibull 和

Uniform 可選擇。

(4) 在 untimed 和 timed functional level，工具提供多種不同事件，讓使用者 可以選擇單一事件或組合事件進行錯誤注入。

為了驗證工具所提供之功能是否都可正常運作，我們在第六章設計了一 個實驗，針對timed functional level 中 OPM、FIM、單一事件以及組合事件 進行正確性驗證。至於BCA 及 untimed functional level 的功能性驗證，我們 將在未來工作繼續完成。

5. 如何驗證工具的完整性？

其工具的完整性驗證包含以下幾個目標：

(1) 是否可以在Bus Cycle Accurate Level、timed functional level、untimed functional level 上進行錯誤注入。

(2) 是否可以完成單一事件以及組合事件的錯誤注入。

(3) 是否可以將錯誤注入模組自動加入到系統。

第三章 不同層級的錯誤注入方法

在第二章的相關研究中，我們整理收集了一些相關研究在SystemC上開發的 錯誤注入方法，接下來我們將針對這些相關研究所提出的錯誤注入方法以及我們 在工具中所使用的錯誤注入方法，做進一步的詳細說明。

以下將提出三種不同層級的錯誤注入方法，分別是：bus cycle accurate level、

untimed functional level 以及 timed functional level。[15]的作者針對這三種不同的 設計層級各設計了一個模組(Module)，稱之為錯誤注入模組(FIM)。利用這三種 不 同 設 計 層 級 的 錯 誤 注 入 模 組 進 行 錯 誤 注 入 。 另 外[16] 的 作 者 針 對 timed functional level 設計錯誤注入的方法，主要是實踐在 CoWare Platform Architect[18]

提供的 Transactor 模組上。以下介紹的 Bus Cycle Accurate level 及 untimed functional level 的錯誤注入方法是以[15]為主；而 timed functional level 是以[16]

為主。

3-1 Bus Cycle Accurate Level

Bus Cycle Accurate這個設計層級是SystemC中較特殊的一層，因為在這個設 計層級的描述方式擁有精確的時間週期(clock cycle)，其優點是在進行錯誤注入 時可得到較精確的結果，但缺點是會導致系統模擬的時間變慢。在本篇論文中，

Bus Cycle Accurate的設計層級是利用clock cycle當作錯誤注入的啟動條件，而模 組之間的溝通方式是透過sc_signal做連接。

Bus Cycle Accurate的錯誤注入方法是將每一個錯誤注入模組搭配一個2對1 多工器(multiplexer)，如圖3-1所示。

圖3- 1 BCA 層級的錯誤注入模組示意圖

在進行錯誤注入實驗之前會先選擇錯誤目標點(fault target)，決定之後會在該 目標點(某個IP)的輸出相接sc_signal上插入錯誤注入模組及多工器。每一個錯誤 注入模組內都會有一組錯誤注入清單(fault injection list)，其中紀錄了每一筆要注 入錯誤的時間點、錯誤注入的值以及錯誤持續時間。錯誤注入模組會利用 SystemC所提供的標準函式(function) -sc_simulation_time()-在系統模擬時抓取模 擬時間。由於系統上的模擬時間對於所有的模組來說都是相同的，利用這個特 性，可以判斷送出正確與錯誤的資料時間點。當系統的模擬時間與錯誤注入清單 上面所列出的時間不符合，錯誤注入模組就會將Sel訊號輸出為’1’並傳送給多工 器，讓原來正確的資料經過；但若是系統模擬時間與錯誤注入清單上面的時間相 符合，代表錯誤注入模組要在這個時間點上注入錯誤，這時候錯誤注入模組就會 將Sel訊號輸出為’0’並傳送給多工器，將錯誤注入模組內設定的錯誤資料送出。

錯誤持續時間(fault duration)在這個設計層級是根據設計錯誤注入模組時的 參數設定來控制。若錯誤持續時間還沒有結束，錯誤注入模組會持續將Sel訊號 線輸出為’0’並傳送給多工器，所以在接下來的時間點也會輸出相同的錯誤資 料。直到錯誤持續時間結束，錯誤注入模組才會將Sel輸出為’1’，並恢復原來正 確的資料傳送。

3-2 Untimed Functional level

本篇論文在Transaction Level Models 中實現 untimed functional level 的錯誤 注入使用的是SystemC 函式庫中所提供的 FIFO 通道：sc_fifo，當有存取的動作 發生時，FIFO 就會自動啟動。

因為FIFO 不像 bus cycle accurate 一樣有精確的時間，而且 FIFO 在讀取、

存入資料時並不會固定在某一個時間週期，因此不能沿用bus cycle accurate 的錯 誤注入方法，所以作者在這裡提出了第二種錯誤注入的方法，並利用兩種事件當 作錯誤注入的驅動條件：

1. 讀取資料的次數

每一次讀取FIFO 內部的資料，錯誤注入模組內部的計數器就會累加，當 計數器的數值與錯誤注入模組中的錯誤注入清單所設定的數值相同，錯 誤注入模組就會將錯誤的值輸出。

2. 讀取資料的值

將每一筆讀取到的資料與錯誤注入模組內的錯誤注入清單(fault injection list)內設定好的資料比較，如果兩者的數值相等，錯誤注入模組就會將錯 誤的值輸出。

F I F O

F I F Event O

Check

FIM Correct Data

Data

Count

Error Data

Enable Duration Data Copy

圖3- 2 TLM Untimed Functional Level 的錯誤注入模組示意圖

在這個設計層級其錯誤注入模組的架構如圖3-2 所示。一共可分為三個主 要的模組：

1. Data Copy：

利用port->read()這個函式，將 FIFO 的資料讀取到模組內。除此之外，

在模組內部設置了一個計數器，每當讀取到一筆資料，計數器就會加

‘1’。並將資料複製成兩份之後再利用 port -> write()函式，把一份資料送 至Event Check 進行事件的判斷；把另外一份資料送至 FIM 作為正確的 資料存放。並且將剛剛計數器計數後的值，送至Event Check 進行事件 的判斷。

2. Event Check：

Event Check 在錯誤注入模組裡面所扮演的角色，是根據 Data Copy 模組 送過來的資料及計數值判斷是否要進行錯誤注入，其內部的架構如圖 3-3 所示。

Data Check

Count Check

Error Data 1 Duration 1 Enable 1

Mux Error Data 2

Event Check

Duration 2 Enable 2

圖3- 3 Event Check 內部架構示意圖 在Event Check 的內部又包含了三個主要的模組：

(1) Data Check：

Data Check 會負責判斷每一筆讀進來的資料，是否為錯誤注入清單 中設定的值。如果不是，Data Check 會將輸出訊號中的錯誤資料 (Error Data)、錯誤持續時間(Duration)和致能訊號(Enable)都設定 為’0’，告知錯誤注入模組現在沒有要進行錯誤注入的動作；反之 若判斷需進行錯誤注入，Data Check 就會將錯誤資料、錯誤持續時

間以及致能訊號都輸出成設定的錯誤資料。

(2) Count Check：

在Count Check 中，包含一組錯誤注入清單，紀錄要進行錯誤注入 的count 值。若計數器的 count 值不符合錯誤注入清單內的數值，

則錯誤資料、錯誤持續時間及致能訊號就會輸出為’0’；一旦收到 計數器送過來的count 值符合錯誤注入清單內的數值，Count Check 就會將錯誤資料、錯誤持續時間以及致能訊號輸出成設定的錯誤資 料。

(3) Mux：

這個模組是決定將Data Check 或是 Count Check 送出來的值輸出，

根據Data Check 跟 Count Check 的致能訊號線，決定將哪一個模組 送出來的值輸出，若Data Check 的致能訊號線=’1’而 Count Check 的致能訊號線為’0’，這個模組就會將 Data Check 的資料送出，但 若Data Check 跟 Count Check 的致能訊號線同時為’1’時，就要看設 計者當初在定義這兩種事件時的優先權誰的比較高。在本篇論文中 是將Data Check 的優先權設定高於 Count Check 的優先權，表 3-1 整理Event Check 中的各種情況，並藉由這個表格說明當 Data Check 跟 Count Check 的致能訊號線同時為’1’時，Event Check 的輸 出為何。

Data Enable Count Enable Error Data Duration Enable

0 0 0 0 0 0 1 Error Data 2 Duration 2 Enable 2

1 0 Error Data 1 Duration 1 Enable 1 1 1 Error Data 1 Duration 1 Enable 1

表3- 1 Event Check 的輸出狀態選擇表

3. FIM：

這個模組的功能，根據Event Check 送出來的致能訊號，決定是要送正 確的資料還是經過錯誤注入的資料。當致能訊號為’0’，代表 Data Check 和Count Check 都沒有啟動錯誤注入，這時候錯誤注入模組會將原來系 統中正確的資料輸出；若致能訊號為’1’，根據 Event Check 所送出的資 料來決定錯誤注入模組要輸出什麼資料。接下來要判斷錯誤持續時間的 值，若錯誤持續時間的值不等於 0，代表還要繼續傳送錯誤的資料，每 傳送一筆資料錯誤持續時間的值就會減 1，直到錯誤持續時間的值等 於’0’，這時候就不再送出錯誤的資料。

3-3 Timed Functional Level：Transactor 的錯誤注入方法

Open SystemC Initiative (OSCI)將 SystemC 中的 TLM 分成下列三種設計層 級：Programmers View (PV)、Programmers View with Timing (PV+T)、以及 Cycle Callable (CC)。設計層級越高代表其抽象層級越高、模擬速度越快。這裡的 PV 等同於TLM 的 untimed functional level；PV+T 等同於 TLM 的 timed functional level。

由於在 SystemC 上面有許多的設計層級，而不同的設計層級使用不同的 protocol。當設計者利用 SystemC 設計系統時，可能會將多個設計層級以及多個 不同的protocol 加以混合使用。為了使不同設計層級的模組之間能夠互相溝通，

訊 息 的 傳 遞 需 要 透 過 有 橋 樑(bridge) 功 能 的 零 件 做 不 同 層 級 的 轉 換 ， 而 Transactor[20]就是其中之一。

在[21]的研究中，針對 AMBA Bus 提出了新的錯誤注入方法，透過修改 CoWare Platform Architect[18] 中 矽 智 產 零 件 庫 (IP library)[22] 所 提 供 的 Transactor，達到資料收集以及錯誤注入的功能，其系統架構圖如 3-6 所示。在圖 3-6 中，Master 元件是屬於 PV+T 的設計層級並使用 AMBA protocol；Slave 元件 是屬於PV 的設計層級並使用 PV protocol。為了溝通兩種不同 protocol 之間的訊

號，因此利用Transactor 連接 PV 與 PV+T 設計層級。

圖3- 4 Transactor 錯誤注入模組架構示意圖

這個新的方法，主要分為兩個階段：第一階段是透過 operational profile module(OPM)收集資料；第二階段是利用 fault injection module(FIM)進行錯誤注 入，其詳細過程如下所述：

第一階段：

一開始先利用產生出來的operational profile modules，進行 AMBA Bus 上的 訊號收集，這些訊號包括：位址(address)訊號、資料(data)訊號、以及控制(control) 訊號。收集這些訊號主要是為了之後進行錯誤注入實驗時，可以提供錯誤注入模 組(FIM)選擇事件驅動的依據。

第二階段：

利用第一階段所收集到的資料，針對進行 FMEA 分析所需的事件，產生相 對應的錯誤注入模組。在這錯誤注入模組裡，除了原有的Transactor 架構外，還 包含了event check 和 fault injection 兩個功能：Event check 的目標事件主要根據 第一階段在AMBA Bus 可收集到的訊號，如表 3-2 所示。而這些事件，除了可以 單一輸入之外，也可以進行事件之間的組合，可以讓設計者針對更詳細的狀況進

行FMEA 的分析。當 AMBA Bus 產生設計者所選擇的事件類型時，錯誤注入模 組會將原來設定的錯誤狀況注入，例如：當address = “0x80000000”時，我們會 將設定好的錯誤值”0x70000000”取代原來的位址值。

事件類型 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

表3- 2 AMBA Bus 訊號總表

第四章 錯誤注入工具開發流程

在上一個章節，介紹了幾種在 SystemC 中注入錯誤的方法，接下來我們將 說明這些方法如何被應用在工具設計開發中。

這篇論文所開發出來的錯誤注入工具必須要跟 SystemC 的系統模擬平台互 相搭配使用，在我們的實驗中使用的SystemC 系統模擬平台是使用由 CoWare 公 司所開發出來的Platform Architect[18]，這套系統模擬平台提供了完整的元件函 式庫(IP library)[22]、AMBA Bus library[20]以及豐富的指令集(Commands)[23]，

讓設計者可以在這個平台上有效率地進行系統的開發。

在接下來的章節中，我們將介紹一些CoWare Platform Architect 內部跟工具 有相關的名詞定義，以及工具內會使用到的命令(commands)。

4-1 CoWare Platform Architect 名詞及命令(Commands)介紹

在使用 CoWare Platform Architect 時，必須要了解其內部所使用的名詞意 義，這樣才能根據其目的執行正確的操作，下表4-1 列出此篇論文中會使用到的 名詞及其解釋。

名詞 名詞解釋

bridge 一個具有轉換功能的 block，其轉換的部份包括：protocol, addressing mode…等。

block system library 中的元件。

include path 放置header file 或是 source file 的資料夾路徑。

instance 從system library 加入到系統中的元件。

port 元件上的連接埠。

protocol 元件之間的通訊協定。

system library 系統內建的函式庫，裡面提供許多可以使用的IP，像是：CPU, RAM, ROM, BUS...等。

表4- 1 名詞解釋表

接下來我們將針對在錯誤注入工具中會使用到的每一道命令，說明此命令及 其內部各個參數所代表的意義。下表4-2 彙整所有命令的名稱、內部參數、命令 及各個參數的解釋。

首先，針對命令中會使用到的符號進行定義：

<>：括弧內的 item 是必須要填入的參數。

[]：括弧內的 item 是可選擇性的填入。

命令名稱 (Command name)

參數 (Parameters)

命令和參數解釋

add_to_systemc_include_

path

<dir> 增 加 一 個 資 料 夾 的 名 字 到 SystemC 的 include path。

dir：

定義為資料夾的名字。

create_bridge_from_block <block>

<masterPort>

<slavePort>

將block 轉換成 bridge。

block：

定義為 block instance 的名 字。

masterPort：

定義為master port。

slavePort：

定義為slave port。

create_connection 1. <name>,

<begin>,

<end>

2. <name>,

<ports>

建立新的連線，連接的方式 有下列幾種：

1. bus 與 bus 之間的連線或 是bus 與元件上的 port 之 間的連線。

3. <name>,

<hierarchicalInstance>,

<ports>

2. 一列的 ports 全部連接到 同一個元件上的port。

name：

新連線的名字。

begin：

定義為begin port。

end：

定義為end port。

ports：

定義為一列的ports。

hierarchicalInstance：

定義為hierarchical instance。

get_connected_port <port> 從輸入的 port 去找到另外一 個連接的port。

port：

定義為port 的名字。

get_param_value <item>,

<set>,

<param>

取得item 內的參數。

item：

包括a block instance, a port, a instance port protocol…等。

set：

定義為參數集合的名字。

param：

定義為參數的名字。

get_port_protocol <port> 取得port 的 protocol。

port：

定義為port 的名字。

instantiate_block <block>,

<parentInstance>,

<newInstance>

從系統函式庫中取出一個元 件加入系統。

block：

定 義 為 系 統 函 式 庫 中 的 元 件。

parentInstance:

定義為新的 instance 要被加 入 到 哪 一 個 hierarchical block。

newInstance：

定義為新加入的 instance 名 字。

list_connections <hierarchical instance> 列出 hierarchical instance 上 所有的連線。

list_instances [instance] 列出系統上所有的 instances 或 是 被 指 定 的 hierarchical instance。

instance；

定義為hierarchical instance。

list_ports <item> [withMonitors] 列出item 上所擁有的 port 的 名稱。

item：

包括a library block, a block instance, a connection…等。

withMonitors：

只 有 item 被 設 定 為 connection 時，若 withMonitor 設定為 true，連線上 monitor 的port 也會被列出來。

load_all_modules <files> 載入模組。

files：

定義為含模組的檔案名稱。

load_system <file> [merge] 載入系統。

file：

包含能夠載入到 Platform 系 統中所有相關資料的檔案。

merge：

這個系統是否已經被合併到 其他存在的系統中。

remove_connection <connection> 移除連線。

connection：

連線的名字。

remove_instance <instance> 移除instance instance：

instance 名字。

rename_connection <old>

<new>

重新命名連線名稱。

old：

原來的連線名字。

new：

改變後的連線名字。

set_block_port_protocol <blockPort>

<protocol>

設定port 的 protocol。

blockPort：

定義為block port。

protocol：

定義為protocol。

表4- 2 命令彙整表 4-2 錯誤注入工具設計流程簡介

接下來將針對此篇論文中所開發的錯誤注入工具，進行詳細的說明。下圖 4.1 為整個錯誤注入工具的設計流程示意圖。

Fault Injection Modules CoWare Architect

Platform

OPM generation

Execute scripts to insert OPMs automatically

FIM generation

Execute scripts to insert FIMs automatically

Simulation and operational profile for

FMEA analysis

FMEA Analysis Simulation

Operational profile for FIM generation

Items Selection : I. FIM generator II. FMEA analysis Execute scripts to

collect fault targets and relative data

Choose level : BCA level, Untimed level

or Timed level

Choose fault distribution

I.Weibull II.Uniform

Input the simulation time,

duration...etc.

I

II

Select fault targets

Event formation and event choice: single event or event

combination I.connected port

II.port type III.protocol ...etc.

Select AHB or APB for Timed level Select fault targets

OPM

BCA level Untimed level

Choose level : BCA level Untimed level

Timed level

Input the number of fault injection

campaigns Select AHB or APB

for Timed level Timed level BCA or

Untimed level

Input the number of

masters

Timed level

圖4- 1 錯誤注入工具之設計流程示意圖 在圖4-1 的設計流程主要可分為三個部份：

(一) CoWare Platform Architect

第一個部份，我們使用CoWare Platform Architect 所提供的命令擷取系統內

部的相關資訊，像是：instance name, port name, protocol…等。透過我們另外 開發的script 產生器(script generator)，輔助使用者根據要擷取的資料，產生 不同的 script。但 script 中所包含的不同命令之間有其順序存在。若沒有遵 照以下命令的執行順序，則此script 就無法順利在 CoWare Platform Architect 上執行。除此之外，依據不同的設計層級所使用的錯誤注入方法，必須執行 不同的命令。

在BCA 和 untimed functional level 執行的命令順序如下所列：

(1) 使用 command ”list_connections”擷取系統中所有的錯誤注入目標(fault targets)。

(2) 使用 command “list_ports”擷取錯誤注入目標前後連接的連接埠名稱(port name)。

(3) 使用 command “get_port_protocol”和”get_param_value”擷取連接埠的通 訊 協 定 以 及 連 接 埠 內 部 的 資 訊 ， 像 是 ：AddressingMode, Category, Direction, MasterSlaveness, addree_width, data_width。

而Timed functional level 的執行需依循以下順序：

(1) 使用 command ”list_instances”擷取系統中所有 instance 的名稱。

(2) 使用 command “list_ports”擷取錯誤注入目標(fault targets)上的連接埠名 稱(port name)。

(3) 使用 command “get_connected_port”和”get_param_value”擷取錯誤注入目 標上各個連接埠所連接到的目標以及內部的資訊，像是AddressingMode, Category, Direction, MasterSlaveness, Address_width, Data_width。

將執行shall script 後的結果存入檔案中，提供驗證工具在產生 OPM 及 FIM 時的資訊輸入。

(二) OPM

第 二 個 部 份 ， 利 用 錯 誤 注 入 工 具 自 動 產 生 Operational Profile

untimed functional level，因為是以模組之間的連線作為錯誤注入目標，加入 OPM 之前必須先把原來的連線切斷；而 timed functional level，是以 Transactor 作為錯誤注入目標，其原本系統架構裡就已經存在，只需將OPM 取代原來 的錯誤注入目標即可。執行系統模擬並收集所有流經OPM 的資料及訊號，

為第三部份要產生錯誤注入模組(FIM)提供相關的資訊。錯誤注入工具產生 OPM 的步驟如下：

(1) 執行錯誤注入工具，選擇產生 Operational Profile Module，並從三種設計 層級中，選擇其中一層。

(2) 選取要收集資料的錯誤注入目標。若設計層級選擇是 timed functional level，由於有兩種不同的匯流排(Bus)種類，所以要告知工具產生那一種 匯流排要使用的OPM。除此之外，一條匯流排上可能有多個 master，所 以使用者必須要輸入 master 個數。在此設計層級，我們要收集每一個 master 送出的所有訊號，包括：address、data、以及 control signals，在 表3-2 中，列出了 Transactor 可以抓取到的所有訊號，並根據不同的訊號 類型分別儲存，之後要對系統進行分析時，只需要根據要分析的事件讀 取相關的檔案。

(3) 產生對應層級的 OPM。

(4) 根據產生出來的 OPM 設計層級不同，在 CoWare Platform Architect 上所 要執行的script 也不盡相同。

對BCA 和 Untimed functional level 所執行的 script 包含下列命令：

(i) add_to_systemc_include_path (ii) load_all_modules

(iii) instantiate_block (iv) remove_connection (v) create_connection

而對timed functional level 的 script 中包含的命令則為：

(i) add_to_systemc_include_path (ii) load_all_modules

(iii) remove_instance

(iv) create_bridge_from_block (v) set_block_port_protocol (vi) instantiate_block

(vii) create_connection (5) 執行系統模擬。

(6) 收集系統模擬後的資料，像是：transaction count, address, data, control signals…等。

(三) Fault Injection Modules

第三個部份，利用OPM 所收集到的資料，根據不同的設計層級像是：BCA、

untimed functional and timed functional level 以及不同的錯誤注入驅動方式：

時間驅動和事件驅動，自動產生對應的錯誤注入模組。錯誤注入工具的使用 步驟如下：

(1) 執行錯誤注入工具，選擇產生 Fault Injection Module(FIM)，並從三種設計 層級中，挑選其中一種。使用者可根據需求決定一次模擬要注入的錯誤個 數。

(2) 若使用者選擇 BCA level，工具提供了 Weibull 和 uniform 兩種錯誤分佈模 組給使用者選擇；而untimed functional level 因為無時間觀念，在這個設 計層級是採取事件驅動方式；在timed functional level 其 Bus 架構所使用 的clock cycle 為虛擬的時間，因此在這個設計層級也是採取事件驅動的方 式。

(3) 若設計層級為 timed functional level，使用者要告知工具 FIM 是接在 AHB 還是APB 上。