Analysis of Permanent Faults in Transaction Level SystemC Models

Reza HajisheykhiDepartment of

Computer Science and EngineeringMichigan State University

East Lansing, MI, USAEmail: hajishey@cse.msu.edu

Ali EbnenasirDepartment of

Computer ScienceMichigan Technological University

Houghton, MI, 49931, USAEmail: aebnenas@mtu.edu

Sandeep S. KulkarniDepartment of

Computer Science and EngineeringMichigan State University

East Lansing, MI, USAEmail: sandeep@cse.msu.edu

Abstract—Since SoC systems are typically used for criticalscenarios, it is desirable to analyze the impact of faults onthem. However, fault-impact analysis is difficult due to thehigh integrity of SoC systems and different levels of abstractionprovided by modern system design languages such as SystemC.In this paper, we present a method for modeling and analyzingpermanent faults in SystemC TLM programs. The proposedmethod includes three steps, namely timed model extraction,fault modeling, and fault analysis. We use UPPAAL timedautomata to formally model the SystemC TLM programs andmonitor how the models behave in the presence of faults. A casestudy is also provided to better explain our proposed method.

Keywords: SystemC, Transaction Level Modeling, FaultModeling, Fault Analysis

I. INTRODUCTION

System on Chip (SoC) and Network on Chip (NoC)systems have grown continuously in their performance andcomplexity. As a result, the design process for such systems,which includes hardware and software components, has alsobecome more complex. This has given rise to the needfor studying the effects of faults in today’s complex SoCsystems. A de-facto standard in hardware/software systemspecifications is SystemC [1]. It is a widely accepted lan-guage based on a C++ library that provides hardware mod-eling concepts (e.g., time, concurrency, events, logic valuetypes, etc.) for the description and simulation of systemsat different levels of abstraction. In particular, the conceptof Transaction Level Modeling (TLM) [2], which enablestransaction-based interactions between the components of asystem, improves the success of SystemC. The objectiveof this paper is to analyze the effects of different typesof permanent faults on SystemC TLM models and evaluatehow the models behave in the presence of those faults. Theresults of these evaluations will help SystemC designers togain a better understanding of the behaviors of SystemCTLM models in the presence of faults, thereby facilitatingthe design and verification of fault-tolerant mechanisms insuch programs.

There are numerous approaches for fault injection andimpact analysis of SystemC programs. In fault injectionmethods [3], [4], [5], [6], [7], faults are injected to the

This work is supported by National Science Foundation awards CNS-1329807 and CNS-1318678.

program under the test to analyze the impacts of faults onsystem output at different levels of abstraction. Testing meth-ods can be categorized into test patterns [8] and verification-based methods [9], [10], [11], [12]. Our work lies in thesecond category where the designers can use techniquesfor software model checking of finite models created fromSystemC models and then checking properties of interest byan exhaustive search in the finite model. In [13], [14], [15],manual program transformations from SystemC or SystemCTLM models into equivalent state machines are proposed.However, these transformations do not capture the precisesemantics of the TLM transport mechanisms or sockets.Herber et al. [16] propose an automatic transformation ofa SytemC TLM model into a semantically equivalent timedautomata model. They use this transformation to test a set ofsafety and liveness properties. Nonetheless, this work doesnot consider faults and their impacts on the model. In [17],we propose an approach for designing fault-tolerant concernsin SystemC TLM models. In our approach, we analyze theimpact of specific kinds of transient faults and design afault-tolerant SystemC TLM program with respect to thosefaults. However, we consider only untimed SystemC models.In [18], [19], [20], [21] the authors propose fault/mutationmodels for SystemC TLM models. They mainly target faultlocalization in their methods and do not analyze the impactof faults on the SystemC TLM models. By comparison,in this paper, we focus on modeling permanent faults inthe extracted time-constrained formal model from SystemCTLM model and analyze the impact of those faults on thefault-affected model.

The proposed approach applies model extraction, faultmodeling, and model checking to analyze the effects offaults on SystemC TLM models. The proposed frameworkhas three parts: (1) model extraction, (2) fault modeling, and(3) impact analysis.

For the first part, we leverage the approaches from [17],[22] to extract UPPAAL timed automata [23] from the Sys-temC TLM model. To obtain the desired model, we utilizeapproaches from [17] by incorporating timing constraintsin them. The motivation for choosing UPPAAL timed au-tomata as the target formal language is multi-fold: (1) Itsupports interactions between parallel processes includingtiming behaviors and dynamic sensitivity, (2) Similar toSystemC, UPPAAL toolset permits modeling of the program

2014 IEEE 34th International Conference on Distributed Computing Systems Workshops

1545-0678/14 $31.00 © 2014 IEEE

DOI 10.1109/ICDCSW.2014.33

154

as a network of communicating processes. Hence, it canpreserve the architecture of the SystemC TLM programsby supporting transactions in the extracted timed automata,and (3) Compared to other state-based modeling languages,UPPAAL is especially well-suited to modeling and verifyingtiming behaviors.

For the second part, we inject different kinds of permanentfaults including Byzantine, fail-stop, and stuck-at faults intothe extracted timed automata to create a model in thepresence of faults. Towards this end, we identify severalrules that describe how the given faults can be modeledin the UPPAAL model. These rules are purely syntactic innature and do not involve semantic analysis of the givenUPPAAL model.

Finally, in the third part, we use the UPPAAL toolsetto verify the timed automata that considers the effect offaults. We expect that the analysis will ultimately lead toa better understanding of the effect of faults on SystemCTLM programs and as a result a higher dependability ofSoC systems designed using SystemC TLM models.

To validate our proposed method, we have conducted acase study that represents on-chip memory-mapped bussesusing TLM base protocol. This case study utilizes Loosely-Timed (LT) coding style and blocking transport interfacefor communication. The LT style is mainly used whendesigners need fast simulation of a program with littlecare about timing concerns. Such a style of coding heavilyrelies on a blocking transport interface b transport() forcommunication. For analyzing the impact of faults on thiscase study we consider three types of permanent faults,namely Byzantine, fail-stop, and stuck-at faults. We evaluatethe time for identifying counterexamples and/or verificationfor the case study and argue that the time is comparable withverification in the absence of faults.

Contributions of the paper. We present

• an approaches for modeling permanent faults for UP-PAAL model of SystemC TLM models;

• a case study where we analyze the impact of faults onmemory-mapped busses, and

• experimental evidence that the increased cost of ver-ification due to faults is small. In other words, thetime for verification of fault-free UPPAAL programis comparable with fault-affected UPPAAL programs.Thus, our approach will be applicable in scenarioswhere verification of fault-free programs is feasible.

Organization of the paper. The rest of the paperis organized as follows: In Section II, we give a briefbackground of SystemC TLM models. In Section III, weidentify different types of permanent faults considered inthis paper. The modeling of these faults is formalized in thecase study, which is presented in Section IV. Finally, theconcluding remarks are presented in Section V.

II. BACKGROUND

This section provides a brief background on SystemCand its simulation kernel (Section II-A), Transaction LevelModeling (Section II-B), UPPAAL timed automata (SectionII-C), and UPPAAL model extraction (Section II-D). Theconcepts presented in this section are mainly adapted from[1], [2], [17], [23], [22].

A. SystemC

SystemC is an open-source C++ class library that pro-vides executable models of hardware-software systems atdifferent levels of abstraction. It provides an event-drivensimulation kernel in C++ that enables the simulation ofconcurrent processes. SystemC scheduler, which is a part ofthe kernel, selects one of the processes to be executed fromthe sensitivity list. The sensitivity list consists of a set ofevents or timeouts that cause a process to be either resumedor triggered. The SystemC scheduler includes the followingphases to simulate a system: i) initialization: each processis executed once; ii) evaluation: all processes that are ready-to-run are either executed or resumed in an arbitrary order;iii) update: primitive channels and signals are updated; iv)delta notification: A delta notification is an event resultingfrom an invocation of the notify() function with the argumentSC ZERO TIME. If there are delta-delay notifications,the corresponding processes are triggered; and v) timednotification: if pending timed notifications or timeouts exist,the scheduler identifies the corresponding sensitive processesand adds them to the set of runnable processes.

B. Transaction Level Modeling

Transaction Level Modeling (TLM) is an abstraction levelabove SystemC whose primary purpose is to accelerate sim-ulation by utilizing function calls instead of using individualevents and pins. In TLM, a transaction is an abstractionfor an interaction between two or more modules for eitherdata transfer or synchronization. TLM 2.0, in particular,targets transaction-level memory-mapped bus modeling tosupport virtual platform modeling of today’s complex SoCsystems. It is layered on top of the SystemC standard toprovide higher simulation speed and interoperability, i.e.,the ability to take TLM models from different sourcesand make them work together. In other words, SystemCprovides wrappers around the individual function calls toenable fast simulation and interoperable modeling. In aTLM model, an initiator is a module that initiates newtransactions to exchange data or synchronize with the othermodule, called the target. Both the initiator and target try tomaintain the interoperability while interacting. In TLM 2.0,the interoperability is introduced as a layer and has a set ofmain components as follows.

• Core interfaces, which comprise a set of methodsthat mainly support two abstraction levels supportedby two coding styles, namely Loosely-Timed (LT)and Approximately-Timed (AT) coding styles. Loosely-Timed is a coding style that is mainly used when

155

designers need fast simulation of a program with lit-tle care about timing concerns. Such a style of cod-ing heavily relies on a blocking transport interfaceb transport() that should be implemented in targetmodules and invoked by initiators. The AT style ofcoding is used when timing issues are important toconsider in simulation. In this style of coding, de-signers benefit from a non-blocking transport interfacenb transport().

• Generic payload, which is a structure in TLM thatcaptures transaction objects.

• Sockets, which are programming constructs that con-nect the initiator and target modules for sending andreceiving generic payloads.

• Base protocol that is a set of rules for using TLM inter-faces while sending/receiving generic payload throughsockets.

C. UPPAAL Timed Automata

Timed Automata (TA) are state machines that enablethe modeling of real-time systems [24]. The notion oftime is captured by real-valued clock variables. The clockvalues are used to express the timing constraints and canbe assigned to locations (vertices) and transitions (edges)of the TA. The semantics of TA is given by an infinite-state transition system where transitions correspond eitherto a change of location (discrete transition) or to passage oftime (time transition). UPPAAL [23] is an integrated toolenvironment for modeling, simulation, and verification ofreal-time systems modeled as networks of timed automata,extended with data types. A system in UPPAAL consistsof concurrent processes, each of them modeled as a TA.Each process TA has a set of locations and transitions.To control transitions between locations, UPPAAL usesguards that limit when process actions can be executed andsynchronization channels that require multiple processes tocoordinate.

D. Model Extraction

In order to extract a formal model from a SystemC TLMmodel, we utilize the rules and approaches in [17], [22]. In[17], we propose a set of transformation rules that extractan untimed formal model from the given SystemC TLMprogram. In [22], we extend the transformation rules suchthat the new set also considers the timing constraints of thegiven SystemC TLM program while extracting the formalmodel. These rules are proposed for Loosely-Timed (LT)coding style and blocking transport.

III. CATEGORIES OF PERMANENT FAULTS

In this section, we give a brief description of the threetypes of permanent faults considered in this paper. Bypermanent faults, we mean that the impact of the fault islong-lasting (possibly forever). In this paper, we considerByzantine faults, fail-stop, and stuck-at faults caused inhardware. In our work, we distinguish between faults andbugs with the following intuition. A fault is something that

Figure 1. The NoC switch architecture.

we expect to happen in a program and we expect the programto provide desired behavior even if it occurs. Examples ofsuch faults include faults such as message loss (caused dueto noise), malicious components, transients, etc. By contrast,a bug is something that we expect to avoid. Examplesinclude uninitialized variables, buffer overflow, incorrectuse of blocking or nonblocking interfaces, incorrect use oftimed/untimed constructs. With this distinction, intuitively,we want to ensure that the program works correctly even iffaults occur. Our work focuses on the former, i.e., it assumesthat the designer has decided that it is difficult/impossibleto prevent the faults from occurring and, hence, it must betolerated. We utilize this discussion in formal modeling ofthe faults in the case study in Sections IV. The differenttypes of permanent faults considered in this paper are asfollows.

• Byzantine faults. The Byzantine fault is one where thefaulty component continues to run but produces incor-rect results. Byzantine faults encompass both omissionfailures such as failing to receive a request and failingto send a response, and commission failures such asprocessing a request incorrectly and sending an incor-rect/inconsistent response to a request.

• Fail-stop faults. In a fail-stop fault, a componentfails functionally and the other components cannotcommunicate with it.

• Stuck-at faults. The stuck-at faults cause a signal toget stuck at a fixed value (logical 0, 1, or X); i.e., canno longer change value.

IV. MODELING FAULTS IN LT CODING STYLE

In this section, we present our fault modeling approachand apply it in the context of our case study. The case studyis a Network on Chip (NoC) switch that uses Loosely-Timed(LT) coding style and the TLM base protocol. We also utilizethis case study to formalize the faults described in SectionIII.

156

AdrDecode?

AdrDecode!

Init2Router[InitID]!

Router2Target[TargetID]?

Router2Target[TargetID]!

Init2Router[InitID]?

L9

L8

L11 L10

L7L6

x <=delay1+delay2

x >=delay1

(a) The Router module

AdrDecode!

AdrDecode?

shared. address = shared. address - TargetSiz e,TargetID = TargetID + 1

L13

L12

shared. address > TargetSiz e

shared. address < TargetSiz e

(b) The address decoding mechanism

Figure 2. The extracted UPPAAL timed-automata in LT coding style. The green texts show either the guards or synchronization, the bluetexts show the updates, and the magenta texts represent the names.

A. Description of Case Study

In this case study, first, we use SystemC TLM to model aNetwork on Chip (NoC) switch. We assume that the switchhas eight processing cores that communicate using a router.

To model this switch, we assume we have memorymapped busses with four Initiators and four Targets and aRouter as an interconnect component between the Initiatorsand Targets (See Figure 1). Each Initiator module generates atransaction and sends it to one of the Target modules throughthe Router using b transport() interface. The Router re-ceives the transaction, decodes the address attribute in thetransaction, and forwards it to the appropriate Target usingthe decoded address. The Router also needs to manage thereturn path from the Targets to the Initiators. In other words,the Router is a component that forwards transactions from anincoming target socket to an outgoing initiator socket. In thisexample, there are four incoming target sockets connectedto four instances of the Initiator, and four outgoing initiatorsockets connected to four instances of the Target. Socketsbelonging to the Initiators are bound to the target sockets ofthe Router, and each of the four initiator sockets belongingto the Router is bound to a socket belonging to a differentTarget. Each initiator-to-target socket connection is point-to-point.

B. Extracted Timed Automata Model

We use the methods in [17], [22] (described briefly inII-D) to extract the UPPAAL timed-automata model fromthe SystemC TLM model. Next, in Figure 2, we identifythe fault-free version of this model that forms the basis ofmodels generated for different types of faults. Due to reasonsof space, we only present the extracted model for the Routermodule and the extracted models of the Initiators and Targetsare the same as those in [22].

Figure 2(a) represents the Router automaton and Figure2(b) shows the address decoding mechanism used in theRouter module. The Router receives a transaction throughone of the channels Init2Router and changes its state to L7.This transaction should not be received before delay1 timingpoint. Note that in the Router automaton, we cannot usethe same channel to communicate with Initiators since theirsocket connections are point-to-point in the SystemC TLMmodel. After receiving the transaction, the Router decodesthe address (Locations L12 and L13 in Figure 2(b)), obtainsthe TargetID, and forwards the transaction to the appropriateTarget. The Router then waits to receive the response of theTarget from the same channel (L10) and sends it back tothe appropriate Initiator (L11).

To ensure that the extracted model captures the require-ments/properties of the SystemC TLM program, we specifythe properties that should hold in the absence of faults. Forthis purpose, we define the following CTL (ComputationalTree Logic) specifications in Figure 3.

SPEC 1: A[] not deadlockSPEC 2: Init[id_i].CurrTrans.cmd == readCmd -->

(Target[id_t].SentData == Router.RcvdData)and(Router.SentData == Init[id_i].RcvdData)

SPEC 3: Init[id_i].CurrTrans.cmd == writeCmd -->(Init[id_i].SentData == Router.RcvdData)and(Router.SentData == Target[id_t].RcvdData)

SPEC 4: Init[id_i].L1 -->(Init[id_i].L2) or (Init[id_i].L3)

SPEC 5: (Init[id_i].L2) or (Init[id_i].L3) -->Init[id_i].L1

Figure 3. Properties of the extracted UPPAAL timed automata.

The correctness of requirement SPEC 1 in Figure 3

157

implies that in all paths of the extracted automata model,we do not have any deadlock. The requirements SPEC 2and SPEC 3 represent that the communicated data betweenthe Initiator and Router, and the Router and Target are thesame in the absence of faults. The SPEC 4 and SPEC5 show that the Initiator eventually generates a transactioneither with a write request (Location L2) or a read request(Location L3), and eventually comes back to the initialstate to generate another transaction. These two requirementstogether imply that the Initiator module is not blocked. Wecan extend the set of requirements and define the samerequirements as SPEC 4 and SPEC 5 for all modules in theextracted model. Using UPPAAL model checker, we havemodel checked the requirements of Figure 3.

Next, we present the rules to transform the fault-freemodel explained above (Figures 2(a) and 2(b) are a partof the extracted model) into the fault-affected model. Foreach type of faults, first, we identify a generic approachfor modifying the UPPAAL model. Then, we identify therevised model and evaluate its correctness.

C. Modeling of Permanent Faults

Generic description of permanent faults. As discussedin Section III, we consider three types of permanent faults:Byzantine, fail-stop, and stuck-at faults. The modeling ofthese faults are as follows.

• Byzantine. A Byzantine fault allows the fault to changethe affected component (variables of the component) inan arbitrary manner. Moreover, this fault can perturbthe program several times. For this type of fault, thedesigner needs to specify which variable(s) may becorrupted by the Byzantine component and the possiblevalue(s). For example, in this case study, the variablerepresenting the requesting action (read/write) is af-fected by faults. This fault can perturb the programto an arbitrary state. Hence, the default for this faultis that the variable can be corrupted to any value inits domain. Moreover, in the TA model, we inject atransition T in parallel to that of the fault-free modelfrom location, let say, Li to Lj . Having the transitionT , the fault-affected variable (defined by designer) isassigned to a different value from that of the fault-freemodel.

• Fail-stop. To model fail-stop faults, for each compo-nent c, we introduce a variable downc that denoteswhether the component is working (downc = 0) orfailed (downc = 1). This can be tailored to considerfailure of all components or only a subset of compo-nents or a specific number of components. Furthermore,all actions of component c are restricted to execute onlyif (downc = 0).

• Stuck-at. To model a stuck-at fault, we disable all tran-sitions that change the value of the variable (identifiedby the designer using the same mechanism discussedearlier). This is achieved by revising all actions thatchange the value of affected variable(s).

Modeling and analyzing Byzantine faults. In this case

study, we consider the case where the variable of concern iscmd. This variable contains the action requested from oneof the targets and can be either read from (cmd=0) or writeinto (cmd=1) one of the Targets. To perturb this variable,we inject the faults into the Initiator such that the cmdattribute is non-deterministically changed. In other words,fault causes the Initiator to behave maliciously by corruptingthe cmd variable from 0 to 1 and vice versa. The effects ofthese faults on the program are as shown in Table I. In thistable, if requirement x is satisfied, we include xs in thetable. If it is violated, we include xv . If the answer is morecomplicated, we include xz and explain the result in the text.Also, SPEC 5 is for all possible Initiators. Thus, 5s meansthat the requirement for all the Initiators is satisfied, and 5vmeans that the requirement in at least one of the Initiatorsis violated.

As shown in Table I, the resulting program satisfies SPEC1, SPEC 4 and SPEC 5 and the satisfaction of SPEC 2and SPEC 3 depends upon the effect of Byzantine fault.Specifically, when cmd is changed from 0 to 1 (respectively,1 to 0), SPEC 2 (respectively, SPEC 3) is violated andSPEC 3 (respectively, SPEC 2) is satisfied. We have alsoconsidered Byzantine failure at the Router and Target. Theresults are as shown in Table I.

Modeling and analyzing fail-stop. In this example,we consider three types of fail-stop faults: Initiator, Router,and Target failures. To model the failures, we utilize avariable downm to define a guard downm == 0. Thisguard can be defined at any transitions prior to sendingthe transaction to the Targets. We initialize this variableto 0 that shows we have no component failure. During theprogram execution, it can be non-deterministically set to 1.For example, if the injected fault perturbs the transition (L7,L8), the Router cannot decode the address and will not beable to communicate with the Initiators and Targets. As aresult, the Router is considered as a failed component. Themodeling of the Initiator and Target failures are similar.

The results for failure of different components is as shownin Table I. As expected, a Router failure causes all propertiesto be violated, since all transactions pass through the Router.However, failure of Initiator or Target does not lead to thewhole system failure. Specifically, regarding the Initiatorfailure, the location of the fault injection affects satisfactionof SPEC 4. If the fault occurs after setting the attributes inthe sending transaction, the fault does not violate SPEC 4. Ifthe fault occurs while setting the attributes, the requirementSPEC 4 is violated. Hence, we show it as 4z .

Modeling and analyzing stuck-at faults. Modelingof the stuck-at faults is similar to that in Byzantine faultsexcept that once the fault occurs, the affected variablescannot change. We consider the stuck-at fault for the variablecmd to 1 in Table I, which means the Initiator is alwaysrequesting a write action. However, if the original requestedaction is a read action (cmd=0), the Target considers it asa write action and writes a value into its memory. As aresult, when a write action is requested, the stuck-at faults

158

Cause Affected Locations Requirement Status Total Time (ms)

Fault-free model – 1s, 2s, 3s, 4s, 5s 13.0

ByzantineInitiator 1s, 2z, 3z, 4s, 5s 14.5Router 1s, 2z, 3z, 4s, 5s 14.1Target 1s, 2z, 3z, 4s, 5s 14.1

Fail-stopInitiator 1v, 2v, 3v, 4z, 5v 12.8Router 1v, 2v, 3v, 4s, 5v 13.1Target 1v, 2v, 3v, 4s, 5v 14.4

Stuck-atInitiator 1s, 2z, 3z, 4s, 5s 14.0Router 1s, 2z, 3s, 4s, 5s 14.2Target 1s, 2z, 3s, 4s, 5s 14.2

Table IMODELING AND ANALYZING PERMANENT FAULTS IN THE NOC SWITCH.

are masked and SPEC 3 is satisfied.

V. CONCLUSIONS AND FUTURE WORK

In this paper, we focused on analyzing the effect ofdifferent types of permanent faults that are of concern in theSystemC TLM program. We began with the given SystemCTLM model and extracted a fault-intolerant UPPAAL modelfrom the SystemC model. Subsequently, we considered threetypes of faults, Byzantine, fail-stop, and stuck-at faults.For each type of faults, we utilized a generic approachto transform the UPPAAL model to obtain a fault-affectedmodel. Subsequently, this model was used in UPPAAL toconclude tolerance to faults or to obtain a counterexample.We were either able to verify that the original specificationis satisfied or find a counterexample demonstrating theviolation of the original specification. Moreover, the timefor evaluating the effect of faults was comparable (< 110%)to the verification in the absence of faults.

We demonstrated our approach with a case study. Thiscase study covered a program that utilized LT coding style.Given the simplicity of the LT coding style, the time forverification was low in LT coding style. However, we believethat the evaluation of programs in Approximately-Timedcoding style is significantly higher.

One future work in this area is to extend this work withautomation of fault-tolerance where given UPPAAL model isconverted to a new model that provides the desired behaviorin the presence of faults. One of the interesting challengesin this work is to revise the model in such a way thatcorresponding SystemC TLM model can be designed withlow or no human intervention. We are also working onprograms modeled in Approximately-Timed coding style tosee how they behave in the presence of permanent faults.

REFERENCES

[1] Open SystemC Initiative (OSCI): Defining and advancingSystemC standard IEEE 1666-2005, http://www.systemc.org/.

[2] Transaction-Level Modeling (TLM) 2.0 Reference Manual,http://www.systemc.org/downloads/standards/.

[3] S. Misera, H. T. Vierhaus, A. Sieber, Fault injection tech-niques and their accelerated simulation in SystemC, in: Pro-ceedings of the 10th Euromicro Conference on Digital SystemDesign Architectures, Methods and Tools, 2007, pp. 587–595.

[4] R. A. Shafik, P. Rosinger, B. M. Al-Hashimi, SystemC-basedminimum intrusive fault injection technique with improvedfault representation, in: Proceedings of the 2008 14th IEEEInternational On-Line Testing Symposium, 2008, pp. 99–104.

[5] F. A. da Silva, P. S. Sanchez, On the use of dynamic binaryinstrumentation to perform faults injection in transaction levelmodels, in: Proceedings of the 2009 Fourth InternationalConference on Dependability of Computer Systems, 2009,pp. 237–244.

[6] Y.-Y. Chen, C.-H. Hsu, K.-L. Leu, SoC-level risk assessmentusing FMEA approach in system design with SystemC, in:International Symposium on Industrial Embedded Systems,2009, pp. 82–89.

[7] J. Perez, M. Azkarate-askasua, A. Perez, Codesign and simu-lated fault injection of safety-critical embedded systems usingSystemC, in: Proceedings of the 2010 European DependableComputing Conference, 2010, pp. 221–229.

[8] A. Fin, F. Fummi, M. Martignano, M. Signoretto, SystemC:A homogenous environment to test embedded systems, in:Proceedings of the ninth international symposium on Hard-ware/software codesign, CODES ’01, 2001, pp. 17–22.

[9] S. Kundu, M. Ganai, R. Gupta, Partial order reduction forscalable testing of SystemC TLM designs, in: Proceedingsof the 45th annual Design Automation Conference, DesignAutomation Conference, 2008, pp. 936–941.

[10] A. Sen, Mutation operators for concurrent systemc designs,in: MTV, 2009, pp. 27–31.

[11] N. Blanc, D. Kroening, Race analysis for SystemC usingmodel checking, ACM Transactions on Design Automationof Electronic Systems 15 (3) (2010) 1–32.

[12] K. Marquet, M. Moy, PinaVM: A SystemC front-end basedon an executable intermediate representation, in: Internationalconference on Embedded software (EMSOFT), 2010, pp. 79–88.

159

[13] A. Habibi, S. Tahar, An approach for the verification ofSystemC designs using asml, in: D. Peled, Y.-K. Tsay (Eds.),ATVA, Vol. 3707 of Lecture Notes in Computer Science,Springer, 2005, pp. 69–83.

[14] A. Habibi, H. Moinudeen, S. Tahar, Generating finite statemachines from SystemC, in: G. G. E. Gielen (Ed.), DATEDesigners’ Forum, European Design and Automation Asso-ciation, Leuven, Belgium, 2006, pp. 76–81.

[15] B. Niemann, C. Haubelt, Formalizing TLM with Communi-cating Stat Machines, in: Proceedings of Forum on Specifi-cation and Design Languages 2006 (FDL 2006), 2006, pp.285–292.

[16] P. Herber, M. Pockrandt, S. Glesner, Transforming SystemCTransaction Level Models into UPPAAL timed automata, in:S. Singh, B. Jobstmann, M. Kishinevsky, J. Brandt (Eds.),MEMOCODE, IEEE, 2011, pp. 161–170.

[17] A. Ebnenasir, R. Hajisheykhi, S. S. Kulkarni, Facilitatingthe design of fault tolerance in transaction level systemcprograms, Theor. Comput. Sci. 496 (2013) 50–68.

[18] H. M. Le, D. Große, R. Drechsler, Automatic TLM FaultLocalization for SystemC, IEEE Trans. on CAD of IntegratedCircuits and Systems 31 (8) (2012) 1249–1262.

[19] H. M. Le, D. Große, R. Drechsler, Scalable fault localizationfor systemc tlm designs, in: DATE, 2013, pp. 35–38.

[20] N. Bombieri, F. Fummi, G. Pravadelli, On the MutationAnalysis of SystemC TLM-2.0 Standard, in: MTV, IEEEComputer Society, 2009, pp. 32–37.

[21] N. Bombieri, F. Fummi, G. Pravadelli, M. Hampton,F. Letombe, Functional qualification of TLM verification, in:DATE, IEEE, 2009, pp. 190–195.

[22] R. Hajisheykhi, A. Ebnenasir, S. S. Kulkarni, Modeling andanalyzing timing faults in transaction level systemc programs,in: NoCArc@MICRO, 2013, pp. 65–68.

[23] G. Behrmann, A. David, K. G. Larsen, A tutorial on uppaal,in: M. Bernardo, F. Corradini (Eds.), SFM, Vol. 3185 ofLecture Notes in Computer Science, Springer, 2004, pp. 200–236.

[24] R. Alur, D. L. Dill, A Theory of Timed Automata, Theor.Comput. Sci. 126 (2) (1994) 183–235.

160